Closed Bug 420102 Opened 16 years ago Closed 16 years ago

Firefox exhibits strange delays while and immediately after loading a page.

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: vvasaitis, Unassigned)

Details

(Keywords: perf, regression) 

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; el; rv:1.9b4pre) Gecko/2008022714 Firefox/3.0b4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; el; rv:1.9b4pre) Gecko/2008022714 Firefox/3.0b4pre

Hi,

I'm having a very strange problem with Firefox trunk builds here. While Firefox is loading a page, it seems to get "stuck" at regular intervals: suddenly it becomes unresponsive for 1-2 seconds, during which nothing on the window is updated, the mouse pointer doesn't change shape, and it doesn't respond to clicks (though it will respond to them once it unfreezes). This behaviour also manifests a few seconds after the page has finished loading. After that, Firefox will "stabilize", and be super responsive again up until the point where a new page is loaded, when this starts over again. This behaviour also appears when creating/destroying tabs.

When this happens, CPU usage doesn't go up. I.e. Firefox appears to be blocking for something, rather than doing some CPU-intensive work.

A few words about my environment: I'm running Firefox trunk builds of my own, at the moment 1-2 days old straight from CVS (but I've also built the released betas and they've exhibited the same problem). This is Linux x86-64, so I'm building Firefox myself because there are no official builds for this platform. Here is my current mozconfig:

----------------------------------------
# enable an objdir
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@

# pull the greek language
mk_add_options MOZ_CO_LOCALES=el

# build firefox
. $topsrcdir/browser/config/mozconfig

# make this a proper firefox build
ac_add_options --enable-official-branding

# optimization
ac_add_options --enable-optimize="-Os -fno-strict-aliasing"
ac_add_options --disable-debug

# graphics toolkit
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --enable-pango

# static build
ac_add_options --enable-static
ac_add_options --disable-shared
ac_add_options --disable-libxul

# use jemalloc
ac_add_options --enable-jemalloc

# tests
ac_add_options --disable-tests

# default language
ac_add_options --enable-ui-locale=el

# use system libraries when possible
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
----------------------------------------

The computer is running Debian unstable, with a fairly recent X server and X driver, on an Intel 945G integrated graphics chipset. My home directory is on AFS. I've tried removing all extensions and plugins and it didn't make any difference.

On the same computer, Firefox/Iceweasel 2.0 does not exhibit the problem. On my home computer (32-bit userland, nVidia binary drivers, no AFS) no version of Firefox exhibits the problem.

Any ideas? Anything I could try? This really makes the browser extremely frustrating to use.

Thanks,
Vasilis


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Version: unspecified → Trunk
> but I've also built the released betas and they've exhibited the same problem

Which betas exactly?

If you've been doing your own builds for some time, can you remember when
you first saw the problem?

Can you reproduce it in an official (32-bit) nightly build?

OK, first of all: if I create a new, clean profile, that profile does not exhibit the problem. If you feel this is enough to dismiss the bug, well ok (but hopefully not).

Now, with my normal profile that *does* exhibit the problem:

- I built 3.0b1 and it doesn't exhibit the problem.
- I built 3.0b2 and it doesn't run; I get greek XUL errors on startup, both with the el and the en-US build. I'll try building again, or perhaps I should try deleting XUL.mfasl or something?
- The problem definitely existed from 3.0b3 onwards, and from what I can remember from 3.0b2 too, but I'm not sure so I'll double-check.
- I cannot try out i686 builds on this computer; they run but they are unable to resolve anything, for some reason.

Thanks for the info.  Do you have any add-ons/themes installed in the
original profile?  If so, maybe you could try disabling them one by one?
I don't have any add-ons or themes installed in this profile at the moment. I did have a few add-ons (adblock+ and refcontrol), but I removed them while trying to diagnose the problem, and it didn't make any difference. I even tried removing all plug-ins, again to no avail.
Ok, so their is something in this profile that causes it but a newly created
profile works?  First, can you make a backup copy of this profile so that
if the problem suddenly disappears we have something to go back to?
Can you help us analyze what the difference is between this profile
and a freshly created one?  Would you be willing to send it to a select
few developers for analysis?
What a great idea. I made a backup, and this prompted me to try out a few more tests. I can now confirm that removing my 4MB places.sqlite file eliminates the problem. So does copying it to a local filesystem (as I've mentioned, my home directory is on AFS) and symlinking to it from my profile. My guess would be that Firefox updates it fairly frequently, and this creates delays when doing so on a network filesystem?

I wouldn't mind sending files to specific people no.

(In reply to comment #6)
> My guess would be that Firefox updates it fairly frequently, and this
> creates delays when doing so on a network filesystem?

If so, I suspect this would also be a problem with slow local devices.

> I wouldn't mind sending files to specific people no.

Great.  Keep that profile backup copy around if we need it.
Thanks for your help.

-> Places (for further triage)
Component: General → Places
Flags: blocking-firefox3?
Keywords: perf
QA Contact: general → places
As this is still unconfirmed, it can't block, but adding some people who might be able to help.

I know that we've had some problems with AFS in other areas, but we might want to figure out a better strategy for cases where we're getting stopped up on slow devices where profiles are hosted (even if it's caching the required information locally, maybe?)
Flags: blocking-firefox3?
Regression from bug 408914?  (see also bug 421482)
Keywords: regression
Possible - probably a dupe of bug 421482.  Places should really be adding to the db on a background thread I think, but that's a fairly risky change at this point :(
(In reply to comment #8)
> As this is still unconfirmed, it can't block, but adding some people who might
> be able to help.
> 
> I know that we've had some problems with AFS in other areas, but we might want
> to figure out a better strategy for cases where we're getting stopped up on
> slow devices where profiles are hosted (even if it's caching the required
> information locally, maybe?)

If it is sqlite (my guess would be "yes" but it's impossible to know for this situation), then the blocking is because of the fsyncs required doing writing, not reading, so caching will not help anything.
I know I'm coming in a bit late, but I confirm this error.

The happens  to me in Firefox 3, Beta 5 on my OpenSuse10.3 32bit install.

This also happens on Firefox 3, Beta 5 portable apps version from John Hall in Windows XP SP2.  To be sure it wasn't just the portable  version I downloaded the installable version from Mozilla (same beta), and the same problem persists.  

This did not happen in the previous beta (4) and does not happen in Firefox 2.x or 1.5.x
(In reply to comment #12)
Is this Fx3b5 the version OpenSuse provides or the official version from Mozilla.org?  There are usually some kinks that appear in the downstream channels, so just checking.

Also, if you could copy your useragent (go to about: and copy it from the bottom), that would be useful.
I'm unable to give you the useragent for the firefox on my opensuse 10.3 immediately, but that was from Mozilla.org.  Not the opensuse provided one (if there even is one anywhere). 

User Agent from F3b5 provided by John Hall On XP Sp2: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
User Agent from F3b5 provided by Mozilla.org on XP Sp2:  Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

I'll report with the same from my OpenSuse install in about 3-4 hours.
Just a note, the issue in both Windows instances seems to be resolved by deleting out places.sqlite, I'll update with the linux soon.
OpenSuse Build:

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

Also fixed upon removing places.sqlite
Bulk closing all UNCONFIRMED bugs dealing with places that haven't had any bug activity in over 120 days, have no votes, and are not enhancement requests.

If you are still experiencing this issue in Firefox 3.0 or later, please re-open the bug with steps to reproduce (if they were not part of the original comment).
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.