Closed
Bug 306437
Opened 20 years ago
Closed 20 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•20 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•20 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•20 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•20 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•20 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•20 years ago
|
||
Bug 290354 made some event releated changes to an options element during the
regression window that could be related.
Comment 8•20 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•20 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•20 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•20 years ago
|
||
Attachment #194591 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #194591 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 12•20 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•20 years ago
|
Attachment #194591 -
Flags: review?(dbaron)
| Assignee | ||
Updated•20 years ago
|
Whiteboard: [ETA: needs layout peer review]
Attachment #194591 -
Flags: review?(dbaron) → review+
| Assignee | ||
Updated•20 years ago
|
Status: NEW → RESOLVED
Closed: 20 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•20 years ago
|
Attachment #194591 -
Flags: approval1.8b4?
Updated•20 years ago
|
Attachment #194591 -
Flags: approval1.8b4? → approval1.8b4+
Comment 14•20 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
•