1370134 - Move to New Window sometimes results in a blank window

Status: RESOLVED DUPLICATE of bug 1374025

(Firefox :: Tabbed Browser, defect)

Description

[Brian Birtles (:birtles)]

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.

Comment 1

[Brian Birtles (:birtles)]

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.

Comment 2

[Brian Birtles (:birtles)]

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.

Comment 3

[Brian Birtles (:birtles)]

This just happened again, but I notice the URL bar is not empty after all.

Comment 4

[Brian Birtles (:birtles)]

Attachment: Screenshot (after choosing Move to New Window on previously loaded page)

Comment 5

[Brian Birtles (:birtles)]

Attachment: Screenshot (after then pressing refresh)

In this case, I pressed F5 to refresh the page and the title and URL field were cleared leaving the window completely blank.

Comment 6

[Brian Birtles (:birtles)]

I have seen this on both my work profile and home profile so I don't think it's a corrupt profile to blame.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 8

[:Gijs (he/him)]

Is this the same as bug 1362462?

Comment 9

[Brian Birtles (:birtles)]

(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.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 55.

Comment 11

[Brian Birtles (:birtles)]

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.

Comment 12

[Kris Maglione [:kmag]]

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.

Comment 13

[Brian Birtles (:birtles)]

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.

Comment 14

[Brian Birtles (:birtles)]

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.

Comment 16

[Mike Conley (:mconley) (:⚙️)]

I also wonder if this is somehow related at all to the Windows Creators Update that Microsoft is rolling out.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 19

[Kris Maglione [:kmag]]

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.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 21

[Mike Conley (:mconley) (:⚙️)]

(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).

Comment 22

[Andrew Swan [:aswan]]

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"/>

Comment 23

[:Felipe Gomes (needinfo for replies!)]

Just mentioning here that I'm seeing the same problem on Mac, so it's not Windows-specific.

Comment 24

[Brian Birtles (:birtles)]

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.

Comment 25

[Brian Birtles (:birtles)]

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(+)

Comment 26

[Haik Aftandilian [:haik]]

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.

Comment 27

[:Gijs (he/him)]

(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.

Comment 28

[Mike Taylor [:miketaylr]]

Kris, should we close this as a dupe of Bug 1374025?

Comment 29

[Kris Maglione [:kmag]]

Yeah, I think so.

Comment 30

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracked in the duplicate.