select onchange with typing in Webkit

[Chris Riesbeck]

In Firefox, IE and Opera, with a select menu with size > 1, typing a few
characters in the menu selects an item and triggers the onchange event.

In the Webkit-based Safari and Google Chrome, the item appears to be
selected (visually and selectedIndex is set) but the onchange is not
triggered.

The W3C says "The onchange event occurs when a control loses the input
focus and its value has been modified since gaining focus."

http://www.w3.org/TR/REC-html40/interact/scripts.html

Doesn't that mean if you type to select then tab or click away from the
menu, the onchange should fire? This doesn't happen in Safari or Google
Chrome.

I can work around this with an onblur but is it me or Webkit not getting
this right?

Toy example at

http://www.cs.northwestern.edu/~riesbeck/demo/menutest.html

 

[Thomas 'PointedEars' Lahn]

The W3C says "The onchange event occurs when a control loses the input
focus and its value has been modified since gaining focus."

http://www.w3.org/TR/REC-html40/interact/scripts.html

Doesn't that mean if you type to select then tab or click away from the
menu, the onchange should fire?

It does mean that.

This doesn't happen in Safari or Google Chrome.

It does happen in "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE)
AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1.2 Safari/525.21".


PointedEars

 

[Chris Riesbeck]

It does mean that.


It does happen in "Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE)
AppleWebKit/525.19 (KHTML, like Gecko) Version/3.1.2 Safari/525.21".

For the test page I gave?

http://www.cs.northwestern.edu/~riesbeck/demo/menutest.html

I'm running Safari 525.21 for Windows XP, and Safari 3.1.2 (5525.20.1)
on MacOS X 10.5. For both (and for Google Chrome):

- click on One in the menu (adjacent field shows "one")
- type 's' -- "shoe" highlights in the menu
- tab to next field -- adjacent field does NOT update to "shoe"

For a second, I thought maybe the problem was that the option's had no
explicit value. But I changed that and still no update, even though

javascript:alert(document.forms[0].elements[0].value)

shows "shoe" indicating the select's value has changed

 

[Thomas 'PointedEars' Lahn]

For the test page I gave?

http://www.cs.northwestern.edu/~riesbeck/demo/menutest.html

I'm running Safari 525.21 for Windows XP, and Safari 3.1.2 (5525.20.1)
on MacOS X 10.5. For both (and for Google Chrome):

- click on One in the menu (adjacent field shows "one")
- type 's' -- "shoe" highlights in the menu
- tab to next field -- adjacent field does NOT update to "shoe"

My test case, where it worked, would trigger Standards Compliance Mode in Fx
3.0.3, and used a dynamically generated `select' element with size="1".

In your test case, which could trigger Quirks Mode due to the missing system
identifier, though, the aforementioned Safari handles every change in the
selection as a `change' event, no matter if the element loses focus.

That is indeed a bug as is Safari's not regarding the selection a change in
the control's value when it is caused by putting in the leading characters;
however, Quirks Mode might trigger this non-standard behavior. (I cannot
test it right now.)


PointedEars

 

[Jorge]

(...)
That is indeed a bug as is Safari's not regarding the selection a change in
the control's value when it is caused by putting in the leading characters;
however, Quirks Mode might trigger this non-standard behavior.  (I cannot
test it right now.)

I did. I does fail in Safari 3.1.2, latest released version.
But it's been fixed already in the nightly builds (I tested r36882):

http://nightly.webkit.org/

 

[Chris Riesbeck]

