238987 - Focus and blur events bubble from some form input controls

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Gérard Talbot]

When a <select> or input type="reset" receive a focus or blur event, such events
bubble when the specs clearly indicate they should not. MSIE 6 and Opera 7.5 do
not do that.
This bugfile spins off from bug 230356. Bug 190557 refers to the same issue but
for checkbox. Cross-browser testcase coming.

Comment 1

[Gérard Talbot]

Attachment: Self-explanatory cross-browser testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

I believe we do this on purpose and I know we have code that relies on these
events bubbling....  in fact, the fact that they don't bubble from text inputs
leads to focus event bugs with <input type="file">

Comment 3

[Boris Zbarsky [:bzbarsky]]

Note that the resolution of this somewhat depends on what we decide to do with
text controls (and that depends on the file input stuff in bug 4033).

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Attachment: testcase with type="file"

focus doesn't work on type="input" when clicking inputfield. It does work when clicking the button. Though, the inputfield bug has 
nothing to do with this bug and it doesn't work in 1.8 either.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Attachment: proposed patch

Because of bug 334216, non-bubbling events get handled at target also
when dispatched somewhere in anonymous content, so type="file" works.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Fixes also textfield in the file control

There is no need to call stopPropagation in editor code, if focus and blur events don't bubble. Listener is added there for bubble phase.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 270573 [details] [diff] [review]
Fixes also textfield in the file control

This looks OK, I guess, but I wonder whether it'd make sense to move the bubble-prevention into the nsEvent constructor (basically use the message to index into something which would say whether the event bubbles).  I'd really prefer a single data table somewhere to sprinkling this throught the code...

Followup bug on that perhaps?

r+sr=bzbarsky assuming you've tested accesskeys and such and will also check in tests for this.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #7)
> but I wonder whether it'd make sense to move the
> bubble-prevention into the nsEvent constructor (basically use the message to
> index into something which would say whether the event bubbles).  

yup, I was thinking that too. I'll post a followup (with a patch for 
focus, blur, error, load, unload, scroll, SVGLoad, SVGUnload).
Everything in nsEvent is inline, I wonder how the change will affect 
codesize. Maybe the constructor should call something non-inline.

Comment 9

[Boris Zbarsky [:bzbarsky]]

You could compile and strip to see how codesize is affected.  ;)

I do think that if it's just an index into a table to set default flags (as opposed to an if cascade or something) it shouldn't be that big.