130500 - select: onChange should happen after onBlur

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[John Keiser (jkeiser)]

Selects currently fire onChange *before* onBlur in some cases, because we are
firing onChange from within the onBlur handler.  In fact, because of this we can
get into situations currently where we call onBlur twice, because the element is
not actually blurred yet at the point where we fire onChange, and JavaScript may
cause another element to be focused.

The proper way to handle this is to sandwich the focus setters like we did
Reflow(): WillReflow(), Reflow(), DidReflow().  Then we can fire onChange and do
other such work from within DidReflow().

Comment 1

[Jesse Ruderman]

I think onchange should happen before onblur, at least as seen by the web page.
 Web pages designed for mouse interaction don't expect to see the selected
<option> change when the <select> doesn't have focus.

Comment 2

[Daniel Wang]

w3c DOM Event specification:

change
    The change event occurs when a control loses the input focus and
    its value has been modified since gaining focus. This event is
    valid for INPUT, SELECT, and TEXTAREA. element.
blur
    The blur event occurs when an element loses focus either via the
    pointing device or by tabbing navigation. This event is valid for
    the following elements: LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.

the keyword here is probably "input focus." Does <select> fire change
event when its value is changed but still maintains the focus? If so,
then the answer should be onchange fires first, then onblur.

--> INVALID