Tab swallowing not working properly

[gibsonrng]

Hey, finally discovered this project (big thanks for sharing this) as tab dragging in i3 and chromium based browsers has been painful for quite some time (especially when trying to rearrange tabs in the same browser window when inside a tabbed i3 layout with multiple windows).

Just noting that I am aware of the recent chromium bug that caused complete tab dragging breakage in the last few weeks. But it looks already fixed in chromium 102.0.5005.115 based browsers. So I started testing this script with 102.0.5005.115 and also multiple older browser versions before the last breakage. But in all cases I am noticing a problem. When dragging a tab to another window, the dragged window gets switched to floating mode properly, but it cannot be placed in another browser window, it just does not get swallowed when dragged to the new position. This can be seen in the following gif:

In very rare cases (maybe 1%) it randomly gets swallowed in a new position.

So I started testing this with other machines, distros and older browser versions and this issue seems to appear with all versions >= 97.0.4692.71. More specifically 96.0.4664.110 was the last version there the script in this project worked really well (as described in the project README). I used the following method: https://unix.stackexchange.com/a/612981 to install older google-chrome versions on a Debian based system.

Am I doing something wrong? Has dragged tab swallowing been working properly for somebody with a chromium based browser >= 97.0.4692.71?

[ristomatti]

You are right, this is exactly the same experience I described on issue #5. A specific thing I noticed was that it seemed to be easier to get a window to swallow the tab on the left and middle panes with 3 vertical splits.

One particular annoyance I have with Chrome's tab handling is that I mostly use 2 or 3 vertical splits which are all set to tabbed (stacked?) layout. When there's multiple tabbed Chrome windows, it's pretty much just trial and error to get a tab stick to the window I want. As I mentioned on #5, it's even more difficult with a tab group based on my experience.

Often I've found it's easier to float both window before attempting. Also I've found it helps if the tab bars of the two windows are side by side and try to make the motion as straight as you can. :grin:. But the latter strategy falls apart if you happen to grab the last tab on a window (with no other tabs on the split). It also fails if there's multiple Chrome tabbed/stacked Chrome windows.

Of course, I believe we all agree this is likely not a simple issue to fix and i3 users have to be a very tiny fraction of the Chromium based browsers' userbase. :slightly_smiling_face:

With that said, seeing how painlessly this works on Firefox,it makes me think Chromium has a somewhat too eager UX implementation. I wonder if it's creating a completely new window when you detach a tab, which will then be immediately closed if attached to an existing window. The tabs also seem to snap in to a window in this same eager way, while Firefox lets you carefully select the position using a small arrow indicator.

[Syphdias]

But it looks already fixed in chromium 102.0.5005.115 based browsers.

@gibsonrng, not sure about the minor versions, but 102 did not fix it for me. 103 was the one that "fixed" it. (Every time I say fixed here, I mean it very loosely as it it not entirely fixed as far as I can tell).

Is @ristomatti correct in assuming that this is exactly the same issue as described in #5 and not something new? If so, I would close this issue as I have already pinned #5. If so I can only repeat that this is a chromium but that I cannot "modify" as this only interacts with windows/containers and their behavior.

Often I've found it's easier to float both window before attempting. Also I've found it helps if the tab bars of the two windows are side by side and try to make the motion as straight as you can. grin. But the latter strategy falls apart if you happen to grab the last tab on a window (with no other tabs on the split). It also fails if there's multiple Chrome tabbed/stacked Chrome windows.

I also discovered different behavior when the layout is vplit instead of hsplit in i3. I don't even know if it is purely related to chromium at this point. In the following gif you can see what I mean. After v-splitting. I works fine – at no point do I use the script from this repository!

In the README you can see some old information about which versions I bisected to work or partly work but I am a bit weary to do that again and get someone from the chromium team to look at it again... This build (should be version 95.0.4630.0) – please don't use that outside of testing – works as it should.

[gibsonrng]

Hey @Syphdias, regarding your last gif: I think all these differences in behavior can be explained by the fact that you are sometimes working with a browser window that has only one tab. Dragging out last tab from a browser window behaves differently than the usual case with when some tabs remain in the browser window.

