1065236 - Switching tabs slow with Gnome and proprietary NVIDIA drivers

Status: RESOLVED INVALID

(Firefox :: Tabbed Browser, defect)

Description

[Reed Law]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140901122935

Steps to reproduce:

Start Firefox in Safe Mode (Arch Linux with 3.16.1-1-ARCH kernel), close all tabs except 3:
http://orgmode.org/worg/org-contrib/babel/
https://bugzilla.mozilla.org/enter_bug.cgi#h=bugForm|Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=636908

Happens on other pages and with extensions such as Ghostery enabled.



Actual results:

Switching between tabs by clicking on each tab is extremely slow. Sometimes it takes several seconds. The problem is intermittent. Sometimes the switch happens quickly.

Some other web pages take even longer to display after clicking the tab. I've seen it take 10 seconds or more at times.


Expected results:

Tab switching should be imperceivable. There should be no noticeable delay.

Comment 1

[Reed Law]

This happens even with very low CPU load. It does not occur in Chromium on the same machine. I am using an Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz with 16GB RAM and SSD.

Comment 2

[YF (Yang)]

Does you reproduce the with a clean profile?

Comment 3

[Reed Law]

It is indeed faster with a clean profile. But the problem still occurs intermittently. After opening another tab (Youtube) and browsing for a little while, then switching back to one of the first three tabs, there is occasionally a delay of a few seconds. Incidentally, I don't have Flash installed. I watched part of one video (https://www.youtube.com/watch?v=bDOZbvE01Fk) in HTML5 video mode while waiting for the problem to reassert itself. I watched for maybe 3 minutes and didn't do anything else on the site.

Comment 4

[:Gijs (he/him)]

Is this on a vanilla mozilla.org build, or on the version from arch linux? This wouldn't be the first weird arch-linux-specific bug...

Comment 5

[Reed Law]

It is the Arch packaged version. Here is the PKGBUILD: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox

You can see most of the modifications are to the build process in order to make it work in the Arch Linux environment.

Comment 6

[:Gijs (he/him)]

(In reply to Reed Law from comment #5)
> It is the Arch packaged version. Here is the PKGBUILD:
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/
> PKGBUILD?h=packages/firefox
> 
> You can see most of the modifications are to the build process in order to
> make it work in the Arch Linux environment.

I realize that this might be the case, but those modifications + linking of different libraries etc. might well be at issue here. It would still be very useful for you to download and test an official build to exclude that vector.

Comment 7

[Reed Law]

The Arch Users Repository has a package, https://aur.archlinux.org/packages/firefox-esr-bin/, which provides version 31.1.0, an Extended Support Release binary. I installed that and started with a clean profile and tab switching was near instantaneous. I'll continue to use this version with my regular profile and see if the slow switching is alleviated. If so, I will file a bug for the Firefox package. I will mark this resolved for now. Thank you YF and Gijs!

Comment 8

[Reed Law]

Attachment: firefox_tabs.mp4

A screen capture of a 20+ second delay in changing tabs

Comment 9

[Reed Law]

Spoke too soon. The strange behavior also affects the Mozilla build (31.1.0 ESR). I made a screencast of the problem. At about 7" I click on the first tab and then leave the mouse cursor in the middle of the page. About 20 seconds later, I start moving the mouse and the tab immediately switches over. This isn't the first time I've noticed that mouse movement triggers a tab to display. The initial movement after I clicked the tab does nothing in these cases, but after a sufficient delay sometimes moving the mouse causes the tab to update.

I wasn't able to capture it this time, but there is also a strange effect that occurs sometimes where after clicking on a tab, the current tab and the previous tab flicker back and forth rapidly for a while until finally settling on the current tab.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Holy smokes, that's horrendous. Would you be comfortable gathering a profile for us, Reed, so we can see where the time is going there?

Link to download profiler add-on: https://github.com/bgirard/Gecko-Profiler-Addon/blob/master/geckoprofiler.xpi?raw=true

That'll add a button to your toolbar, and I believe it should start gathering data by default. Trigger the behaviour, and when you have control of your browser again, click on the button, and choose "Analyze" to open a new tab to show the profile. Once you've got a profile, there'll be a button in the profile tab in the bottom left to "Share" the profile. Click it, and when the profile is done uploading, copy and paste the resulting link in this bug.

Thanks Reed! Feel free to ask me if you have any questions on how to do that.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

I've received a profile from Reed.

The main thread is not blocked, but we seem to be waiting on something - 91.2% of the profile is spent calling "__poll_no_cancel" in libc.so.6.

I'm no systems specialist, but could this be related to http://linux.die.net/man/2/poll ?

karlt - do you know what Firefox could be polling for and waiting for for 91.2% of the time when switching tabs? With Reed's permission, I can send you the profile - but it looks like that 91.2% set of calls to __poll_no_cancel in libc.so.6 somehow comes directly from Startup:XRE_Main, which I kind of find hard to believe, but it's possible.

Any ideas, karlt?

Comment 12

[Karl Tomlinson (:karlt)]

Reed, are you using a compositing window manager?
Does it let you disable compositing to see whether that changes the visible behavior?
If a compositing window manager but compositing can not be disabled, are you able to experiment with a different window manager, please?

It looks from the screen capture that the position of the mouse, avoiding highlightable elements, and the lack of a blinking cursor may be part of what makes this reproducible in an obvious way.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #11)
> The main thread is not blocked, but we seem to be waiting on something -
> 91.2% of the profile is spent calling "__poll_no_cancel" in libc.so.6.

poll() is where the thread will wait if there are no events to process, so it is normal to spend most of the time in poll.  poll could also be waiting for the X server to respond, but the cpu is not busy, so that seems less likely.

Comment 13

[Reed Law]

I am using Gnome 3.12.2. I wasn't sure, but I checked and its window manager, Mutter, appears to be compositing.[1] Can you suggest a non-compositing window manager for me to try out? I will first try disabling compositing.

1. https://en.wikipedia.org/wiki/Mutter_%28software%29

Comment 14

[Reed Law]

Karl, you were right about the window manager. I switched desktop managers to LXDE which uses Openbox as its window manager. So far I have not been able to observe slow tab switching. So I guess I should report this issue to Gnome?

Comment 15

[Reed Law]

Bug has been reported here: https://bugzilla.gnome.org/show_bug.cgi?id=736669

Comment 16

[Wayne Mery (:wsmwk)]

The Gnome bug report is still open, but it sounds like this is not a Firefox bug, so => invalid