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)
Core
Layout: Form Controls
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)
376 bytes,
text/html
|
Details | |
1.08 KB,
patch
|
dbaron
:
review+
neil
:
superreview+
mtschrep
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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).
Reporter | ||
Comment 1•19 years ago
|
||
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.
Comment 3•19 years ago
|
||
-> 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
Reporter | ||
Comment 4•19 years ago
|
||
This bug appeared in trunk builds of Firefox between 2005-07-14 and 2005-07-15. It is probably the cause of bug 260850 also. Could it be caused by one of these (esp. 291443)? https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=select&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2005-07-14&chfieldto=2005-07-15&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
Comment 5•19 years ago
|
||
It's better to use bonsai for determining which patch caused the bug: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-07-14+05%3A00%3A00&maxdate=2005-07-15+08%3A00%3A00&cvsroot=%2Fcvsroot
Comment 6•19 years ago
|
||
Looking at the test case, this seems like a pretty bad regression. Nothing jumped out at me during the regression window.
Comment 7•19 years ago
|
||
Bug 290354 made some event releated changes to an options element during the regression window that could be related.
Comment 8•19 years ago
|
||
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
Comment 9•19 years ago
|
||
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+
Assignee | ||
Comment 10•19 years ago
|
||
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) {
Assignee | ||
Comment 11•19 years ago
|
||
Attachment #194591 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #194591 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 12•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Attachment #194591 -
Flags: review?(dbaron)
Assignee | ||
Updated•19 years ago
|
Whiteboard: [ETA: needs layout peer review]
Attachment #194591 -
Flags: review?(dbaron) → review+
Assignee | ||
Updated•19 years ago
|
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 ]
Assignee | ||
Updated•19 years ago
|
Attachment #194591 -
Flags: approval1.8b4?
Updated•19 years ago
|
Attachment #194591 -
Flags: approval1.8b4? → approval1.8b4+
Comment 14•19 years ago
|
||
verified on mozilla1.8 branch (Win, Lin and Mac) 2005-09-07
Keywords: fixed1.8 → verified1.8
You need to log in
before you can comment on or make changes to this bug.
Description
•