Closed Bug 306437 Opened 19 years ago Closed 19 years ago

change event fires twice for HTML select (mousedown & mouseup)

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: mikecaines, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: regression, testcase, verified1.8, Whiteboard: [ETA: testing on trunk, although i am positive it is correct and won't regress anything ])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050830 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050830 Firefox/1.0+

A change event is fired twice (as compared to Internet Explorer) when changing
the selection of an HTML select. One fires on mousedown and the other on
mouseup. If the same selection change is made with the keyboard, only one change
event is fired. The behaviour should be consistent.

Reproducible: Always

Steps to Reproduce:
1.Change the selection of the select element with the mouse
2.Note that the TWO alerts are displayed

Actual Results:  
Two alerts are displayed


Expected Results:  
One alert is displayed

Note the difference in change event firing between the mouse and keyboard, and
Internet Explorer and Mozilla (mouse).
Attached file Testcase
Keywords: testcase
Assignee: events → nobody
Component: Event Handling → Layout: Form Controls
QA Contact: ian → layout.form-controls
Reproducible with SeaMonkey/20050828 but WFM with Mozilla 1.8b1 and Deer Park a2.
-> New, All/All. This is potentially a website breaking bug, so nominating for
1.8b5.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b5?
Keywords: regression
OS: Windows XP → All
Hardware: PC → All
Blocks: 260850
Looking at the test case, this seems like a pretty bad regression. Nothing
jumped out at me during the regression window.
Bug 290354 made some event releated changes to an options element during the
regression window that could be related. 
This is caused by the patch for bug 290354, backing out the listcontroleframe
part of that patch fixes the bug for me in my local debug build.
Blocks: 290354
Aaron, this looks pretty nasty. Can you please help us get this fixed ASAP. I'd
like to not ship b4 with this problem.
Assignee: nobody → aaronleventhal
Flags: blocking1.8b5? → blocking1.8b4+
Thanks Martijn, that was a great help. Backing out this small bit fixes it.

@@ -2708,6 +2718,9 @@ nsListControlFrame::MouseDown(nsIDOMEven
     // Handle Like List
     CaptureMouseEvents(GetPresContext(), PR_TRUE);
     mChangesSinceDragStart = HandleListSelection(aMouseEvent, selectedIndex);
+    if (mChangesSinceDragStart) {
+      UpdateSelection(); // dispatch event, update combobox, etc.
+    }
   } else {
     // NOTE: the combo box is responsible for dropping it down
     if (mComboboxFrame) {
Attachment #194591 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #194591 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 194591 [details] [diff] [review]
Don't know how the UpdateSelection() call snuck in. It's clearly wrong.

I'm not a layout peer but the change looks good.
Attachment #194591 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #194591 - Flags: superreview+
Attachment #194591 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #194591 - Flags: review?(dbaron)
Whiteboard: [ETA: needs layout peer review]
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [ETA: needs layout peer review] → [ETA: testing on trunk, although i am positive it is correct and won't regress anything ]
Attachment #194591 - Flags: approval1.8b4?
Verified on 9-5-07 Trunk build.   
Status: RESOLVED → VERIFIED
Attachment #194591 - Flags: approval1.8b4? → approval1.8b4+
Keywords: fixed1.8
verified on mozilla1.8 branch (Win, Lin and Mac) 2005-09-07
Keywords: fixed1.8verified1.8
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: