select tag doesn't always fire onchange events

VERIFIED DUPLICATE of bug 126379

Status

()

Core
Event Handling
--
minor
VERIFIED DUPLICATE of bug 126379
15 years ago
15 years ago

People

(Reporter: Daniel Miladinov, Assigned: joki (gone))

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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

15 years ago
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 - 
Assignee: rogerl → joki
Component: JavaScript Engine → Event Handling
QA Contact: pschwartau → rakeshmishra
(Reporter)

Comment 2

15 years ago
Created attachment 105100 [details]
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

15 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID

Comment 4

15 years ago
v.
Status: RESOLVED → VERIFIED

Comment 5

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

Comment 6

15 years ago
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

15 years ago
> 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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

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

Comment 14

15 years ago
This is a dup of bug 126379.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---

Comment 15

15 years ago

*** This bug has been marked as a duplicate of 126379 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → DUPLICATE

Comment 16

15 years ago
>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.

Updated

15 years ago
QA Contact: rakeshmishra → trix

Comment 17

15 years ago
verified dupe
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.