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

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
17 years ago
7 months ago

People

(Reporter: mozillazine, Unassigned)

Tracking

({hang})

Trunk
Points:
---
Bug Flags:
blocking1.4.1 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [2012 Fall Equinox])

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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/
Yeah... doing all that reflowing of all the pages is slow...
(Reporter)

Comment 2

17 years ago
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

16 years ago
OS: Linux -> All
Same problem on OS/2.
OS: Linux → All

Comment 4

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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

15 years ago
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
Severity: normal → major
Flags: blocking1.4.x?
Summary: with many pages loaded, changing fonts or colors in preferences freezes Mozilla a few seconds → with many pages loaded, changing fonts or colors in preferences freezes Mozilla a few seconds or longer (100% CPU)
Whiteboard: crash
Keywords: hang
Whiteboard: crash

Comment 10

15 years ago
Created attachment 130239 [details]
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

15 years ago
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.
Flags: blocking1.4.x? → blocking1.4.x-
(Reporter)

Comment 12

15 years ago
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

15 years ago
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.
There's a performance problem somewhere, and someone should profile to try to
figure out where it is.

Comment 15

15 years ago
*** Bug 193779 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Assignee: bugs → prefs
QA Contact: bugzilla
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs

Comment 17

6 years ago
Is this still actual with modern PCs?
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA?]
Yes, but the definition of "many pages" has increased.
Whiteboard: [2012 Fall Equinox][CLOSEME 2012-11-01 INVA?]
Component: Preferences → Style System (CSS)
Product: SeaMonkey → Core
Hardware: x86 → All
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.
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.
Whiteboard: [2012 Fall Equinox]

Comment 21

9 months ago
(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?
Whiteboard: [2012 Fall Equinox] → [closeme 2018-01-01][2012 Fall Equinox]

Comment 22

9 months ago
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

7 months ago
Resolved per whiteboard and comment 22
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2018-01-01][2012 Fall Equinox] → [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.