652531 - select elements fail to fire change event when applying position: relative during keyup

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Brad Dunbar]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: http://hg.mozilla.org/releases/mozilla-2.0/rev/6be9e31d01b4

If the style.position of an input or select element is changed from static to relative (or vice versa) during a keyup event the element fails to fire a change event upon losing focus.

Reproducible: Always

Steps to Reproduce:
1. bind to the keyup and change events of an input or select element
2. during keyup, change the style.position of the element to relative (or from relative to static)
3. focus on the element
4. press a key
5. change focus

Actual Results:  
the change event is not fired

Expected Results:  
the change event is fired

Comment 1

[Brad Dunbar]

Attachment: html test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

Sounds like we need to persist more state of some sort here across the reframe...

Comment 3

[(no longer active)]

What's a change event?  The input event is fired successfully...

Comment 4

[Boris Zbarsky [:bzbarsky]]

> What's a change event? 

The one that onchange="..." would get.

Comment 5

[(no longer active)]

(In reply to comment #4)
> > What's a change event? 
> 
> The one that onchange="..." would get.

It is not something which is fired by the editor, is it?  If not, this should move to DOM I think.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> It is not something which is fired by the editor, is it?

It's fired by nsTextControlFrame::CheckFireOnChange.  The problem is that we keep track of mFocusedValue in the frame.  We should probably move that to either the editor state or the DOM node, whichever makes the most sense.

Comment 7

[(no longer active)]

(In reply to comment #6)
> > It is not something which is fired by the editor, is it?
> 
> It's fired by nsTextControlFrame::CheckFireOnChange.  The problem is that we
> keep track of mFocusedValue in the frame.  We should probably move that to
> either the editor state or the DOM node, whichever makes the most sense.

We should move it to nsTextEditorState (which has to resort to a dirty hack to access it now: <http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsTextEditorState.cpp#1777>).

Mounir, is this something that you're interested to work on?

Comment 8

[Mounir Lamouri (:mounir)]

The <input> part of this bug has been fixed by bug 722599 and bug 787102 (Firefox 16 and above).
The <select> part isn't fixed yet so I'm changing the summary to make it <select> only.

One solution to fix this would be to make those change events being fired by the content.

Comment 9

[Andrew Quartey [:drexler]]

Attachment: Fix

Comment 10

[Andrew Quartey [:drexler]]

Comment on attachment 795687 [details] [diff] [review]
Fix

Cancelling review as this breaks other functionality i didn't take into account such as the use of special key F4 to toggle the drop down list.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.