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

Status: VERIFIED WORKSFORME

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

Description

[hangas]

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.

Comment 1

[Peter Trudelle]

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

Comment 2

[buster]

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?

Comment 3

[hangas]

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.

Comment 4

[hangas]

Adding Hyatt to cc list.

Comment 5

[buster]

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

Comment 6

[buster]

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.

Comment 7

[hangas]

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

Comment 8

[buster]

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.

Comment 9

[buster]

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]

Comment 10

[hangas]

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

problem now.

Comment 11

[Scott MacGregor]

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.

Comment 12

[Scott MacGregor]

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....

Comment 13

[lchiang]

adding myself to cc: list

Comment 14

[buster]

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.

Comment 15

[rods (gone)]

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

Comment 16

[hangas]

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).

Comment 17

[buster]

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.

Comment 18

[rods (gone)]

changed to M14

Comment 19

[rods (gone)]

changing to M15

Comment 20

[Jonas Nagel]

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?

Comment 21

[rods (gone)]

mass-move to M16

Comment 22

[rods (gone)]

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

Comment 23

[rods (gone)]

moving bugs to M17

Comment 24

[rods (gone)]

moving to M19

Comment 25

[rods (gone)]

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. 

Comment 26

[bsharma]

Updating QA contact.

Comment 27

[rods (gone)]

Is this still an issue or a bug?

Comment 28

[Jean-Francois Ducarroz]

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

Comment 29

[rods (gone)]

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

Comment 30

[jerone]

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