User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20100101 Steps to reproduce: 1. open firefox 2. open at least two tabs 3. drag and drop one tab out of firefox' window Actual results: Nothing Expected results: Create a new window which contains only the selected tab. This is the "old" behaviour on X11 and XWayland. Additional info: This issue happens with the nightly 62.0a1 (2018-05-26) build and also with Fedora's wayland-enabled firefox-60.0.1-5.fc28.x86_64. The same issue is present in a few GNOME applications like nautilus or epiphany.

Can you please test latest nightly?

I'm still on this but I'm waiting for the flatpak-repo https://firefox-flatpak.mojefedora.cz/repo/ to update.

I verified this issue on Ubuntu 18.04 X64 with the latest Firefox 62.0a1 (64bit) and I cannot reproduce it after following your steps. Please test if the issue is reproducible in safe mode, here is a link that can help you: https://support.mozilla.org/t5/Procedures-to-diagnose-and-fix/Troubleshoot-Firefox-issues-using-Safe-Mode/ta-p/1687#w_how-to-start-firefox-in-safe-mode Please download Firefox Nightly from here: https://ftp.mozilla.org/pub/firefox/releases/60.0.1/win64/en-US/. If you still have the issue please create a new profile, you have the steps here:https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

I can still reproduce this issue with 62.0a1 (2018-06-12) (64-bit) builds from https://firefox-flatpak.mojefedora.cz/repo/ with a new (clean) profile. (In reply to Daniel_A from comment #3) > Please download Firefox Nightly from here: > https://ftp.mozilla.org/pub/firefox/releases/60.0.1/win64/en-US/. I cannot find any recent firefox nightly (62.x) on that FTP server. Testing with 60.x does not make sense as that version does not have the wayland backend enabled. This bug is only about the (still experimental) wayland backend, not about behaviour in a released (stable) version.

I've also confirmed that this issue still happened in nightly 62.0a. ``` changeset: 423477:15c95df467be tag: tip fxtree: central user: Olli Pettay <Olli.Pettay@helsinki.fi> date: Sun Jun 24 18:16:32 2018 +0300 summary: bug 1470306, DOMEventTargetHelper object should be kept alive while calling DisconnectFromOwner, r=bkelly ``` And :ashie and I confirmed that previous version of bug 1464808 can resolve this bug. https://reviewboard.mozilla.org/r/247524/diff/1/

Build 423477:15c95df467be on Fedora 28 / gnome-shell fixes that for me. Fix from Bug 1464808 depends on your compositor - which one do you use and can you retest that on gnome-shell/mutter?

(In reply to Martin Stránský [:stransky] from comment #6) > Build 423477:15c95df467be on Fedora 28 / gnome-shell fixes that for me. Fix > from Bug 1464808 depends on your compositor - which one do you use and can > you retest that on gnome-shell/mutter? In my case this issue happens on gnome-shell/mutter. I can still reproduce this issue with the latest Fedora builds (firefox-wayland-61.0-4.fc28.x86_64). I have no clue which of these weird version numbers that build has. I can also reproduce this issue with the latest flatpak version of Firefox (from http://firefox-flatpak.mojefedora.cz/, 62.0a1 (2018-06-21) 64Bit)

(In reply to Martin Stránský [:stransky] from comment #6) > Build 423477:15c95df467be on Fedora 28 / gnome-shell fixes that for me. Fix > from Bug 1464808 depends on your compositor - which one do you use and can > you retest that on gnome-shell/mutter? As usual, we use weston compositor 2.0.0 on Debian Stretch 9.4.

> As usual, we use weston compositor 2.0.0 on Debian Stretch 9.4. Previous comment says wrong weston version. We use Weston 2.0.0 on R-Car M3 but Debian stretch 9.4 does not have weston 2.0.0.... I tried on current trunk with weston compositor 1.12.0: --- changeset: 424901:987ea0d6a000 tag: tip fxtree: central parent: 424835:b636a45b545e parent: 424900:5d23b6e0b74d user: shindli <shindli@mozilla.com> date: Wed Jul 04 00:56:24 2018 +0300 summary: Merge inbound to mozilla-central. a=merge --- Worked: 1. Drag tabs and arrange tab order 2. Open tabs on new window or tab after dragging indicator to be `+` Not Worked: 3. Drag tabs and then check dragging indicator to be `+`. A tab which is dragging indicator to be `+` is just copied to new window/tab and original tab still to be remained. Expected Results: Step 3 expected result: Tab should not be cloned. It should be moved into new window or just moved.

Yes, the behavior is somewhat different than on X11. I noticed that when dragged page leaves tabbar on X11. the icon changes from '+' to a hand icon on gnome but on Wayland it still stays a '+'. Looks like we have a default D&D action "copy" on Wayland and "link" on X11.

For me, sometimes tab dragging works but clones tabs, sometimes dragging doesn't even start. (the "sometimes" seems to be per Firefox launch)