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

VERIFIED WORKSFORME

Status

()

Core
Layout: Form Controls
P2
normal
VERIFIED WORKSFORME
19 years ago
17 years ago

People

(Reporter: hangas, Assigned: rods (gone))

Tracking

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Blocks: 10925

Updated

19 years ago
Assignee: trudelle → buster
Component: XP Toolkit/Widgets → Editor

Comment 1

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

Comment 2

19 years ago
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?
(Reporter)

Comment 3

19 years ago
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.
(Reporter)

Comment 4

19 years ago
Adding Hyatt to cc list.

Comment 5

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

Comment 6

19 years ago
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.
(Reporter)

Comment 7

19 years ago
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
(Reporter)

Updated

19 years ago
Blocks: 13399

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11

Comment 8

19 years ago
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.

Updated

19 years ago
Priority: P3 → P2

Comment 9

19 years ago
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]
(Reporter)

Comment 10

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

problem now.

Comment 11

19 years ago
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

19 years ago
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

19 years ago
adding myself to cc: list

Comment 14

19 years ago
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.
(Assignee)

Updated

19 years ago
Depends on: 7133
(Assignee)

Comment 15

19 years ago
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
(Reporter)

Comment 16

19 years ago
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).

Updated

19 years ago
Blocks: 15002

Updated

19 years ago
Assignee: buster → rods
Status: ASSIGNED → NEW
Component: Editor → HTML Form Controls

Comment 17

19 years ago
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.
(Assignee)

Updated

19 years ago
Target Milestone: M12 → M14
(Assignee)

Comment 18

19 years ago
changed to M14

Updated

19 years ago
Assignee: ckritzer → rods
QA Contact: phillip → ckritzer
(Assignee)

Comment 19

19 years ago
changing to M15
Target Milestone: M14 → M15

Comment 20

19 years ago
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?
(Assignee)

Comment 21

19 years ago
mass-move to M16
Target Milestone: M15 → M16
(Assignee)

Comment 22

18 years ago
hangas what is going on with this bug, does it still exist?
(Assignee)

Comment 23

18 years ago
moving bugs to M17
Target Milestone: M16 → M17
(Assignee)

Comment 24

18 years ago
moving to M19
Target Milestone: M17 → M19
(Assignee)

Comment 25

18 years ago
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

Comment 26

18 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma
(Assignee)

Comment 27

18 years ago
Is this still an issue or a bug?
Status: NEW → ASSIGNED
At least, it's not anymore an issue for the Addressing Widget...
(Assignee)

Comment 29

18 years ago
marking works for me, please reopen if it is still an issue
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 30

17 years ago
Verified Build 2001082703 OS:Linux7.1,win98,win2000,winNT
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.