102005 - input onchange onfocus oddness

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Simon Weijgers]

In some situations Mozilla fires an onChange event for changes made
in the onFocus event. Most of the time it doesn't and it appears
to depend on how the event handlers are installed.

Please look at the URL for a more thorough description as well as a test
case.

Comment 1

[Keyser Sose]

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Comment 2

[Simon Weijgers]

I've done exactly as you said

 - I've downloaded the latest nightly (2001110921 LINUX).
 - I created a new profile and used that new profile.

Then went through the testcase and onchange events are still fired for
some of the input boxes.

So this bug is still alive and well.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

I get a connection refused when connecting to the URL.

Simon, could you upload the html file as an attachment?  If there are any
external files needed (js or css), please try combine them all into one file
before doing so.

Thanks!

Comment 4

[Simon Weijgers]

Attachment: Testcase outlining the bug

Comment 5

[Boris Zbarsky [:bzbarsky]]

This is really bizarre.  confirming.  John, could you take a look?

Comment 6

[saari (gone)]

maybe fixed by rewrite which addresses event registration ordering, targeting 0.9.9

Comment 7

[joki (gone)]

124990 and its associated bugs is not quite ready for checkin for 0.9.9. 
Maintaining high priority and moving to 1.0 for completion and further testing.

Comment 8

[chris hofmann]

how close is this now?

Comment 9

[Daniel Wang]

The test case shows that onchange will only fire if both onfocus and
onblur event handler are registered via js instead of in HTML code.

I thought this may be due to differences with DOMFocusIn vs. focus
and DOMFocusOut vs. blur, but my test shows that DOMFocusIn is not
supported yet.

Here's some testing result I have:

.addEventListener('focus',blah,false); doesn't interfere w/ onchange

.onfocus = blah;                       doesn't interfere w/ onchange

<input onfocus=blah>                   interfere w/ onchange

<input onfocus=blah> and
input.onfocus=blah2                    interfere w/ onchange
(reset onfocus)

It seems having onfocus defined in HTML will cause onchange not to
fire correctly (even if onfocus is later redefined via js)

note: due to some other fix with alert(), <input> will get focus
back again after the onblur event is fired. To avoid this, the
testcase has to be changed, e.g. using bg color change to indicate
which event has been fired instead of using alert. My test is done
using this method.

reassign target since moz1.0 deadline is missed

Comment 10

[Pham]

.

Comment 11

[Vedran Miletic]

retargeting

Comment 12

[j.j.]

(In reply to comment #9)
> The test case shows that onchange will only fire if both onfocus and
> onblur event handler are registered via js instead of in HTML code.

Now only onblur is fired on all inputs of the testcase.
This is also what IE and opera do. Isn't that what we want?
Should this bug be closed?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070107 Minefield/3.0a2pre 

Comment 13

[Mats Palmgren (inactive)]

WFM, Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a2pre) Gecko/20070107 SeaMonkey/1.5a

Feel free to reopen if you can reproduce in builds dated 20070106 or later
(ie. where bug 265047 is fixed)

-> WORKSFORME