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)

28 Branch
x86_64
Windows 7
defect
Not set
normal

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
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.
Ryan, Can you have a look at this?
Flags: needinfo?(ryanvm)
Not sure why you think I would. Blake wrote the patch.
Flags: needinfo?(ryanvm) → needinfo?(mrbkap)
I can't reproduce this, but the patch in Bug 959585 might help.
Alice, would you mind retesting once bug 959585 is checked in?
Flags: needinfo?(mrbkap)
(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.
Sorry, The flag of needinfo was cleared unexpectedly.
Flags: needinfo?(mrbkap)
Assignee: nobody → mrbkap
I'm working on a fix for this bug in bug 956704.
Flags: needinfo?(mrbkap)
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
Marking FIXED per comment 8.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
This is still affected on 28/29 but we're tracking the landing of the fix in bug 956704 so untracking here.
Marking verified based on comment 8 and comment 10.
Status: RESOLVED → VERIFIED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.