70094 - onchange handler for selects will fire even if *no* change occurs

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Joseph Myers]

If you click and open a select menu then click out, JavaScript will sometimes
run the onchange event handler for the select menu even if no change was made.
Apparently just dragging the mouse over another option will trigger the onchange
event even if you don't really choose that option.

I noticed it at drugstore.com while searching. There is a menu "Choose Your
Brand," which will update the page when changed (using an onchange event
handler). After dragging the mouse through the options and clicking out of the
box the page was reloaded without really having a change made to the select menu.

Comment 1

[Fabian Guisset]

reassigning to html form controls. This might be covered by bug 62753

Comment 2

[Phil Schwartau]

Setting default owner and QA - 

Comment 3

[Vladimir Ermakov]

QA Contact Update

Comment 4

[Robert Thörncrantz]

I just wanted to add that I see this problem under linux too.
I can see it with the 0.8-release (Id: 2001021503) as well as the latest nightly
build, Id: 2001032608

Comment 5

[Jacob Kjome]

I'm seeing this on http://www.kaspersky.com/

Just try selecting a different language.

1. drop down the language list
2. click the mouse somewhere else on the page to "avoid" the onchange event
3. watch as the onchange event fire even though there was no change in the
select box

Please note a quirk in the html of this page: script and form elements occur
before the html element.

Also, this should probably not be a Mac-only bug.  I'm on win2k using build
#2001041508

I'll try to post a simplified testcase in a bit...

Jake

Comment 6

[Jacob Kjome]

Attachment: simple testcase showing incorrect firing of onChange event

Comment 7

[Jacob Kjome]

I'd recommend changing platform and OS to "All" because this is happening on 
Mac and Win32.  Also, the priority and severity should be bumped up given that 
using onchange in select boxes to navigate is pretty common on the top 100 
sites...or at least a lot of sites I look at and this bug makes those sites 
very difficult to deal with as a user.

Jake

Comment 8

[Keyser Sose]

Marking NEW based on confirmation.

Comment 9

[Jacob Kjome]

Bug 80040 is almost definitely a dup of this

jake

Comment 10

[Keyser Sose]

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

Comment 11

[Jacob Kjome]

bug 79073 is a dup of this...or the other way around

jake

Comment 12

[Keyser Sose]

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

Comment 13

[Keyser Sose]

Adding keywords from dupe

Comment 14

[John Morrison]

changing summary (hey, I'm biased to mine :-]). 

Also clearing milestone. This is a pretty serious change in the way that 
a <select> works. I don't think we should break with 5+ years of behaviour.

Comment 15

[Jacob Kjome]

Looks like this bug has been fixed in build #2001060804 on Win2k (SP2)!!!

Can anyone verify this?

I saw one quirk that I thought was a bug in Mozilla, but it is, more likely, a 
bug in IE5.5 SP1.  In the testcase, if you select a new language, you never 
actually see the selected language in the list, rather, you only see the 
default language even as the page is being routed to a new page specified by 
the language you selected.  IE5.5 *does* change the language so you can see it 
and upon hitting the "back" button, you come back to the page with the language 
you selected actually selected.

However, the script attempts to reset the selectedIndex to the default 
immediately after it changes the location object of the current window.  
Mozilla sees this and resets it to the default before the page is left making 
it so you never witness the change visually.  IE5.5 seems to miss running that 
part of the script, so you get the normal behavior of Select boxes.

So, if anyone sees that behavior and thinks it is a bug, it is most likely 
not...that is unless Mozilla isn't supposed to evaluate any more scripts for 
the page after the location object has been changed...but I don't think that is 
true.

Long story short.  This bug is fixed.  Leaving status alone until someone else 
verifies.

Nice Work!!! :-)

Jake

Comment 16

[John Morrison]

I haven't pulled down today's trunk build (my bad), but it was not fixed in 
yesterday's trunk, so I assume that it was fixed with rods' batch-o-select-logic
checkin from yesterday. But I'll let Rod mark it FIXED.

Comment 17

[rods (gone)]

This did get fixed with my batch-o-matic checkin

Comment 18

[Vladimir Ermakov]

verifying fixed on build 2001-06-13-09-trunk windows 98

Comment 19

[Marius Andreiana]

this bug it's still in 0.9.5 (released after verifier's comment), should I try
with 0.9.6?

Comment 20

[Jacob Kjome]

Marius,

Most of the originally reported behavior is fixed and should have been for the 
0.9.5 build.  That behavior was that any time you dropped down the list you 
were now doomed to have the onchange event occur because any click to discard 
the list anywhere on the page caused the onchange event to occur.  That is 
definitely not happening currently.

However, there still is some bad behavior for which I filed bug 87352.  If the 
list is dropped down and then the previously selected item is clicked, the 
onchange event is fired when it shouldn't be...because there was no change.  I 
wonder what would happen on a multiselect list with an onchange event?  Would 
it wait until the alt key is lifted before firing the onchange event?  Anyway,  
please vote for bug 87352 if you think it should get more priority (I think it 
should be fixed soon!).

Jake

Comment 21

[Marius Andreiana]

Jake,

thanks for the comment, I was talking about the bug you described.