Closed Bug 629232 Opened 9 years ago Closed Last year

Move to New Window results in blank page and empty location bar for unloaded tab

Categories

(Firefox :: Session Restore, defect, critical)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
Firefox 64
Tracking Status
blocking2.0 --- -
firefox-esr60 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- verified
firefox65 --- verified

People

(Reporter: rjohnson19, Assigned: jaws)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: dataloss, regression)

Attachments

(1 file, 1 obsolete file)

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110126 Firefox/4.0b11pre

Using the Move to New Window menu item on a tab that has not been loaded by Session Restore results in a blank page instead of the tab.

Steps to Reproduce:
1. Set to restore sessions (Show my windows and tabs from last time).
2. In about:config, set browser.sessionstore.max_concurrent_tabs to 0.
3. Open a new tab and navigate to a page (such as http://www.mozilla.org/)
4. Switch to another tab so the new tab doesn't load on startup.
5. Close and reopen Firefox.
6. Right click on the tab you opened and select Move to New Window

Actual Results:
A new window opens with a blank tab.

Expected Results:
The site you opened is opened in a new window.
Same happens for me on OS X. This is clearly a dataloss bug because there is no way to get back the URL of the formerly not loaded page. Asking for blocking.
Severity: normal → critical
blocking2.0: --- → ?
Keywords: dataloss
OS: Windows 7 → All
Hardware: x86 → All
Summary: Move to New Window results in blank page for unloaded tab → Move to New Window results in blank page and empty location bar for unloaded tab
Alas, browser.sessionstore.max_concurrent_tabs=0 isn't a supported setting, so I can't see us blocking on this.
blocking2.0: ? → -
Component: Tabbed Browser → Session Restore
QA Contact: tabbed.browser → session.restore
(In reply to comment #2)
> Alas, browser.sessionstore.max_concurrent_tabs=0 isn't a supported setting

It's not, but this can happen if it's a tab that hasn't been restored yet with default settings.

Bug 599909 (which will land soon) is going to make this better so at least the URL is in the location bar. Things will still be a little weird with session history.

If I can get a proper fix, I'd want to take in a .x (how do I set flags to say that?)
Maybe the restoreTab API can be made public and called in swapBrowsersAndCloseOther?
Since "Don't load tabs until selected" option is on by default now, this bug needs more attention.
Same experience here with FF 20.0 on Linux.
Depends on: 1109229
Opening up a new window and not replacing its tab with the selected unloaded tab is caused by `otherTabListener` being undefined if the other tab is not loaded.

I don't know how to write a proper unit test for this, but this does appear to fix the bug.
I have been seeing this intermittently in Nightly. Just happened again in 56.0a1 (2017-07-18) (64-bit) on MacOS Sierra 10.12.4. Each time I would consider filing a bug about it, I would run into problems providing a reproducible example.

However, this time it has happened with Bugzilla. I had https://bugzilla.mozilla.org/show_bug.cgi?id=1128392 open and used the tab "Move to New Window". The new window was created but was blank and the correct URL shown in the address bar. I forced a refresh (command-R), and the address bar changed to "Search or enter address". Window is still blank.

Sure, it could be that my profile is old, but I like my old profile. :-)
(In reply to Kathleen Wilson from comment #8)
> I have been seeing this intermittently in Nightly. Just happened again in
> 56.0a1 (2017-07-18) (64-bit) on MacOS Sierra 10.12.4. Each time I would
> consider filing a bug about it, I would run into problems providing a
> reproducible example.
> 
> However, this time it has happened with Bugzilla. I had
> https://bugzilla.mozilla.org/show_bug.cgi?id=1128392 open and used the tab
> "Move to New Window". The new window was created but was blank and the
> correct URL shown in the address bar. I forced a refresh (command-R), and
> the address bar changed to "Search or enter address". Window is still blank.
> 
> Sure, it could be that my profile is old, but I like my old profile. :-)

So, interesting thing is that I am only able to reproduce this from one of the windows I currently have open. It works correctly from the other windows I have open.

Let me know if you would like me to set some debugging flags and save the output...
See Also: → 1387366
This still happens on Nightly 58.0a1.
> Move to New Window results in blank page and empty location bar for unloaded tab

Reproducible with Waterfox 56.1.0_10 and Firefox 59.0.2_4,1 on FreeBSD-CURRENT. 

----

(In reply to Henrik Skupin (:whimboo) from comment #1)

> … on OS X. This is clearly a dataloss bug because there is
> no way to get back the URL of the formerly not loaded page. …

Not reproducible – no loss – with either browser on FreeBSD-CURRENT: 

- the page remains, in its tab, in the window away from which it should move.
I am seeing this in tonight's Nightly (23rd of June 2018)

My Steps to reproduce are:

1) Have a session with multiple tabs open

2) Restart browser and restore previous session *

2a) (One tab per window will fully load at this point; other tabs are now "unloaded" until/unless they're focused.)

3) On any unloaded tab, [Right Click] the tab -> [Click] on "Move to New Window" in right click menu

Actual Result: A new window opens, as is expected, but the old tab is not loaded. The new window's tab is blank (No text in the "awesomebar." The tab's title is "New Tab" and favicon is the Firefox Nightly logo.

Expected: Even an unloaded tab can be "Moved to a New Window" successfully.


* I tried all the following ways of restarting Nightly, and was in all cases able to reproduce this bug:

1) Clicking the green "Update Nightly" bar/button in the hamburger menu.

2) Clicking the [Restart normally...] button in "about:profiles"

3) Clicking [Exit] button in Hamburger menu, then starting Nightly and clicking "Restore Previous Session" in hamburger menu

3a) Same thing as 3, but using keyboard shortcut [Ctrl] + [Shift] + [Q], instead of "Exit" in the hamburger menu.
Blocking tab multi-select due to large numbers of tabs disappearing. The apparent data loss is not as severe as it first seems though as they remain in the session and are restored when restarting the browser.
Assignee: nobody → ablayelyfondou
Status: NEW → ASSIGNED
So... this bug was filed in January 2011 and was later fixed by bug 817947 in December 2012. But it has since reappeared. I have traced it down to between 2017-04-20 and 2017-04-21 via mozregression. This is the pushlog for those dates:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=27311156637f9b5d4504373967e01c4241902ae7&tochange=dd530a59750adcaa0d48fa4f69b0cdb52715852a

Within that range is https://hg.mozilla.org/mozilla-central/rev/a03617861cb6, which comes from bug 1345090.
Blocks: 1345090
Keywords: regression
I've got a fix for this.
Assignee: ablayelyfondou → jaws
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/20a82622d638
Update remoteness of swapped browsers to ensure we can load them in a new window. r=mconley
https://hg.mozilla.org/mozilla-central/rev/20a82622d638
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Duplicate of this bug: 1496256
Build ID 	20181023100120
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Verified in latest Nightly
I successfully reproduced the issue on Firefox Nightly 62.0a1 (2018-06-23) under Windows 10 (x64) using the STR from Comment 12.

The issue is no longer reproducible on Firefox 64.0b3 and latest Nightly 65.0a1 (2018-10-25) under Windows 10 (x64), Ubuntu 16.04 (x64) and macOS 10.12.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Duplicate of this bug: 1488094
You need to log in before you can comment on or make changes to this bug.