147564 - with many pages loaded, changing fonts or colors in preferences freezes Mozilla a few seconds or longer (100% CPU)

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[Hervé]

description :
-------------
When you have many pages loaded in Mozilla (in tabs or windows), changing fonts
or colors in preferences freezes Mozilla during a few seconds... 

problem :
---------
In this situation, many "normal users" will think Mozilla is dying and kill the
Application (Could this lead to prefs corruption, by the way ???)

How to reproduce : 
------------------
- load 5 to 10 web pages in windows and/or tabs (the more you load, the longer
it freezes)
- go the the prefs -> Appearance -> Colors
- check/uncheck "system colors" or change colors
OR
- go the the prefs -> Appearance -> Fonts
- change one font size
then click OK to leave prefs and watch Mozilla crawl :-(

What should happen :
--------------------
at least, some "hourglass" or "watch" pointer should be displayed !
(or some "please wait" window should pop up)

Tried on this Browser/OS/PC : 
-----------------------------
Mozilla 1.0RC3 / Linux 2.2 (SuSE) / Pentium 400 * 256 MB RAM 
(quite fast machine)

Reproducible :
-------------
yes. easily.

Hervé - http://mozillazine-fr.org/

Comment 1

[Boris Zbarsky [:bzbarsky]]

Yeah... doing all that reflowing of all the pages is slow...

Comment 2

[Hervé]

Yes, it's so slow that the user needs to know that something's going on, that
it's perfectly normal but that it's er... slow :\ 

So, What about a "busy" pointer ? Is it possible ? 

I suppose that on closing the prefs, we could display that cursor, or even
better, some "please wait" message in the prefs window itself... but can we
guess the total time it will take to reflow all the pages ? or can we get a
signal from the reflowing process to warn us it's completed ?

Comment 3

[Felix Miata]

OS: Linux -> All
Same problem on OS/2.

Comment 4

[Chris Pickett]

in windows it is worse -- this _frequently_ causes mozilla to crash.  i thought
it was a preference toolbar problem but it isn't - changing them from the
preferences menu also causes mozilla to crash.  i sent a few talkback reports to
netscape.  how can i find these?  how can i generate a talkback report to attach
here?

this is a big problem!  suggesting major to critical priority!  as in i think it
should be fixed for 1.2.1 - i've lost data a couple of times already.

i'm using 1.2, nov. 26th.  it didn't happen with previous builds iirc.

also, i get this problem even with just one window open.

Comment 5

[Asa Dotzler [:asa]]

Chris Pickett's crashes in TalkBack look like this:
nsPresContext::PreferenceChanged
[c:/builds/seamonkey/mozilla/layout/base/src/nsPresContext.cpp, line 607]
nsPresContext::PrefChangedCallback
[c:/builds/seamonkey/mozilla/layout/base/src/nsPresContext.cpp, line 106]
pref_DoCallback [c:/builds/seamonkey/mozilla/modules/libpref/src/prefapi.cpp,
line 1188]
pref_HashPref [c:/builds/seamonkey/mozilla/modules/libpref/src/prefapi.cpp, line
1074]
PREF_SetBoolPref [c:/builds/seamonkey/mozilla/modules/libpref/src/prefapi.cpp,
line 570]
nsPrefBranch::SetBoolPref
[c:/builds/seamonkey/mozilla/modules/libpref/src/nsPrefBranch.cpp, line 202]
nsPrefService::SetBoolPref
[c:/builds/seamonkey/mozilla/modules/libpref/src/nsPrefService.h, line 57]
nsPref::SetBoolPref [c:/builds/seamonkey/mozilla/modules/libpref/src/nsPref.cpp,
line 205]
NavigatorImpl::Preference
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 5861]
XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2014]
XPC_WN_CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1282]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 841] 

This crash isn't showing up in the topcrash talkback list so it's not hitting
nearly as many users as other crash problems.

Comment 6

[Chris Pickett]

