The default bug view has changed. See this FAQ.

[e10s] Detaching XUL tabs (about:newtab, about:preferences, about:addons) leaves a ghost tab in the old window, and opens a blank tab in the new window

VERIFIED FIXED in Firefox 40

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: Johan C, Assigned: mconley)

Tracking

(Blocks: 1 bug)

unspecified
Firefox 40
Points:
2
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify +

Firefox Tracking Flags

(e10sm7+, firefox40 verified)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

2 years ago
STR:
1. Make sure e10s is enabled.
2. Open a website (e.g. https://www.mozilla.org/).
3. Open a new tab (tab_2) (e.g. about:newtab, about:preferences or about:addons)
4. Detach tab_2 to open it in a new window.

Actual result:
tab_2 is blank
tab_2 remains in the first window as a ghost tab (i.e. you can't close it. You also can't reselect it after selecting the first tab (https://www.mozilla.org/).

When detaching the tab the following error is thrown:
  NS_ERROR_NOT_IMPLEMENTED:  browser.xml:1104

If you drag the now blank tab back to the first window, it remains blank and the ghost tab remains as well. This also throws:
  NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver] browser.js:2238
I believe this is a duplicate of bug 976621.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 976621
(Reporter)

Comment 2

2 years ago
Wrong bug?

The bug you marked this bug a duplicated of was fixed 8 months ago.

Setting to reopened for now.
Status: RESOLVED → REOPENED
Flags: needinfo?(cpeterson)
Resolution: DUPLICATE → ---
oops! Looks like tab dragging might be broken again.
Flags: needinfo?(cpeterson)
Assignee: nobody → davidp99
tracking-e10s: ? → m4+
The key line in the log is this:

> [Parent 41145] WARNING: Swapping remote and non-remote frames is not currently supported: file /Users/davidp/mozilla/central/firefox/dom/base/nsFrameLoader.cpp, line 1045

I'm not sure how much time we want to spend on this since we want to eliminate non-remote pages.

In tab-drag cases, where the swap is always done with a brand new tab, the new tab should match the old tab's remoteness.  Currently, the new tab is always the (remote) "about:blank".  This could be done by swapping with "about:newtab" if the page is not remote, for example.  Note that this leaves the problem of dragging between an e10s and a non-e10s window.
tracking-e10s: m4+ → ?
(Reporter)

Comment 5

2 years ago
(In reply to David Parks [:handyman] from comment #4)
> The key line in the log is this:
> 
> > [Parent 41145] WARNING: Swapping remote and non-remote frames is not currently supported: file /Users/davidp/mozilla/central/firefox/dom/base/nsFrameLoader.cpp, line 1045
> 
> I'm not sure how much time we want to spend on this since we want to
> eliminate non-remote pages.

Isn't the new about:preference page already remote?
I have a tough time keeping this stuff straight but this is the relevant function:
https://mxr.mozilla.org/mozilla-central/source/browser/modules/E10SUtils.jsm#14

It defines about:home, blank, neterror and certerror as the only remote about pages.
(Reporter)

Comment 7

2 years ago
(In reply to David Parks [:handyman] from comment #6)
> I have a tough time keeping this stuff straight but this is the relevant
> function:
> https://mxr.mozilla.org/mozilla-central/source/browser/modules/E10SUtils.
> jsm#14
> 
> It defines about:home, blank, neterror and certerror as the only remote
> about pages.

about:preferences is in the process of being rewritten/turned into an in-content page, considering how far along that project is, shouldn't it already be a remote page if that was the plan? Who would know if there are future plans to turn about:preferences into a remote page?

I did some quick testing and installed the add-on superstart (https://addons.mozilla.org/en-US/firefox/addon/super-start/), and the bug affects the add-on. Yes the add-on looks broken but that shouldn't matter. 

Superstart isn't as far as I can tell a XUL-page, and this bug's title should probably be updated.
tracking-e10s: ? → m5+
Duplicate of this bug: 1096554

Updated

2 years ago
Duplicate of this bug: 1103233
Flags: firefox-backlog+
Duplicate of this bug: 1121484
A (partially) similar behavior encountered for various hyperlinks of XUL tabs.

eg.: open about:addons → click the "See all complete themes" link from the "More ways to customize" panel.
Results: A new blank tab is opened.
Note: Page is opened correctly with right click -> open link in new tab.

Should I file a separate issue for this matter?
(In reply to Cornel Ionce [QA] from comment #11)
> A (partially) similar behavior encountered for various hyperlinks of XUL
> tabs.
> 
> eg.: open about:addons → click the "See all complete themes" link from the
> "More ways to customize" panel.
> Results: A new blank tab is opened.
> Note: Page is opened correctly with right click -> open link in new tab.
> 
> Should I file a separate issue for this matter?

Hey Cornel - that's bug 1047603, which should be fixed soon.
Duplicate of this bug: 1129471
Hey handyman,

I'm looking to maybe nab a few more M5's. Were you willing to give this one up, or had you already started to dig into it?
Flags: needinfo?(davidp99)
This is part of the bigger universe of swapFrameLoaders-related bugs... if you honestly want to get into this, its all yours.
Flags: needinfo?(davidp99) → needinfo?(mconley)
Eff it, why not?
Assignee: davidp99 → mconley
Flags: needinfo?(mconley)
Blocks: 1134375
The patch in bug 1087966 fixes this.
Assignee: mconley → dtownsend
Depends on: 1087966
Fixed by bug 1087966
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED

Updated

2 years ago
Iteration: --- → 39.1 - 9 Mar
Flags: qe-verify?
Apparently I was wrong and this isn't fixed.
Assignee: dtownsend → nobody
Status: RESOLVED → REOPENED
Iteration: 39.1 - 9 Mar → ---
Points: --- → 2
Flags: qe-verify? → qe-verify+
Resolution: FIXED → ---
Duplicate of this bug: 1136948
Not convinced this needs to be m5+ though I suspect it is simply a case of making sure the tab in the new window is non-remote to allow swapDocShells to work.
tracking-e10s: m5+ → ?

Updated

2 years ago
Duplicate of this bug: 1136953
tracking-e10s: ? → m7+
Assignee: nobody → mconley

Comment 23

2 years ago
simple str on windows:
1) drag newtab out to a new window
2) drag it back to the original window

result: new window remains open, new tab isn't created

Comment 24

2 years ago
Also once you've done this, you need to restart to get tab drag working again.
Status: REOPENED → ASSIGNED
Created attachment 8603511 [details]
MozReview Request: bz://1094328/mconley

/r/8431 - Bug 1094328 - Make it possible to drag remoteness blacklisted tabs into e10s windows. r=?
/r/8433 - Bug 1094328 - Beef-up regression tests for tab dragging between window types. r=?

Pull down these commits:

hg pull -r e187eb9ab2373857b096a62bec6610ee7e730809 https://reviewboard-hg.mozilla.org/gecko/
Comment on attachment 8603511 [details]
MozReview Request: bz://1094328/mconley

/r/8431 - Bug 1094328 - Make it possible to drag remoteness blacklisted tabs into e10s windows. r=?
/r/8433 - Bug 1094328 - Beef-up regression tests for tab dragging between window types. r=?

Pull down these commits:

hg pull -r e187eb9ab2373857b096a62bec6610ee7e730809 https://reviewboard-hg.mozilla.org/gecko/
Attachment #8603511 - Flags: review?(dtownsend)
Try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ff049d735486
https://reviewboard.mozilla.org/r/8431/#review7111

Ship It!
https://reviewboard.mozilla.org/r/8433/#review7113

r+ but I'm assuming those added test cases will fail in non-e10s, they should be skipped there.

::: browser/base/content/test/general/browser_tab_drag_drop_perwindow.js:111
(Diff revision 1)
> +  const BLACKLISTED_URL = "about:tabcrashed";

FWIW anything under chrome://mochitests/content/... will always open non-remote. Anything under chrome://mochitests-content/content/... will always open remote.
Attachment #8603511 - Flags: review?(dtownsend) → review+

Comment 30

2 years ago
https://hg.mozilla.org/integration/fx-team/rev/df2d734300e4
https://hg.mozilla.org/integration/fx-team/rev/77b43decfd15

Updated

2 years ago
Duplicate of this bug: 1163385
https://hg.mozilla.org/mozilla-central/rev/df2d734300e4
https://hg.mozilla.org/mozilla-central/rev/77b43decfd15
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago2 years ago
status-firefox40: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 40

Updated

2 years ago
Iteration: --- → 40.3 - 11 May
This issue is fixed with e10s enabled on:
- Latest Nightly, build ID: 20150517030204
- Latest Aurora, build ID: 20150517004004.

Tested on Windows 7 64-bit, Ubuntu 12.04 32-bit and Mac OS X 10.9.5.
Status: RESOLVED → VERIFIED
status-firefox40: fixed → verified
Comment on attachment 8603511 [details]
MozReview Request: bz://1094328/mconley
Attachment #8603511 - Attachment is obsolete: true
Attachment #8618557 - Flags: review+
Attachment #8618558 - Flags: review+
Created attachment 8618557 [details]
MozReview Request: Bug 1094328 - Beef-up regression tests for tab dragging between window types. r=?
Created attachment 8618558 [details]
MozReview Request: Bug 1094328 - Make it possible to drag remoteness blacklisted tabs into e10s windows. r=?
You need to log in before you can comment on or make changes to this bug.