Regarding historic behavior of the script in this project: it worked great with some versions, for example, 96.0.4664.110, but I think that the tab "swallowing" problem described in this issue has been the main problem with this script for quite some time as I also tested exact versions 97.0.4692.99, 98.0.4658.80, 99.0.4844.51 and a few 100+ versions (with install method described previously) and all of them had very similar, consistent "swallowing" issue.

Exact version 102.0.5005.115 fixed the big issue (completely broken tab dragging for all Linux users). I quickly looked at 103.0.5060.42 beta version and it has similar "swallowing" issue, however it is easier to trigger swallowing (in all previously tested versions it seemed almost impossible), still not really usable for everyday use.

[Syphdias]

Hey @Syphdias, regarding your last gif: I think all these differences in behavior can be explained by the fact that you are sometimes working with a browser window that has only one tab. Dragging out last tab from a browser window behaves differently than the usual case with when some tabs remain in the browser window.

I think this is exactly it what I have been struggling with. You are right, there is still an issue. But I think I cannot fix it and it is a chromium issue at heart with one of the behaviors and it changed from version to version.

The two different behaviors for how a tab is converted to "dragging":

1. The tab is the last tab in the window and gets dragged: The window disappears for the window manager and you drag "something" that looks like a window but it has no border. This looks like a floating window but I don't think i3 sees it as a window but I am not sure.
2. The tab leaves behind other tabs: The tab is converted into a new window that is held by the tab. The default behavior for i3 is to make it tiling which leads to jumping around due to container/window resizing.

In my opinion both dragging should behave like 1 and we would all be happy. No script needed.

But at some point in the development of chromium behavior 2 changed and you can no longer drag (floating) windows into other windows. This is not specific to the script but only visible with it. Since if you drag out a tab, you usually get it in tiling mode without the script. In looks like 96.0.4664.110 behaves like the version I tested (95.0.4630.0 + i3-chrome-tab-dragging.py) and does not have this problem yet. If a tab that is a floating window and another chromium window does not "swallow" it, there is nothing I can do about it – I think.

This is made worse by the fact that if you start with behavior 1, but accidentally drag the tab out again, you now have behavior 2. Which means you need to drop the window in tiling mode and drag the single tab to get behavior 1 again. Not sure if that could be done automatically to force behavior 1 :thinking:

[ristomatti]

Is @ristomatti correct in assuming that this is exactly the same issue as described in #5 and not something new? If so, I would close this issue as I have already pinned #5. If so I can only repeat that this is a chromium but that I cannot "modify" as this only interacts with windows/containers and their behavior.

Yes I believe I was :slightly_smiling_face:. The first 102 release broke things badly and that is what I believe #5 is about. After noticing the issue I installed a beta of 103 and to my relief found out it's already fixed there. However we did not have to wait that long as a few days ago a second 102 build was released which fixed that. The issue described here matches my experience with running this script on the later 102 build.

I also discovered different behavior when the layout is vplit instead of hsplit in i3. I don't even know if it is purely related to chromium at this point. In the following gif you can see what I mean. After v-splitting. I works fine – at no point do I use the script from this repository!

Looks the same as for me also w/o this script running. In fact, now after a full day of using the newer 102 build, I believe dragging tabs has improved over version 101. It's definitely glitchy but still an improvement. Moving tab groups still seem to be worse than single tabs but it might also have improved a bit.

One thing I've specifically noticed improving is rearranging tabs within the same window (e.g. moving a tab from the far right to a tab group on the far left. On all previous releases after tab group feature was released I had to have my tongue at the right angle and carefully try not to move the mouse pointer even a single pixel off the tab tab bar vertical axis. It seems there's now a bit more margin for error :smile:.

But I think I cannot fix it and it is a chromium issue at heart with one of the behaviors and it changed from version to version.

Agree 100%. The base idea of your script is still very clever. It's a pity it can't work around the current Chromium version but at least now it's good enough for me. Heopfully it won't reappear at some point given the change history you've described. With good luck they'll add regression tests:

[Syphdias]

In a nutshell: The script improves the tab dragging experience from multi tab out of the window, but not into another window. Workaround: Drop tab to make a new window then drag into another window – the script has no part in this.

