Closed Bug 1370134 Opened 7 years ago Closed 7 years ago

Move to New Window sometimes results in a blank window

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1374025
Tracking Flags:
Tracking Status
firefox55 + fix-optional

People

(Reporter: birtles, Assigned: kmag)

References

Details

(Keywords: dataloss, regression, regressionwindow-wanted)

Attachments

(2 files)

Screenshot (after choosing Move to New Window on previously loaded page)
57.71 KB, image/png
Details
Screenshot (after then pressing refresh)
40.34 KB, image/png
Details 
In about the last 3 weeks I have noticed that about one quarter of the time I use "Move to New Window" from the tab's right-click menu I end up with a blank page. If I refresh, sometimes the page will show, sometimes it will not. Needless to say, any data I entered in that window is lost. I have seen this on at least two different computers so far (both Windows 10). Prior to this, the feature worked flawlessly (I use this feature quite a lot).

I don't have any tab-related extensions installed or non-default options for tabs.

Unfortunately, I have yet to find any reliable STR.

(Also, curiously, while writing this bug report I tried to reproduce this by right-clicking a non-focussed tab and somewhere along the way the tab I was writing the bug report in disappeared and was not restorable using Ctrl+Shift+T.)

[Tracking Requested - why for this release]: Dataloss regression.
Bug 629232 appears to have similar symptoms but that bug relates to the session restore feature and is 6 years old, so is not the same regression.
Also, for what it's worth, I am using Nightly so it's possible this regression is only present when the Nightly-only photon work is enabled.
This just happened again, but I notice the URL bar is not empty after all.
Summary: Move to New Window sometimes results in a blank window and empty URL bar → Move to New Window sometimes results in a blank window
In this case, I pressed F5 to refresh the page and the title and URL field were cleared leaving the window completely blank.
I have seen this on both my work profile and home profile so I don't think it's a corrupt profile to blame.
I wonder if this is related to the stuff I've been seeing in bug 1364563...

