Using element.focus() in addressingWidgetOverlay.js to focus on an html:input, the widget has focus for text entry but the onkeypress="if (event.which == 13) {AutoCompleteAddress(this); awReturnHit(this);}" does not fire when return is hit. It does fire only after clicking in this html:input and hitting return.

sounds like a text input type, which is not an XPToolkit widget. reassigning to buster for triage

paul, could you please describe how I reproduce this bug? I assume I run some mail component (compose message?) with gfx widgets on, then what do I do?

To reproduce: Use a standard build as checked into the tree. Open the mail compose window. Click in the email address field, enter a name and hit return. A second input field will appear that seems to have focus. The name can be entered but return does not tigger the onkeypress= code. If the mouse is clicked in the input field, then the onkeypress will fire. The same problem can be demonstrated in the New Card dialog. Open the address book window, click the New Card button, the New Card dialog appears with focus set to the First Name field. At this point it is possible to type in the name, but the onkeypress= does not fire unless the mouse is clicked in this field. If focus is not yet supposed to work, please let me know.

Adding Hyatt to cc list.

tried opt builds from 9/1 on 2 different Win98 machines, still can't reproduce.

sorry, could you be more specific in your example? I open the compose window, type a name, hit return, a second field appear, type a name into this second field (proving it has focus), hit return, etc. What code is supposed to fire? I don't see an obvious onKeyPress handler where I can add debug info to.

buster: there seems to be a distinction between focus and focus :-). While it is true that you can type characters into this second field, when you hit return for this second field the onkeyup= handler does not seem to pass the 'this' and therefore it fails. So yes, it may have focus but it does not know its own 'this'. The onkeyup= is located in addressingWidgetOverlay.xul

set to m11. Paul, I'll be in MV on Tuesday. Can you show me more about this bug, I've had a hard time understanding what's going on in the javascript, and what you expect to happen that isn't happening.

upon bringing up mail compose, typing a character into the recipient field, and hitting return, I get this result in tonight's build: set focus on the recipient here! inputElement = [object HTMLInputElement] select = [object HTMLSelectElement] select.value = addr_to JavaScript Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIAutoCompleteSession.AutoComplete ]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: ch rome://messengercompose/content/addressAutoComplete.js :: AutoCompleteAddress :: line 48" data: no]

Adding mscott to cc list in case he knows why you are seeing this autocomplete problem now.

I started seeing this message buster pointed out in a build last night. I was still looking into as of last night. I think it's separate from the bug here but may be blocking you from using auto completion in the compose window.

I'm not seeing the autocomplete java script exception in todays windows build. I haven't tried my mac yet. But I don't think it's a blocker for this bug is it? the only thing that fails is auto completion....

adding myself to cc: list

here's an update from tom pixley: Tom sez... The basic answer is that the Focus() and Blur() methods have never been properly hooked up. These calls mirror the JS calls, as the interfaces define they must, and as such have no PresContext. But since we really do need to be able to focus a single piece of content independently across multiple representations we need that. So the SetFocus method takes a prescontext, and from that PresContext it get to the EventStateManager (ESM). The javascript side of this has always been mildly busted. In fact, before gfx widgets it only worked at all on native elements since it could directly grab the widget and focus it and that still left the ESM out of the loop. Case in point, the nsHTMLButtonElement::Focus() method consisted of '// XXX write me' right up until the gfx stuff went in. So anyway, the basic answer is we have two methods because one is correct in our new world with possible multiple views: SetFocus(nsIPresContext*), and one is legacy: Focus(). They probably should be combined and at the very least, the Focus() and Blur() methods will not jive well with the rest of the system unless they at least call SetContentState on the ESM. -tom Steve Clark wrote: > > All of you at one time have touched nsHTMLInputElement::Focus() and > nsHTMLInputElement::SetFocus(), so I'm hoping someone can explain to > me what's going on here. > > The problem I'm seeing is in javascript (addressingWidgetOverlay.js), > someone is calling inputElement.focus(), and that input element is not > getting the focus. > > The result of the javascript above is nsHTMLInputElement::Focus() gets > called. But it looks like most the interesting logic (in paticular, > the use of the event state manager) is in SetFocus(), which as far as > I can tell gets called only from the event state manager: > > nsEventStateManager::ChangeFocus() does a QI to see if the content > supports nsIFocusableContent, and if so calls SetFocus(). > > It seems very odd that SetFocus and Focus don't do share the same > code. SetFocus() does call Focus(), but the direct javascript > invocation misses out on all the logic in SetFocus(). > > I'm having a hard time finding enough documentation to understand > what's going on here. > > Any help is appreciated. > > Steve --------------------------------------------------------------------------- The result of this conversation is I am moving this bug to M12, because it sounds like some design work needs to get done to make this all work right with gfx controls. Removing hyatt from the cc list 'cause I don't think he cares, and adding rods, pollman, and kevin who have to care even if they don't want to.

Thanks, Steve. Well, that is all very interesting and helpful because I am working on that problem for Joki as we speak/write. I'll keep this bug updated as to what is going on. Making this dependent on #7133

Buster, Joki: I ran into another twist that we may want to work out as we fix this. It seems that buttons get focus when you click on them. We have windows that contain buttons that act on the focused widget, the problem is that when you click on the button the button takes the focus, then the onclick fires and there is no way to see what list (tree) had focus when the user clicked the button. The example that I am using is the "Delete" button in mailnews and address book windows, but I think that the same problem will occur with the menu items on Windows; the menus may take the focus when clicked on (I have not tested that yet).

rod and I worked on a fix for this and related focus problems that rod checked in on 10/18/99, for bug 7133. I'll bet this is working now. Paul, can you retest? Assigning to rod, who owns the focus problem for widgets now.

changed to M14

changing to M15

Its M15 now and focus() and blur() still don't work. Persisten test case can be found here: http://www.pizzablitz.ch/zuerich/e-mail/ If you click on a field with default text in it, it should disappear. If the fields are blank and go blur(), then the defaultValue should be restored. Used script: function rmLabel(field) { if (field.value == field.defaultValue) { field.value = ""; } } function reLabel(field) { if (field.value == "") { field.value = field.defaultValue; } } And the input field looks like this: <INPUT NAME="E-Mail" TYPE="text" VALUE="Deine E-Mail Adresse" SIZE=32 onFocus="rmLabel(this);" onBlur="reLabel(this);"> I think this is supposed to work, isn't it?

mass-move to M16

hangas what is going on with this bug, does it still exist?

moving bugs to M17

moving to M19

This bug has been marked "future" because at this time it has been determined that it is not absolutely critical for RTM (Release To Manufacturing). If the reporter and anyone else believe it is necessary to fix this before shipping Seamonkey 1.0, please describe your issue in the bug.

Updating QA contact.

Is this still an issue or a bug?

At least, it's not anymore an issue for the Addressing Widget...

marking works for me, please reopen if it is still an issue

Verified Build 2001082703 OS:Linux7.1,win98,win2000,winNT