Thank-you for getting those.  I think probably the reason it isn't hitting many
people is because not everyone changes colors that frequently, and it might only
be a Win32 bug.  Is it a security problem?

Comment 7

[Chris Pickett]

Mozilla also crashes if images are unchecked in the preferences menu.  What's
going on?  I'm scared to adjust these preferences now.

Comment 8

[Felix Miata]

2003051210 OS/2 vacpp

With 15-20 tabs full, mailnews open, and CZ open, I tried changing all
non-western monospace fonts from 13px courier to 15px andale mono. CPU pegged.
After many minutes, probably 10+. I gave up waiting and rebooted.

After reboot, with only the browser open and no pages loaded, I made the same
changes, and prefs closed normally/immediately.

Comment 9

[Felix Miata]

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4) Gecko/20030821

Going into prefs to switch on or off or change the size of minimum fonts will
also trigger this.

I tried again essentially what I described in comment 8, with a new profile.
Total system lockup this time, after about 2 minutes of 100% CPU and
unacceptable system response. Machine is K6/2-550 with 256MB RAM.

normal -> major

whiteboard -> +crash

Comment 10

[Felix Miata]

Attachment: testcase - bookmarks for recreating comment 9

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624

Not the same machine as comment 9, but also K6/2-550 with 256MB RAM and
identical 4MB PCI graphics adapter.

Both machines use 1024x768, Modern, 8,895 byte userContent.css, 393 byte
chatzilla.css, and 800-1000 byte userChrome.css.

Using this to as best I could duplicate comment 9 (which may have had more
tab(s) open), it took over 19 minutes for the system to recover after clicking
OK after changing all proportional to Arial and all monospace to Andale Mono
16px for all non-Western that weren't already so set.

Comment 11

[Mike Kaply [:mkaply]]

This isn't going to block 1.4.1 - it's been around forever. If anyone was
actually looking at this, I'd consider it.

Comment 12

[Hervé]

true, it's not a blocker but you said it : it's been around forever. wouldn't it
be possible to pop a warning "this operation can be very long if you have many
windows/tabs opened, are you sure ? ok / cancel". 
i really don't know how hard it is coding this kind of stuff...

Comment 13

[Felix Miata]

Someone needs to look at it. Why can't reflowing pages wait until they are
focused? Being around "forever" doesn't justify perpetuating it. The way it is
now, it can take considerably less time to shut down, restart, set prefs, and
load 15 tabs than to simply change pref(s) in an open browser. The time it takes
to recover from a prefs change should never take even 30 seconds, much less many
minutes. At the very least a relnote for it should block 1.4.1.

Comment 14

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

There's a performance problem somewhere, and someone should profile to try to
figure out where it is.

Comment 15

[Andreas Kunz]

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

Comment 16

[Serge Gautherie (:sgautherie)]

(Filter "spam" on 'prefs-nobody-20080612'.)

Comment 17

[Phoenix]

Is this still actual with modern PCs?

Comment 18

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Yes, but the definition of "many pages" has increased.

Comment 19

[Boris Zbarsky [:bzbarsky]]

We could try throttling these (as in, detect how much time we've spent doing the restyles "recently" and post an event instead of doing it sync for the current prescontext.  Or something.

Comment 20

[Tony Mechelynck [:tonymec]]

Please don't yet remove the [2012 Fall Equinox] entry, it is still needed to track what happened to the bugs handled during the latest SeaMonkey Bug Event, where they ended up (possibly outside of the SeaMonkey product), etc. Results haven't yet all been tallied.

Comment 21

[Wayne Mery (:wsmwk)]

(In reply to David Baron :dbaron: ⌚️UTC-8 from comment #18)
> Yes, but the definition of "many pages" has increased.

I cannot reproduce with 58 beta, 700+ tabs. 

Can anyone here still reproduce?

Comment 22

[Felix Miata]

Seems fine here whether changing font size or toggling allow web page colors or both with est. 150-200 open tabs.
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.1; Build ID: 20171002000000

Comment 23

[Phoenix]

Resolved per whiteboard and comment 22