Are both of the machines you're seeing this on Windows machines?
Flags: needinfo?(bbirtles)
Is this the same as bug 1362462?
(In reply to Mike Conley (:mconley) from comment #7)
> I wonder if this is related to the stuff I've been seeing in bug 1364563...
> 
> Are both of the machines you're seeing this on Windows machines?

Yes.

(In reply to :Gijs from comment #8)
> Is this the same as bug 1362462?

Quite likely. I could definitely repro with yesterday's nightly, but perhaps that didn't include the fix from that bug.
Flags: needinfo?(bbirtles)
I am still seeing this in today's nightly so this is not the same as bug 1362462.

Adding Kris to CC since he left a comment in bug 1362462 saying that he was investigating some follow-up issues related to that bug.
Are you seeing it as often as you were before? My understanding from bug 1362462 is that has been happening for some time, but the patches from bug 1353060 made it happen more often. I wasn't able to reproduce this after the changes bug 1362462, so it's likely that it just returned to its previous severity after they landed.
Yes. I used to never see it at all (I use "Move to New Window" frequently for reviewing patches) and as of about 3 weeks ago I started seeing it often. This morning out of using "Move to New Window" once, I saw the bug once. I'll let you know if I see a drop in frequency over the next few days.
Of the 2~3 times I used "Move to New Window" so far today, it has failed twice so I don't think this has decreased in frequency.
I also wonder if this is somehow related at all to the Windows Creators Update that Microsoft is rolling out.
It's possible I guess. I've been running build 1703 since it was released back in April, though. Like Brian, this issue only started happening for me in the last couple weeks.
Next time this happens, I'd love it if somebody could open up the Browser Toolbox and inspect the <xul:browser> for the misbehaving tab. Can you tell me if there's a "blank" attribute set to "true" on it?
I'm going to try to figure out exactly what's causing the flakiness here in the next couple of days, but a fix might have to wait until after the merge and be uplifted.
Assignee: nobody → kmaglione+bmo
I run my own local builds - if there's any sort of logging patch that might be useful to build with, I'd be happy to do so.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #20)
> I run my own local builds - if there's any sort of logging patch that might
> be useful to build with, I'd be happy to do so.

For the issues _I'm_ worried about, you could set browser.tabs.remote.logSwitchTiming to true, and then when this issue comes up, open the Browser Console immediately and send me the contents (note that URLs for tabs are captured in the logging spew).
In reply to comment 18, here's the browser element from a recent occurrence (on macos, Nightly 55 from 2017-06-09).  There's no "blank" attribute, and I didn't have the log setting from comemnt 21 enabled...

<xul:browser xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" anonid="initialBrowser" type="content" message="true" messagemanagergroup="browsers" primary="true" xbl:inherits="tooltip=contenttooltip,contextmenu=contentcontextmenu,autocompletepopup,selectmenulist,datetimepicker" xmlns:xbl="http://www.mozilla.org/xbl" contextmenu="contentAreaContextMenu" tooltip="aHTMLTooltip" datetimepicker="DateTimePickerPanel" selectmenulist="ContentSelectDropdown" autocompletepopup="PopupAutoComplete" clickthrough="never" autoscrollpopup="autoscroller" remote="true" remoteType="web"/>
Just mentioning here that I'm seeing the same problem on Mac, so it's not Windows-specific.
I'm still hitting this every day. I see the same as Andrew for xul:browser.

<xul:browser xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" anonid="initialBrowser" type="content" message="true" messagemanagergroup="browsers" primary="true" xbl:inherits="tooltip=contenttooltip,contextmenu=contentcontextmenu,autocompletepopup,selectmenulist,datetimepicker" xmlns:xbl="http://www.mozilla.org/xbl" datetimepicker="DateTimePickerPanel" selectmenulist="ContentSelectDropdown" autocompletepopup="PopupAutoComplete" contextmenu="contentAreaContextMenu" tooltip="aHTMLTooltip" clickthrough="never" autoscrollpopup="autoscroller" remote="true" remoteType="web"/>

I'll try setting browser.tabs.remote.logSwitchTiming next.
I took the log after setting browser.tabs.remote.logSwitchTiming to true.

When I moving https://bugzilla.mozilla.org/show_bug.cgi?id=1365472 to a new tab I get:

    Warning: ‘nsIOService::NewChannelFromURI()’ deprecated, please use ‘nsIOService::NewChannelFromURI2()’ utils.js:413:13
    START
    Initial tab is loaded?: true
    requestTab 7(https://bugzilla.mozilla.org/show_bug.cgi?id=1365855) 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VR(+) 7:(-) 8:(-) 
    Loading tab 7(https://bugzilla.mozilla.org/show_bug.cgi?id=1365855)
    Tab should be blank: false
    Requested tab is remote?: true
    done 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:V(+) 7:LR(+?) 8:(-) 
    Tab should be blank: false
    Requested tab is remote?: true
    Switch to tab 7 - 6(https://bugzilla.mozilla.org/show_bug.cgi?id=1365855)
    done 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VLR(+?) 7:(-) 
    Tab should be blank: false
    Requested tab is remote?: true
    done 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VLR(+?) 7:(-) 
    onLayersReady(6, true) 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VLR(+?) 7:(-) 
    DEBUG: tab switch time = 167
    Tab should be blank: false
    Requested tab is remote?: true
    DEBUG: spinner time = 145
    FINISH
    done 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VR(+) 7:(-) 

(The URL https://bugzilla.mozilla.org/show_bug.cgi?id=1365855 is, it seems, for the page that came into focus as a result.)

By comparison, when I then moved https://bugzilla.mozilla.org/show_bug.cgi?id=1365855 to a new tab, it succeeded and left me with the following log:

    Warning: ‘nsIOService::NewChannelFromURI()’ deprecated, please use ‘nsIOService::NewChannelFromURI2()’ utils.js:413:13
    START
    Initial tab is loaded?: true
    requestTab 7(https://docs.google.com/spreadsheets/d/1iDkLyj06ZnAFynoIRW8uawZsHNS7Fl_ZTO7sbqUDkTE/edit#gid=1420354661) 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VR(+) 7:(-) 
    Loading tab 7(https://docs.google.com/spreadsheets/d/1iDkLyj06ZnAFynoIRW8uawZsHNS7Fl_ZTO7sbqUDkTE/edit#gid=1420354661)
    Tab should be blank: false
    Requested tab is remote?: true
    done 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:V(+) 7:LR(+?) 
    Tab should be blank: false
    Requested tab is remote?: true
    Switch to tab 7 - 6(https://docs.google.com/spreadsheets/d/1iDkLyj06ZnAFynoIRW8uawZsHNS7Fl_ZTO7sbqUDkTE/edit#gid=1420354661)
    done 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VLR(+?) 
    Tab should be blank: false
    Requested tab is remote?: true
    done 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VLR(+?) 
    onLayersReady(6, true) 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VLR(+?) 
    DEBUG: tab switch time = 216
    Tab should be blank: false
    Requested tab is remote?: true
    DEBUG: spinner time = 196
    FINISH
    done 0:(-) 1:(-) 2:(-) 3:(-) 4:(-) 5:(-) 6:VR(+)
See Also: → 1374025
I'm hitting this on Mac and at the moment it is 100% reproducible for me with the following steps.

1) Setup:
   A window with 7 pinned tabs and 5 unpinned tabs,
   with GMail open in tab 1 viewing a "Thank you for your try submission" email
   click on a link from the mail message to
      https://treeherder.mozilla.org/#/jobs?repo=try&revision=2298f62961dc04a7343d6c39b2f8450da3bd2296
 
2) The new tab opens in the same window and fully loads

3) Right-click on the tab title and select "Move to New Window"
   The window opens in a new tab with the correct URL in the URL bar, but the tab is blank.
(In reply to Haik Aftandilian [:haik] from comment #26)
> I'm hitting this on Mac and at the moment it is 100% reproducible for me
> with the following steps.
> 
> 1) Setup:
>    A window with 7 pinned tabs and 5 unpinned tabs,
>    with GMail open in tab 1 viewing a "Thank you for your try submission"
> email
>    click on a link from the mail message to
>      
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=2298f62961dc04a7343d6c39b2f8450da3bd2296
>  
> 2) The new tab opens in the same window and fully loads
> 
> 3) Right-click on the tab title and select "Move to New Window"
>    The window opens in a new tab with the correct URL in the URL bar, but
> the tab is blank.

I expect this is really the same issue as bug 1374025, which indeed explicitly calls out window.open()'d windows. Not sure if gmail uses that or if it just also happens with <a href="..." target="_blank">links</a>. Either way, it seems likely it's the same issue.
Kris, should we close this as a dupe of Bug 1374025?
Flags: needinfo?(kmaglione+bmo)
Yeah, I think so.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(kmaglione+bmo)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: