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...
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 ?
OS: Linux -> All Same problem on OS/2.
OS: Linux → All
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.
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.
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?
Mozilla also crashes if images are unchecked in the preferences menu. What's going on? I'm scared to adjust these preferences now.
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.
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
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)
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.
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-
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...
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.
*** Bug 193779 has been marked as a duplicate of this bug. ***
Assignee: bugs → prefs
QA Contact: bugzilla
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
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]
(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]
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
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.