Slow to switch tabs; tabs sometimes spontaneously become separate windows




7 years ago
6 years ago


(Reporter: Ken Wesson, Unassigned)


5 Branch

Firefox Tracking Flags

(Not tracked)




7 years ago
User Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122 Safari/534.30

Steps to reproduce:

Clicked a tab to switch to it.

Actual results:

Firefox was even slower than usual (3-4 seconds instead of roughly 1) to switch to the tab. When it finally did, a bit later the tab detached itself and became a separate browser window, which is annoying to have to reinsert where I had it.

Expected results:

Firefox should have simply switched to that tab, without making it into a separate window and preferably in a lot less than even 1 second.

Comment 1

7 years ago
This has happened repeatedly, but does not occur 100% of the time or even much more than 2-3% of the time when switching tabs. Switching to a tab tends to be slow, though, and the risk of the tab breaking off seems to grow the slower it is in a particular case. Predictors of slowness (and thus risk): how long since that tab was last active (worse if longer), and how long the browser has been focused since last backgrounded (better if longer).

Theory: dragging a tab far enough down is supposed to break it off, so perhaps when Firefox is slow to switch to a tab, the mousedown event on the tab starts it switching, it then gets busy loading stuff and doesn't service the mouseup event right away. By the time it sees the mouseup event the mouse has been moved well down the screen to scroll/click a link/whatever.

Corroboration: click-and-hold on an inactive tab foregrounds it without waiting for the mouseup event, so the mouseup event can indeed occur after the browser begins to retrieve the cached contents of the tab from wherever it stows it when that tab's not active.

Fix, if the theory is correct: increase the priority of the event loop thread relative to whichever thread fetches tab contents to display when the active tab changes, so that the event loop is not preempted by the other thread. Do not do disk I/O directly in the event loop thread so that it cannot be held up by the other thread via disk contention; delegate to another thread for disk I/O and use an event of some type to communicate results back to the event loop thread. Preferably do not do network I/O directly in the event loop either, in case the NIC can be a bottleneck.

Alternative fix: if possible, make the coordinates associated to a mouseup event correspond always to the position of the pointer at the time the event was generated, not at the time the event is eventually looked at by the event loop code.

Alternative fix, and probably the best one: make switching tabs not so damn slow! :)

Comment 2

6 years ago
do you see thisin v13 or newer?
Whiteboard: [closeme 2012-08-01]

Comment 3

6 years ago
and in safe mode :)

Comment 4

6 years ago
Resolved per whiteboard
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2012-08-01]
You need to log in before you can comment on or make changes to this bug.