1012784 - [e10s] Dragging a tab out of a window to create its own window does not work

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Chris Peterson [:cpeterson]]

When e10s autostart is enabled, if you try to drag a tab out of a window to create its own window, the following occurs:

* The original tab does not close automatically and cannot be closed manually.
* The new window does not open the original tab's URL.
* The new window's bookmarks toolbar is empty.

Comment 3

[Meinert]

I also have the same issue but also the tab that was dragged out to make its own windows can longer me switched to as well unless you once again try to drag it into its own window.

about:buildconfig
Build Machine

bld-lion-r5-089
Source

Built from https://hg.mozilla.org/mozilla-central/rev/2db5b64f6d49
Build platform
target
x86_64-apple-darwin11.2.0
Build tools
Compiler 	Version 	Compiler flags
/usr/local/bin/ccache /builds/slave/m-cen-osx64-ntly-0000000000000/build/clang/bin/clang -arch x86_64 	3.3.0 	-Qunused-arguments -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Werror=int-to-pointer-cast -Wtype-limits -Wempty-body -Wsign-compare -Wno-unused -Wno-error=uninitialized -Wno-error=deprecated-declarations -isysroot /Developer/SDKs/MacOSX10.7.sdk -std=gnu99 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -DNO_X11 -pipe
/usr/local/bin/ccache /builds/slave/m-cen-osx64-ntly-0000000000000/build/clang/bin/clang++ -arch x86_64 	3.3.0 	-Qunused-arguments -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Werror=int-to-pointer-cast -Werror=type-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-error=uninitialized -Wno-error=deprecated-declarations -isysroot /Developer/SDKs/MacOSX10.7.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -DNO_X11 -pipe -DNDEBUG -DTRIMMED -g -O3 -fno-omit-frame-pointer
Configure arguments

--with-macos-sdk=/Developer/SDKs/MacOSX10.7.sdk --enable-crashreporter --enable-release --with-ccache --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --with-google-api-keyfile=/builds/gapi.data --enable-warnings-as-errors --disable-install-strip --enable-signmar --enable-profiling --enable-instruments --enable-dtrace --enable-js-diagnostics --with-macbundlename-prefix=Firefox --target=x86_64-apple-darwin11.2.0 --with-unify-dist=../i386/dist

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Looks like a duplicate of bug #936092.
If you feel otherwise please reopen.

Comment 5

[Chris Peterson [:cpeterson]]

Move old M2's low-priority bugs to M6 milestone.

Comment 6

[Chris Peterson [:cpeterson]]

Bug 936092 is about dragging and dropping files onto the Firefox window (e.g. uploading gmail attachments). This bug is about dragging browser tabs between browser windows.

Comment 9

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Ahhh, my bad.

Comment 15

[Ram Dayal Vaishnav [:ram]]

I also found this issue on Firefox Nightly 35.0a1 (2014-09-22) for Linux.

Comment 18

[:Felipe Gomes (needinfo for replies!)]

Renominating from m6 because it looks like this bug is getting a look of duplicates filed

Comment 19

[martin]

Still there on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141014030201 CSet: 54217864bae9

Comment 20

[AJ Jordan [:strugee] (he/they)]

(In reply to martin from comment #19)
> Still there on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0)
> Gecko/20100101 Firefox/36.0 ID:20141014030201 CSet: 54217864bae9

Unless there has been a patch or patches attached, reviewed, and landed (recognizable by a link to hg.mozilla.org being pasted), you can expect this bug to remain unfixed, thereby making confirmations of its continued existence by and large unnecessary. (Not to sound too harsh - your interest in Mozilla is appreciated!)

Comment 21

[Jim Mathies [:jimm]]

This should be fixed in tomorrow's (10/22) nightly.

Comment 22

[martin]

Testing dragging Tabs on 
BuildID
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141022030202 CSet: ae4d9b4ff2ee

User Story:
created new profile, enabled e10s
browsed to www.heise.de , opened some tabs  (http://www.heise.de/ http://www.heise.de/thema/Windows-10, http://www.heise.de/thema/iPhone-6 http://www.heise.de/thema/NSA )

Dragged a Tab out of its window, which created a new window, the web-page rendered there, 
but the tab name was "New Tab" and the url was blank.
Subsequent drags to the same second window creates a "New Tab" which looks empty at first, switching tabs in the second window will render the content, the url stays blank.
Reload Page in the URL bar does not refresh the url.
The tabs are usable , i.e. continuing navigation to links on the rendered page is possible.

Expected Result:
Tab should retain the name of the web page it contains.
Tab URL should contain the url of the tab dragged to the new window.
Needinfo me if you need more input.

Comment 23

[Jim Mathies [:jimm]]

We've got tab drag to new window working, but there's some polishing that needs to be done. Let's file some follow ups.

Comment 24

[Jim Mathies [:jimm]]

Do bugs 1087966 and 1087969 cover everything you've run into martin? If not, feel free to file more follow ups! Thanks for testing too.

Comment 25

[Jim Mathies [:jimm]]

btw, tab thumbnails are covered by bug 863512.

Comment 26

[martin]

@Jim Comment 24, jup seems to cover all I found. Thanks!

Comment 27

[martin]

Added another followup , bug 1088126 about context menus showing all possible entries after dragging a tab to a new window.
Not sure this belongs here or in the general contextmenu meta bug 1060070 .
Jim what do you think?

Comment 28

[Jim Mathies [:jimm]]

(In reply to martin from comment #27)
> Added another followup , bug 1088126 about context menus showing all
> possible entries after dragging a tab to a new window.
> Not sure this belongs here or in the general contextmenu meta bug 1060070 .
> Jim what do you think?

Here is fine. All we really need is that tracking-e10s:? flag to find and triage it.

Comment 29

[martin]

Filed bug 1088180, which deals with the fact that links with the attribute target set to _blank open in the window the tab was dragged from , instead of the current window.