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.

Wrong bug? The bug you marked this bug a duplicated of was fixed 8 months ago. Setting to reopened for now.

oops! Looks like tab dragging might be broken again.

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.

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

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

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.

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?

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

Eff it, why not?

The patch in bug 1087966 fixes this.

Fixed by bug 1087966

Apparently I was wrong and this isn't fixed.

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.

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

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

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

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.

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

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

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.