1973735 - Pinning tabs via drag and drop is slow in a window with many tabs

Status: NEW

(Firefox :: Tabbed Browser, defect, P2)

Description

[Asif Youssuff]

Steps to reproduce:

1. Have a Firefox window with many tabs
2. Have a pinned tab
3. Drag tab to pinned area to pin

What happens:

I found that after clicking and dragging the tab I wanted to pin, the pointer didn't decorate itself until seconds after I started to drag, and the tab didn't move until I wiggled my mouse -- long after I started to drag.

That was the case when both pinning and unpinning, and in horizontal and vertical modes.

Expected result:

Much faster, ideally as fast as a window with only 3 tabs.

Profiles:

https://share.firefox.dev/4l1z0xe

https://share.firefox.dev/463H8Zt

Comment 1

[Kelly Cochrane [:kcochrane]]

Hi, do you know roughly how many tabs you have open when you're seeing this? Could you tell us what OS you're using? A screen recording would be nice if possible.

Comment 2

[Asif Youssuff]

Attachment: horizontal.mkv

Comment 3

[Asif Youssuff]

Attachment: vertical.mkv

The window where I recorded the attached screen recordings currently reports 12,697 tabs, according to https://addons.mozilla.org/en-US/firefox/user/DaAwesomeP/

I'm also running Debian Testing.

Comment 4

[Kelly Cochrane [:kcochrane]]

Along with a regression window, it'd be nice to pin down if this is happening on all platforms or just some/one. It'd also be helpful to know how many tabs you need to have open before we start seeing this jank. Curious if someone on the QA team can find out, so we can more accurately set priority/severity.

Comment 5

[Asif Youssuff]

I pin tabs in a few (overburdened) windows, and I didn't even know how many tabs were in that window until you asked.

I did some additional testing in a window with 864 tabs, and starting a drag is a lot faster.

Horizontal layout: https://share.firefox.dev/3T6Gtz1
Vertical layout: https://share.firefox.dev/4l2ljhR

Comment 6

[Sam Foster [:sfoster] (he/him)]

The profiles show a lot of reflow during the dragging. That's surprising. We expect a little at the start of the drag and at the end, but not so much just moving the dragged tab around.

Comment 7

[Alexandru Trif, Desktop Test Engineering [:atrif]]

I mistakenly removed the ni? for comment 4.

I believe that I can reproduce this issue with Firefox 142.0a1 (20250626034703) on Windows 10x64, macOS 15 aarch and Ubuntu 24, but for me it is not as slow as in the videos. I have tried to open 12,000 tabs or at least half of them by duplicating them, but this made Nightly unusable, so I created a sessionstore.jsonlz4 file with 12k Wikipedia tabs. Opening nightly with the profile containing the sessionstore.jsonlz4 file will open 12k unloaded Wikipedia tabs. Note that this will make the browser a little slower for me.

I have uploaded recordings for all three OS's here.

Regression range: This issue can be reproduced after the implementation of bug 1944907 (I tried the build from treeherder, containing the patch), most likely this is not a regression.

Note: I cannot see this issue with ~1300 tabs on macOS 15 aarch. I think I also see a similar issue when creating tab groups by drag and drop with Firefox 142.0a1 (20250626034703) and 140.0.1 (see screen recording).

If more information or other investigation is needed, please let me know.