[gibsonrng]

My main usecase has always been dragging tabs within the same browser window. Dragging tabs to another window is more rare in my workflow and this can be done quite easily with: "right click -> move tabs to another window" and dragging them within the new browser window if needed.

For easier tab dragging within the same browser window I created and now use another workaround.

Dragging tabs within the same browser window requires careful horizontal movement of the mouse (especially when inside a tabbed i3 layout). So I created one script that enters a "horizontal-only dragging mode" and another script that exits this mode. For extra convenience entering this mode presses down mouse button automatically and exiting this mode lifts the mouse button automatically, so I do not have to click or keep touchpad button pressed manually.

I bind these scripts to super + d : d and super + d : space keyboard shortcuts using sxhkd, so I can enter this mode with first key chain and exit by pressing a single space key. Works well so far, maybe somebody else finds this useful. If you do not use sxhkd probably best option is to create a single script that toggles this mode to avoid having to create two different keyboard shortcuts.

First script (enters horizontal-only mouse mode):

set -e
ids="$(xinput list | grep -E "\[slave.*pointer" | cut -d '=' -f 2 | cut -f 1)"
for id in $ids; do
    xinput set-prop "$id" "Coordinate Transformation Matrix" 1 0 0 0 0 0 0 0 1
done
xdotool mousedown 1

Second script (exits the mode):

set -e
pkill -ALRM sxhkd
xdotool mouseup 1
ids="$(xinput list | grep -E "\[slave.*pointer" | cut -d '=' -f 2 | cut -f 1)"
for id in $ids; do
    xinput set-prop "$id" "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1
done

Demo:

[Syphdias]

Since you already pressing buttons this might be interesting to you, if you haven't seen it yet: https://github.com/Syphdias/i3-chrome-tab-dragging/issues/5#issuecomment-1150478804

[ristomatti]

Both of you have gone to great lengths in attempting to tackle the issue! :exploding_head:

I don't know if I've gotten more accurate with my mouse movement or if something has improved but I've only had a couple of tab drops on vertical movement during the last two days. A quick screencap with no tweaks running:

https://user-images.githubusercontent.com/9029939/174144122-0fa14511-7d40-49cd-b0b5-b9d2a6d45c9b.mp4

[ristomatti]

Another trick I use if I need to move a tab to the far right, I'll pin the tab with a shortcut, then unpin it. I've assigned the keyboard shortcut with this extension (might be doable nowadays even without it): https://chrome.google.com/webstore/detail/tab-pinner-keyboard-short/mbcjcnomlakhkechnbhmfjhnnllpbmlh

[gibsonrng]

Since you already pressing buttons this might be interesting to you, if you haven't seen it yet: #5 (comment)

Yes, I also use Ctrl+Shift+PgUp/PgDown but these shortcuts do not work with multiple tabs / tab groups and can be quite slow for moving a tab 30+ positions.

I don't know if I've gotten more accurate with my mouse movement or if something has improved but I've only had a couple of tab drops on vertical movement during the last two days.

Yes, in the demo you are just dragging it very horizontally, quite hard to do with random touchpads.

With that said, seeing how painlessly this works on Firefox,it makes me think Chromium has a somewhat too eager UX implementation.

Yes, I think that Chromium creating native windows during tab dragging is not the best option. This seems to create more platform dependent behaviors and bugs for little if any benefit. I have not looked at many other software projects that support cross-window tab dragging, but Firefox, Jetbrains, even Visual Studio Code handle tab dragging internally without creating native windows and work great as a result. But I would not hold my breath for this to be changed / "fixed" in the Chromium project.

I've assigned the keyboard shortcut with this extension (might be doable nowadays even without it)

Yes, in the end browser extensions probably can provide best UX for this with the current Chromium behavior. There probably are a lot of options that help with "tab organization", although I am not a huge fan of installing additional browser extensions.

[Syphdias]

I had the idea of letting go of the native window for a split second and then grabbing the tab again to trigger the internal window dragging. But at least pynput seems to not allow for letting go of the mouse press if it was triggered by the actual mouse and not by pynput itself. :disappointed: