Eric said:
Could you explain what the value of the select element’s size attribute
has to do with this?
As you could have noticed[1], if size > 1 (i.e. list, not dropdown list) the
`change' event is triggered at least in newer Geckos by change of selection
alone; the control does not need to lose focus first.
[1] <
What is most interesting, though, is that with size=1 in that UA the
`change' event also occurs already when the selection changed, provided the
dropdown list was expanded; the control does not need to lose focus first
then. In fact, when it loses focus in that case, no additional `change'
event is created (contrary to the W3C DOM Level 2 Specification). However,
the situation is different if the dropdown list is not extended; then there
is no `change' event when the selection changes, but only when the selection
changed and the control loses focus (as specified).
So, summarized, these are my observations for Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3, using
Firebug 1.2.1 for logging events:
| selection changes | loss of focus (tab away)
| (Dn +opt. <RET>) |
----------------------+---------------------------|--------------------------
size = 1 not expanded | keydown, keypress, keyup | keydown, keypress,
| | change, blur
| |
size = 1 expanded | keydown, keypress, keyup; | keydown, keypress, blur
| keydown, keypress, |
| popuphiding, change |
| |
size > 1 | keydown, keypress, change,| keydown, keypress, blur
| keyup |
Is that so? Which Firefox version on which OS have you tested with? Which
rendering mode was used?
In Firefox and Google Chrome you can tab into the select control
(i.e. give it focus) and scroll through the available options with the
up/down arrow keys *without* the change event firing. It fires
* when you hit enter/return key or
* on blur
Apparently that is different if size > 1.
PointedEars