Johan C Reporter
	Description • 10 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

	Chris Peterson [:cpeterson]
	Comment 1 • 10 years ago

I believe this is a duplicate of bug 976621.

	Johan C Reporter
	Comment 2 • 10 years ago

Wrong bug?

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

Setting to reopened for now.

	Chris Peterson [:cpeterson]
	Comment 3 • 10 years ago

oops! Looks like tab dragging might be broken again.

	David Parks [:handyman]
	Comment 4 • 10 years ago

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.

	Johan C Reporter
	Comment 5 • 10 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?

	David Parks [:handyman]
	Comment 6 • 10 years ago

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.

	Johan C Reporter
	Comment 7 • 10 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.

	Cornel Ionce [:noni] [Hubs QA]
	Comment 11 • 9 years ago

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?

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 12 • 9 years ago

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

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 14 • 9 years ago

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?

	David Parks [:handyman]
	Comment 15 • 9 years ago

This is part of the bigger universe of swapFrameLoaders-related bugs... if you honestly want to get into this, its all yours.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 16 • 9 years ago

Eff it, why not?

	Dave Townsend [:mossop]
	Comment 17 • 9 years ago

The patch in bug 1087966 fixes this.

	Dave Townsend [:mossop]
	Comment 18 • 9 years ago

Fixed by bug 1087966

	Dave Townsend [:mossop]
	Comment 19 • 9 years ago

Apparently I was wrong and this isn't fixed.

	Dave Townsend [:mossop]
	Comment 21 • 9 years ago

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.

	Jim Mathies [:jimm]
	Comment 23 • 9 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

	Jim Mathies [:jimm]
	Comment 24 • 9 years ago

Also once you've done this, you need to restart to get tab drag working again.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 25 • 9 years ago

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

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 26 • 9 years ago

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/

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 27 • 9 years ago

Try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ff049d735486

	Dave Townsend [:mossop]
	Comment 28 • 9 years ago

https://reviewboard.mozilla.org/r/8431/#review7111

Ship It!

	Dave Townsend [:mossop]
	Comment 29 • 9 years ago

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.

	Pulsebot
	Comment 30 • 9 years ago

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

	Phil Ringnalda (:philor)
	Comment 32 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/df2d734300e4
https://hg.mozilla.org/mozilla-central/rev/77b43decfd15

	Cornel Ionce [:noni] [Hubs QA]
	Comment 33 • 9 years ago

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.