Closed
Bug 964076
Opened 11 years ago
Closed 10 years ago
History dropdown of location bar steals mouse event from the Confirm Close Dialog.
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
mozilla30
Tracking | Status | |
---|---|---|
firefox27 | --- | unaffected |
firefox28 | --- | affected |
firefox29 | --- | affected |
firefox30 | --- | verified |
People
(Reporter: alice0775, Assigned: mrbkap)
References
Details
(Keywords: regression)
Build Identifier: http://hg.mozilla.org/mozilla-central/rev/611698b4a246 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20140126030203 @BenYeeHua reported on http://forums.mozillazine.org/viewtopic.php?p=13326203#p13326203 Steps to reproduce: 1.Browsing some website, open at least 2 tabs 2.Click on location bar "without" showing the droplist 3.Click Alt+F4 or 1.Browsing some website, open at least 2 tabs 2.Open a new tab, which will auto focus to the location bar 3.Click Alt+F4 Actual results: The location bar is showing the history, stay on-top and blocking the Confirm Close dialog. Expected results: The location bar should not showing anything, after clicking Alt+F4 and showing the Confirm Close dialog. regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/cbe04dbc2bd6 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131217160921 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/08dc60299942 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131217161358 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cbe04dbc2bd6&tochange=08dc60299942 Regressed by: 08dc60299942 Blake Kaplan — Bug 933483 - Don't fire events (and especially request animation frame events) when we're in a modal dialog. r=smaug
Reporter | ||
Updated•11 years ago
|
Summary: History dropdown of location bar steals focus from the Confirm Close Dialog. → History dropdown of location bar steals mouse event from the Confirm Close Dialog.
Comment 2•11 years ago
|
||
Not sure why you think I would. Blake wrote the patch.
Flags: needinfo?(ryanvm) → needinfo?(mrbkap)
Comment 3•11 years ago
|
||
I can't reproduce this, but the patch in Bug 959585 might help.
Assignee | ||
Comment 4•11 years ago
|
||
Alice, would you mind retesting once bug 959585 is checked in?
Flags: needinfo?(mrbkap)
Reporter | ||
Comment 5•11 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #3) > I can't reproduce this, but the patch in Bug 959585 might help. I applied the patch in Bug 959585 and built in locally. The testcase of Bug 959585 seems to be working well. However, unfortunately, the patch in Bug 959585 does not fix this problem.
Reporter | ||
Comment 6•11 years ago
|
||
Sorry, The flag of needinfo was cleared unexpectedly.
Flags: needinfo?(mrbkap)
Updated•11 years ago
|
Assignee | ||
Comment 7•11 years ago
|
||
I'm working on a fix for this bug in bug 956704.
Flags: needinfo?(mrbkap)
Reporter | ||
Comment 8•10 years ago
|
||
Confirmed, This was fixed on https://hg.mozilla.org/integration/mozilla-inbound/rev/e0284b21846c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140226160009
Depends on: 956704
Assignee | ||
Comment 9•10 years ago
|
||
Marking FIXED per comment 8.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
status-firefox30:
--- → fixed
Target Milestone: --- → mozilla30
Comment 10•10 years ago
|
||
This is still affected on 28/29 but we're tracking the landing of the fix in bug 956704 so untracking here.
tracking-firefox28:
+ → ---
tracking-firefox29:
+ → ---
Comment 11•10 years ago
|
||
Marking verified based on comment 8 and comment 10.
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•