Closed Bug 12162 Opened 20 years ago Closed 19 years ago

element.focus() on html:input in a tree does not allow for onkeydown=


(Core :: Layout: Form Controls, defect, P2)






(Reporter: hangas, Assigned: rods)



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.
Blocks: 10925
Assignee: trudelle → buster
Component: XP Toolkit/Widgets → Editor
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
Blocks: 13399
Target Milestone: M11
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.
Priority: P3 → P2
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
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.


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.
Depends on: 7133
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
Blocks: 15002
Assignee: buster → rods
Component: Editor → HTML Form Controls
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.
Target Milestone: M12 → M14
changed to M14
Assignee: ckritzer → rods
QA Contact: phillip → ckritzer
changing to M15
Target Milestone: M14 → M15
Its M15 now and focus() and blur() still don't work.

Persisten test case can be found here:

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
Target Milestone: M15 → M16
hangas what is going on with this bug, does it still exist?
moving bugs to M17
Target Milestone: M16 → M17
moving to M19
Target Milestone: M17 → 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. 
Target Milestone: M19 → Future
Updating QA contact.
QA Contact: ckritzer → bsharma
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
Closed: 19 years ago
Resolution: --- → WORKSFORME
Verified Build 2001082703 OS:Linux7.1,win98,win2000,winNT
You need to log in before you can comment on or make changes to this bug.