Open
Bug 1349436
Opened 8 years ago
Updated 2 years ago
Tab moved to new window is sometimes invisible if notifications from site identity block appear
Categories
(Firefox :: Site Identity, defect, P3)
Tracking
()
REOPENED
People
(Reporter: 684sigma, Unassigned)
References
Details
(Whiteboard: [fxprivacy])
I have a problem with Firefox Beta 53. It doesn't happen in Beta 52, ESR 45.
Sometimes when I move tab to new window, that new window isn't visible. I have to press Alt+Tab twice to focus it.
Here're 2 ways to reproduce the bug, with the same result:
First:
1. Open https://gauntface.github.io/simple-push-demo/
2. Click "Enable Push Notifications" on the page
3. Open new tab, move that tab to new window
Second:
1. Open https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/Using_geolocation
2. Click "Show my location" button on the page
3. Open new tab, move that tab to new window
Result: new window is created. Old window isn't focused, but it appears ABOVE the new window, making it invisible.
Expected: newly created window should be visible.
Has STR: --- → yes
Keywords: regression
Comment 1•8 years ago
|
||
Thanks for reporting. I can reproduce on Windows but not on OSX, so that might be a specific issue for Windows. I'm not sure if we can easily solve this, however. Neil, do you happen to know why this is happening?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(enndeakin)
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Whiteboard: [fxprivacy] [triage]
Comment 2•8 years ago
|
||
It's reproducible on Firefox Nightly 55.0a1, Firefox Aurora 54.0a2 and on Firefox Beta 53.0b5 on Windows 10 x 64.
It's not reproducible on Ubuntu 16.04 x64.
Updated•8 years ago
|
Keywords: regressionwindow-wanted
Comment 3•8 years ago
|
||
Last good revision: abecacadf9d3006029eb2208445521f495e80a70
First bad revision: 2e3bef583561c4812e6093a5ec639b1a58d0ab18
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=abecacadf9d3006029eb2208445521f495e80a70&tochange=2e3bef583561c4812e6093a5ec639b1a58d0ab18
Keywords: regression,
regressionwindow-wanted
Comment 4•8 years ago
|
||
Thanks!
Comment 5•8 years ago
|
||
Is this fixed by bug 1320361?
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(enndeakin)
Resolution: --- → FIXED
Updated•8 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 6•8 years ago
|
||
This is one of those odd behaviours that Windows has when switching focus while a child popup is open.
The easiest fix would be to close the notification popup in this case.
Comment 7•8 years ago
|
||
(In reply to Neil Deakin from comment #6)
> This is one of those odd behaviours that Windows has when switching focus
> while a child popup is open.
>
> The easiest fix would be to close the notification popup in this case.
We can't close the notification since it's persistent, should only be dismissed by explicit user action. Is this not solveable then?
Comment 8•8 years ago
|
||
Actually, the issue here is that the popup isn't open before the tab is dragged, and when the tab is dragged out to a new window, the old window now switches to the first tab that has the notification panel associated with it. The notification panel gets reopened causing its panel and parent window to come to the front.
From a cursory glance, there are a number of codepaths in PopupNotifications.jsm from which the popup can be reopened (basically any call to _update), but only one (the show function) which it checks if the window is active before trying to open the notification popup.
I would suggest that the other callers should be doing the same.
Updated•8 years ago
|
Priority: -- → P3
Whiteboard: [fxprivacy] [triage] → [fxprivacy]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•