In Chimera .4 loading more than two tabs in the background causes chimera to become unresposive. It will then display the "spinning rainbow cursor of death" until the tabs have begun to load. If the user is loading the tabs in the background they would like to continue to browse the foreground tab, by becoming unresponsive chimera is preventing the user's desired behavior.

Hmmm.. I can't repro this. Wade, could you tell me what URL's you were loading in the background and foreground? Also, which build were you using?

definitely need more specifics on how to reproduce this, since I use tabs constantly without seeing this

Adding qawanted per comment 2.

I sometimes saw this bug from 0.2nightly -> 0.4release. I am now using nightly build August 9, and the severity and frequency of the slowdowns has improved. If 2+ tabs have a total width which is equal to the total width of the window (eg, because of extremely long page titles or many tabs), chimera will beachball until width_tab_total < width_window. Only one tab, even as wide as the entire window, has never caused this type of slowdown on my machine. It doesn't make a difference if the page content of those tabs is very small.

is this still a problem with a recent nightly build? simon checked in a fix for bug 156607 on 5 august, so i'm wondering how a build from 6 august (or more recently) would behave. if it's no longer an issue, this ought to be resolved as a dup...

I think this is still an issue; gecko just chugs the CPU too much during pageload.

i run into this frequently when i use chimera for stuff in bugzilla, since i often open tabs for each bug report i go through. sfraser (over aim) suggested getting Sampler data on this --i'll look into that. in the meantime, does anyone know if there's a bug filed in the Browser (mozilla/netscape) product which describes this problem? i couldn't find an appropriate one under the Browser:Tabbed Browser component, but that might not be the right place for it (since it's a different implementation for chimera).

i ran Sampler for opening 8 tabs in the background...it's a HUGE log, so i won't attach it right now. simon went over it, and it does indeed look like we're spending lots of time/effort in layout. i'd like to compare with how netscape/mozilla on OS X behaves, but i think that a Mach-O mozilla verification build would be the "fairest" comparison. couldn't find where Mach-O mozilla bits would reside, though (they aren't being built regularly, are they?)...i'd welcome pointers there. there was a minor bit where chimera tabs were being redundantly painted, he thinks it's not the main cluprit. i've filed bug 164733 for that.

found a verification build from 8/20, which am guessing is based off of the mozilla trunk: http://ftp.mozilla.org/pub/mozilla/nightly/latest/MacMozilla-MachO.dmg.gz after a quick glance, loading links in background tabs in moz-machO was also slow.

->bryner, who mentioned some ideas for debugging this. (brian, do reassign if needed).

really -> bryner

heh, thanks pink. i think bug 164706 and bug 164733 might be related to this bug.

Taking

*** Bug 159006 has been marked as a duplicate of this bug. ***

I think most of the problem here stems from the sledgehammer approach to processing PLEvents that hyatt added in nsToolkit. The nsToolkit code has a Cocoa timer that fires every 5 milliseconds, and each time calls ProcessPendingEvents() 20 times, or until there are no more events left to process. In my testing, this could block user events for 14 seconds or more (tested loading bugzilla queries). I'm going to check in some code that processes events for up to 200ms, and see how that affects pageload time. New code looks like: // the new way; process events until some time has elapsed, or there are // no events left AbsoluteTime bailTime = ::AddDurationToAbsolute(MAX_PLEVENT_TIME_MILLISECONDS * durationMillisecond, ::UpTime()); // use low-overhead timing routines while (1) { PRBool pendingEvents = PR_FALSE; mMainThreadEventQueue->PendingEvents(&pendingEvents); if (!pendingEvents) break; mMainThreadEventQueue->ProcessPendingEvents(); AbsoluteTime now = ::UpTime(); if (UnsignedWideToUInt64(now) > UnsignedWideToUInt64(bailTime)) break; }

Code checked in. Watching tinderbox pageload numbers.

This change made pageload about 19% slower.

I would like to suggest the following steps: 1) Postpone redrawing content in a background tab until the user tries to view the tab. 2) Put rendering for background tabs into separate, low-priority threads. This could make load times for background tabs a bit worse, but the foreground tab would load more quickly, and the GUI would be more responsive (I believe). If anybody else wants this, then we're definitely going to have to try a patch and benchmark the old and new load times in a test case (as well as changes in responsiveness).

See bug 177259

Cc'ing kmcclusk since he tackled similar native and plevent priority issues on Win32.

worksform with 2003090102 on 10.2.6.

Camino 0.7+, dual 867MHz G4 w/512MB ram. Loading 9 tabs simultaneously I can make Camino pinwheel for 7 seconds (rough estimate). Safari doesn't pinwheel at all, although tabs that haven't rendered yet are blank.

I'm experiencing the same behavior in Windows 2000, with both Mozilla (1.3-1.5) and Mozilla Firebird (0.7). So this problem is probably not OS-specific.

Added Geoff to cc since we talked about this bug and he thought he perhaps knew a way to fix this a bit.

Simon I'm closing this bug as: - I never really had this issue. - You recently solved the "sledgehammer approach to processing PLEvents". That last change makes sure that the UI always stays responsive even when Gecko is using lot's of cpu cycles. WFM using 20050130 NB