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.

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

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

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

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.

Ahhh, my bad.

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

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

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

(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!)

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

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.

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.

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.

btw, tab thumbnails are covered by bug 863512.

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

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?

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

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.