[KDE/X11] Clicking X to close rightmost tab moves the tabs right instead
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: andysem, Unassigned)
Details
Attachments
(5 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
Steps to reproduce:
- Have multiple open tabs - more than can fit in the Firefox window. The list of tabs will extend beyond the window width and become scrollable. The content of the tabs doesn't matter, empty tabs will do.
- Scroll the tabs to the right and click on one of the tabs next to the last (but not the last).
- Click on X to close the tab. The tab will close and the tabs right from is will move left to fill its place, creating empty space on the right.
- Without moving the mouse, click on X on the next tab that has now moved under the mouse.
Actual results:
The entire list of the tabs moves right to fill the empty space created after closing the tab on step 3.
Expected results:
The tab that is currently under the mouse cursor should close, similar to step 3.
It actually worked like this until one of the latest Firefox releases (circa 118-119, I'm not sure which release broke it). This behavior was very useful for closing multiple (but not all) tabs on the right by repeatedly clicking on their X as they slide under the mouse.
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•2 years ago
|
||
Can you please create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
Thanks.
Here's a screencast. Here, I'm left-clicking on the X button to close tabs, but that doesn't close the tab and instead moves the tabs to the right.
Now that I've done some dedicated testing, I can add that the issue doesn't always reproduce. Sometimes it goes away if I switch between different windows (one of which is Firefox). I have found that it is more likely to reproduce if you close some window (e.g. of another application) before you start clicking on the X buttons. That is:
- Start Firefox and open tabs (as in the original description step 1).
- Switch to another window (of whatever other application) and close it.
- Back in Firefox, switch to a tab on the right and start closing tabs (as in the original description steps 2-4).
Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 6.2.0-1016-lowlatency (64-bit)
Graphics Platform: X11
Processors: 16 × 12th Gen Intel® Core™ i7-12700K
Memory: 31.1 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2
Nvidia driver: 535.43.16
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Hi andysem, thank you for filing.
We've not had any luck reproducing this exact bug on macOS, Windows or stock Ubuntu.
Are you using any specialized input devices? Perhaps something more sophisticated than a mouse?
Because we can't reproduce this, it's fairly difficult for us to understand what's going wrong without more information. What we could try to do is find the first version where this bug introduced itself. Are you at all familiar with mozregression? This is a tool that you can use to test various versions of Firefox to see when a particular bug got introduced, (almost) down to the patch. That would be a very valuable piece of information that might help us track this down.
Are you using any specialized input devices? Perhaps something more sophisticated than a mouse?
No, I'm using just the mouse.
Comment 9•2 years ago
|
||
(In reply to andysem from comment #8)
Are you using any specialized input devices? Perhaps something more sophisticated than a mouse?
No, I'm using just the mouse.
Are you still seeing this issue? If so, could you perhaps try mozregression that Mike mentioned in comment 7?
| Reporter | ||
Comment 10•2 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #9)
Are you still seeing this issue?
Yes, with Firefox 125.0.3.
If so, could you perhaps try mozregression that Mike mentioned in comment 7?
Sorry, but that sounds like a lot of work testing various Firefox versions, and I don't have time for that. And I don't know a "good" version anyway - this problem existed for years.
Comment 11•2 years ago
|
||
The tabbrowser-tabs component is waiting for a mousemove on the tabpanels, or a mouseout for the tabstrip to unlock the tab sizing. We're somehow hearing from one of those despite the mouse staying within the bounds of the tab...
Hey stransky, does any of this sound like a familiar bug?
Comment 12•2 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) from comment #11)
The tabbrowser-tabs component is waiting for a
mousemoveon the tabpanels, or amouseoutfor the tabstrip to unlock the tab sizing. We're somehow hearing from one of those despite the mouse staying within the bounds of the tab...Hey stransky, does any of this sound like a familiar bug?
I ques we may get mouse move only as it's in window boundary. Unfortunately we don't log mouse move code, that would generate lot of noise.
Also I can't reproduce it.
andysem, can you try to reproduce with clean profile?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Test_Firefox_with_a_new_profile
Thanks.
Comment 13•2 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #12)
andysem, can you try to reproduce with clean profile?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Test_Firefox_with_a_new_profile
Adding needinfo.
(In reply to andysem from comment #10)
Sorry, but that sounds like a lot of work testing various Firefox versions, and I don't have time for that. And I don't know a "good" version anyway - this problem existed for years.
The mozregression tool actually makes this fairly easy. As it stands without a regression range or a way to reproduce this bug, we likely won't be able to address this.
| Reporter | ||
Comment 14•2 years ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #12)
andysem, can you try to reproduce with clean profile?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Test_Firefox_with_a_new_profile
Yes, it reproduces with a clean profile.
- Reboot.
- Launch Firefox. Maximize it.
- Open 15 empty tabs (or however many so that the list of tabs doesn't fit on the screen).
- Open Konsole. The Konsole icon is on my toolbar, I'm using the icon to open it.
- Close Konsole.
- Click on a tab close to the right (e.g. 5th from right).
- Click on X to close this tab.
- Without moving the mouse, click on X again to close the next tab.
At step 8, the next tab is not closed and the list of tabs resizes to the right.
I tested this on my other system:
Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 6.5.0-35-lowlatency (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4700HQ CPU @ 2.40GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 4600
Comment 15•2 years ago
|
||
The steps looks pretty straightforward. I wonder if that's KDE/X11 specific as I can't reproduce on Gnome. Will try after reboot.
Updated•2 years ago
|
Updated•2 years ago
|
| Reporter | ||
Comment 16•2 years ago
|
||
Yes, please test on Kubuntu/KDE. I've been using KDE all along.
Comment 17•2 years ago
|
||
Tested Firefox 128.0 on KDE/Fedora 40/Wayland and I don't see it there. I didn't test X11 though....do you mind to test X11?
(I have installed plasma-workspace-6.1.2-2.fc40.x86_64)
| Reporter | ||
Comment 18•2 years ago
|
||
This report is on X11, I'm not using Wayland.
| Reporter | ||
Comment 19•2 years ago
|
||
BTW, still reproduces in Firefox 128.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 20•1 year ago
|
||
I will open this issue, I was able to reproduce it on Ubuntu 24.04 with x11, Im not sure if my pc is just slow and thats whats causing it but if you open a bunch of tabs with the Middle mouse wheel and then from the middle of the tab strip you start Closing these tabs at some point it will start to move the tab to the right, either it gets a bit bigger or it moves just enough for the next X to not be under the mouse cursor, I will add a screen recording of the issue but the Mouse cursor is not visible in it (we can still see the tabs move a bit).
Comment 21•1 year ago
|
||
Here is a Screen recording of the issue, sorry that the mouse cursor is not displayed, that ubuntu Screen cast from it does not work correctly
Description
•