nsHTMLInputElement is a content class for text fields. It has a reference to nsIWidget, assuming that text fields are implemented using native widgets. This is wrong. When frame-level interaction is required, nsHTMLInputElement should go through the frame that is mapping the content, not directly to the widget. Fixing this will enable us to replace native text widgets with Ender for text input fields. Kevin estimates the time to fix as approximately 2 days. He has done similar work for other content objects.

optimistically setting milestone to M6. I plan on starting implementation of Ender text fields on 5/19 for inclusion in M7.

There is a second place where a widget is unfairly assumed. nsFileControlFrame holds onto a nsTextControlFrame* mTextFrame. This is fine, except it calls mTextFrame->GetWidget(&widget);, then does a QI to an nsITextWidget and makes calls on that text widget. It should just make calls on the text frame itself, and let the frame decide how to deal with the underlying implementation.

who is blocked on this, and why?

Fixed in 5-13-99 5:03PM build. I removed all remaining references to nsIWidget in the HTML form element content objects. I also removed the reference to nsITextWidget in the file control.

Fixed in 5/17 Build