178288 - select tag doesn't always fire onchange events

Status: VERIFIED DUPLICATE of bug 126379

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Daniel Miladinov]

I'm running Mozilla 1.0.1 

(Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020826)

on Windows 98 SE, and I'm developing a page site that reads a listing of files
from a database and presents them as options in a select tag.  The user is
prompted to select a particular file to view its attributes (filesize,
permissions, owner, etc).

This information is created server-side via my php script and is stored
client-side in javascript array literals.  I've set the select tag's onChange to
call a function that displays the contents of the array corrsponding to the file
the user selects.  However, the onchange event only fires when clicking on the
select tag with the mouse.  If the select tag still has focus, you can use the
mouse scroll wheel or the up/down keys to scroll through the options, but when
you do it that way, no onchange event is fired.  I don't think that's how it's
supposed to work.  Is this a bug, or do I also need to listen for key events as
well?  

Thanks in advance for your timely repsonse!

Comment 1

[Phil Schwartau]

Browser, not engine ---> Event Handling

Dan: could you attach a reduced testcase to this bug via the 
"Create a New Attachment" link above? This should be of the
minimum size needed to exhibit the bug; thanks.

Also - have you tried a more recent build than 20020826?
Perhaps this is something that is fixed in more recent builds - 

Comment 2

[Daniel Miladinov]

Attachment: Some html and javascript source demonstrating the bug

This file demonstrates how selecting an option from the drop down list only
causes the onchange event to fire when using the mouse to select the option. 
However, if you have the drop-down list in focus and use the up or down keys to
select the options, the event doesn't fire even though the tag's value IS
changing.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is done on purpose to allow people using the keyboard or scrollwheel to
actually select the option they want instead of having onchange fire on every
option along the way.  This is identical to the way a text input's onchange does
not fire as you type in it.  The onchange _does_ fire if the <select> loses
focus or if the user presses enter to indicate that she is done changing the value.

Comment 4

[Wesha]

v.

Comment 5

[Phil Schwartau]

*** Bug 178727 has been marked as a duplicate of this bug. ***

Comment 6

[Tommy Morgan]

I believe the event should be fired when the selection is changed with the
keyboard.  For that matter, I think text inputs should too.  The only reason I
have been able to think of as to why you would not want keyboard manipulation to
fire the onchange event for a select is when you are redirecting based on the
selection (so a major functionality change has been made just because someone
doesn't want to place a small "go" button on a page?).

I have created many pages in the past that use JavaScript extensively and depend
on the event firing even with keyboard manipulation (without the control losing
focus).  Older versions of Navigator do this as does Internet Explorer.  I would
prefer to see an attribute added to the select tag (and text inputs) that lets
me choose which behavior I want -- something along the lines of onchangemode
with possible values of full or limited, with full being the default for select
and limited being the default for text.

If the functionality is left as is, the "standard" behavior would have to be
implemented via relatively advanced scripting.  That just doesn't make sense to
me.  It means this becomes yet another area where folks have to make their code
way more convoluted than it should be for the sake of cross-browser
compatibility.  An attribute would give authors more flexibility while not
breaking compatibility.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> is when you are redirecting based on the selection 

Which is what at least 90% of onchange handlers on <select> actually do in the
real world.  The next 6-7% run data-validation code, which should not be run
until the user has actually made a selection.

Users who are using key nav (who were the people that _requested_ this change,
overwhelmingly) know that hitting enter will trigger the onchange, if any.

Comment 8

[Tommy Morgan]

The selection changes when a user "arrows" through the options.  My opinion is
that onchange should be fired because the change has indeed occurred.

This new behavior not only breaks functionality that has existed for years but
also creates an incompatibility with IE.  I can understand the desire to have
the new behavior in some cases, but I think the addition of an attribute to
toggle the behavior is a better solution than a wholesale change in behavior.  I
don't think one should have to write compatibility code just to support such
basic functionality equally in all browsers.

Boris:  Your message did not address the issue of my attribute proposal.  What
are your opinions on that matter?  Just seems to me if Moz can have blink it can
have an extra attribute on some form elements as the attribute could appease
everyone whereas blink just makes them mad ;).

Comment 9

[Boris Zbarsky [:bzbarsky]]

I think that the attribute proposal would be best brought up in the relevant
newsgroups, not here, where I'm the only person seeing it....

Keep in mind, the change is made for the benefit of _users_ who find the current
behavior of IE unbearable.  It's as simple as that.

Comment 10

[Tommy Morgan]

I am new to bugzilla, but I hope we are not the only two seeing this discussion.
 This is assigned to someone with a netscape.com email address and the reporter
seems to feel the same way that I do -- that the new functionality is what is
broken and unbearable.  I am both a developer and a user.  It is _broken_ in its
current state.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Ok, I was wrong.  Phil is also seeing this.  joki quit from netscape about a
week ago, so I can guarantee that he's not seeing this.  I'm serious about the
newsgroups; the decision to change the behavior was made by the keyboard nav and
form controls component owners, not by events in any case.

Comment 12

[Tommy Morgan]

Boris,
What newsgroup should I participate in?  I am posting this here for the benefit
of anyone with the same question in the future.  Thanks for your guidance on
this issue.

Comment 13

[Boris Zbarsky [:bzbarsky]]

For this?  I'd suggest netscape.public.mozilla.accessibility

Comment 14

[Jesse Ruderman]

This is a dup of bug 126379.

Comment 15

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 126379 ***

Comment 16

[Jesse Ruderman]

>I believe the event should be fired when the selection is changed with the
>keyboard.  For that matter, I think text inputs should too.

Try using the oninput attribute.  Oninput fires whenever you change the text in
a text box, while onchange only fires when you're done editing it.  Mozilla only
supports oninput for text inputs, but I think it would make sense to make it
work for <select size=1> as well.

Comment 17

[Trix Supremo]

verified dupe