My test case, where it worked, would trigger Standards Compliance Mode in Fx
3.0.3, and used a dynamically generated `select' element with size="1".

Yes, with size="1" I got onchange events, but not with size > 1.

 

[dhtml]

Chris Riesbeck wrote:

Toy example at

http://www.cs.northwestern.edu/~riesbeck/demo/menutest.html

Focus the select and type 's'.

Result:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.18
(KHTML, like Gecko) Version/3.1.2 Safari/525.22

'shoe' is selected, onchange does not fire

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/527.3+
(KHTML, like Gecko) Version/3.1.2 Safari/525.22

'shoe' is selected, onchange fires

Same version, but "AppleWebKit/527.3+" it works.

Garrett

 

[Chris Riesbeck]

Chris Riesbeck wrote:



Focus the select and type 's'.

Result:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.18
(KHTML, like Gecko) Version/3.1.2 Safari/525.22

'shoe' is selected, onchange does not fire

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/527.3+
(KHTML, like Gecko) Version/3.1.2 Safari/525.22

'shoe' is selected, onchange fires

Same version, but "AppleWebKit/527.3+" it works.

Garrett

Though that behavior, while shared by IE, FF and Opera, isn't required
by the standard, I think. The W3C site just says that when focus is
lost, and the selection has changed, then it should fire. To get changes
as you type, portably, I think I need to have an onkey event, and live
with the fact that in some browsers I get both the onkey and onchange
events.

 

[Thomas 'PointedEars' Lahn]

Though that behavior, while shared by IE, FF and Opera, isn't required by
the standard, I think.

You are mistaken.

The W3C site

That *is* the standard, not just a "W3C site".

just says that when focus is lost, and the selection has changed, then it
should fire.

And the element did not lose focus, did it?

To get changes as you type, portably, I think I need to have an onkey
event, and live with the fact that in some browsers I get both the onkey
and onchange events.

Or this bug could simply be fixed in WebKit so as to comply with the
standard and make this feature interoperable again.


PointedEars

 

[Chris Riesbeck]

You are mistaken.


That *is* the standard, not just a "W3C site".


And the element did not lose focus, did it?

Typing in the menu does not lose focus. Therefore, no onchange is
required to be fired. However onchange is fired in IE, FF, and Opera.
Hence I said this behavior is not portable. Are you saying onchange
should be fired according to the standard?

 

[Thomas 'PointedEars' Lahn]

Typing in the menu does not lose focus. Therefore, no onchange is
required to be fired. However onchange is fired in IE, FF, and Opera.

Indeed, I did not know that since I seldom listen to `change' events on
`select' controls with size > 1.

Hence I said this behavior is not portable.

You are not making much sense here, though. Since all major DOMs do that,
including the WebKit DOM (with the exception of prefix selection, which is a
bug that will probably be fixed in the next release), isn't it instead that
this behavior *is* portable/interoperable?

Are you saying onchange should be fired according to the standard?

Either that, or I overlooked something in the standard (unlikely), or this
behavior should become the standard (since it appears to be interoperable).
However, the problem with the latter would be that the `change' event
definition would become more complicated and bound to a particular markup
language, which I don't think would be a Good Thing.


PointedEars

 

[dhtml]

Though that behavior, while shared by IE, FF and Opera, isn't required
by the standard, I think. The W3C site just says that when focus is
lost, and the selection has changed, then it should fire. To get changes
as you type, portably, I think I need to have an onkey event, and live
with the fact that in some browsers I get both the onkey and onchange
events.

You're right: That behavior is not required; "when" and "only when" are
not the same. This is acceptable behavior, though the spec should
mention this behavior.

Take the w3c's example "ONCHANGE attribute for SELECT elements"[2].
(This is really an example, not a test).

The example does not follow the specification for onchange, but expects
that onchange will fire regardless of the select losing focus. In order
to be a proper unit test case, mouse and key events on the SELECT and
perform assertions, test functions would include tests for bubbling,
size>1, and select-multiple.

In a select-one:

FF 3:
onchange when:
clicking and selecting
change value w/kbd and click away
change value and press return (does not submit the form)
no onchange when:
type ascii, 's' for 'shoe'
type arrow keys

Webkit:
typing ascii brings up a menu.
onchange when:
clicking and selecting
change value w/kbd and click away
change value and press return ('return' submits the form)

no onchange when:
type ascii, 's' for 'shoe'

Opera 9.5:
onchange when:
clicking and selecting
change value w/kbd and click away
change value and press return (does not submit the form).

The w3c would probably have fewer mistakes if they had good unit testing.


Another problem with onchange is that it does not bubble in IE.[1]

Garrett

[1]http://msdn.microsoft.com/en-us/library/ms536912(VS.85).aspx
[2]http://www.w3.org/WAI/UA/TS/html401/cp0102/0102-ONCHANGE-SELECT.html