2.07 KB, image/png
247 bytes, text/html
157 bytes, text/html
Linux 2001090721 While viewing any page with a select, such as any bug, there will be no select arrows viewable, and CPU usages shoots up to 100%. Leaving the page will restore CPU usage to normal. Screenshots coming
Adding keywords. This is highly visible so adding topperf in addition to perf.
Keywords: mozilla0.9.4, perf, regression, topperf
Also, URL Bar autocomplete stops working while viewing a page with a select. Hitting enter also doesn't do anything after typing a URL on this page. Probably due to the 100% CPU usage?
The one thing I know that was done involving <select> recently was the change I made in 97345 to nsHTMLSelectElement.cpp to AddOption() etc. I suggest backing out that patch and recompile to verify. I can't think why this would cause those symptoms, however - I mention it because it was a <select> change, and it went in yesterday. Fabian and I (and others) had been running the patch for a week or more with no trouble, though I did put in changes right before release to accomodate reviewer's requests. Also note that a 1-liner fix (to the last second updates) was checked in to fix bustage (added a return). To back out the entire change/patch, check out version 1.120 of nsHTMLSelectElement.cpp.
According to caillon, this isn't in a build from 13 hours ago, long after 97345 went in, so that's not it apparently.
Hmm. With an hour old CVS build, Linux, arrows are all there..
blizzard, is this caused by your recent checkins in widget ?
Dont know what I was thinking when I entered the perf keywords. Just the shock of this bug overwhelmed me :)
Keywords: perf, topperf
Blizzard: this isn't from your checkin. Sorry for the spam. Anyway, after hours of fiddling with what the problem could be, this seems to be a preferences problem. I tried with a new profile and it worked fine. After a while, then I tried to kill prefs.js completely from my existing profile, and it works fine. Still *This Should Not Occur* with my existing profile. Is there an incompatibilty that was introduced? I'll send my existing profile via e-mail to someone @ netscape on request. I'm going to bed and I'll report back whether or not it works in the morning with the 8am builds.
Assignee: rods → bnesse
Severity: critical → major
Component: HTML Form Controls → Preferences: Backend
QA Contact: madhur → sairuh
Summary: <select> has no drop-down arrows, uses 100% CPU → bad prefs.js causes <select> with no drop-down arrows, 100% CPU usage
Confirmed w/ linux. It took me some time, but I could trace the error back to Bug 97528. It wfm with MOZ_CO_DATE="07 Sep 2001 14:32 PST" and fails with 14:33 PST Now I'll have a look at my profile.
Success. The line user_pref("browser.cache.check_doc_frequency", 1); caused and still causes this problem. Whenever I set Cache to "Every time I view the page" the V's to not appear. Workaround : All other (cache-)settings are OK. I could reproduce this with the latest cvs-build and a new profile, too. Additional to high CPU usage (~60% on my computer) the caret flickers very fast in input textboxes - Only if caching is set to "Every time". So: Changing Summary and adding firstname.lastname@example.org
Summary: bad prefs.js causes <select> with no drop-down arrows, 100% CPU usage → Cache setting causes <select> with no drop-down arrows, 100% CPU usage, flickering caret
If this was caused by bug 97528, then dp should own it.
Assignee: bnesse → dp
Severity: major → blocker
OS: Linux → All
Hardware: PC → All
This is indeed a regression. I can reproduce it on Build 2001090808, but can't on Build 2001090703. However, I only see the flickering caret issue and CPU usage. Drop-down arrows are in place. In addition, I can see one more problem: It isn't possible to open a menu when a page with <SELECT> is shown. To reproduce this: 1. Launch Mozilla 2. Go to a page with <SELECT> and an <INPUT TYPE=text> 3. Click in the text input field - notice the flickering caret 4. Try to open a menu. Its name will be depressed as usual after clicking, but the menu won't be displayed. It's apparent on bugzilla query page. After I click inside a text box, text caret blinks very fast and CPU usage goes up to 99% and I can't open any menu. Testcase follows.
Created attachment 48725 [details] Testcase: A similar form but without SELECT to show the difference
In the 2nd testcase (without <select>) the caret is not flickering. Menus work for me. But on my CPU (Ath 1,3) the usage is far below 100%, so that may be the explanation.
Keywords: mozilla0.9.4 → mozilla0.9.5
w00t! thank you for tracking down the problem, Markus! Yes, I had my cache set to reload the page every time, and yes if I change my cache settings, everything works fine. It also explains why a new profile does not exhibit this problem. The default is once per session IIRC.
Markus: The second testcase is to show that without <SELECT> everything works fine. On my machine (Cel 700), the caret is not flickering, menus work and CPU doesn't go up with the second testcase. However, with the first testcase I can see all those effects at the same time. BTW I discovered one more thing: As has been said before, when displaying a page with a <SELECT>, Mozilla freezes and eats all the CPU and gets unresponsive. Even clicking on links doesn't work. However, if you minimize the Browser window or cover it with another window so it doesn't paint, CPU gets back to normal and Mozilla operates normally. So for example if you display this bug's page, affected Mozilla builds freeze. When you click on a link to a testcase, Mozilla doesn't go there. But if you minimize the window or suppress painting in some other way, Mozilla continues the operation in the background and goes to the testcase.
Good description of the problem above. This is pretty severe (e.g., if you load home.netscape.com, the browser is so busy that hitting return in the urlbar is not serviced for sometime; this can even delay the popup ad from showing, and we wouldn't want that :-]). Anyways, in an opt. cvs build with symbols, pulled about 6pm, when the browser would be locked up just viewing a page with a select (like the testcase on this bug), when I broke in the debugger, I was always "just" in the event loop (albeit obviously very busy). After trying a couple of other backouts (including Randell's select changes), I found it was darin's changes for the 'res' protocol. The backout below fixes this problem (from darin's part of 97528, not dp's). cvs update -j1.48 -j1.47 mozilla/netwerk/macbuild/netwerk.mcp cvs update -j1.1 -j0 mozilla/netwerk/protocol/res/src/nsResURL.h cvs update -j1.1 -j0 mozilla/netwerk/protocol/res/src/nsResURL.cpp cvs update -j1.74 -j1.73 mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp cvs update -j1.5 -j1.4 mozilla/netwerk/protocol/res/src/nsResProtocolHandler.h cvs update -j1.33 -j1.31 mozilla/netwerk/protocol/res/src/nsResProtocolHandler.cpp cvs update -j1.3 -j1.2 mozilla/netwerk/protocol/res/src/makefile.win cvs update -j1.12 -j1.11 mozilla/netwerk/protocol/res/src/Makefile.in cvs update -j1.5 -j1.4 mozilla/netwerk/protocol/res/public/nsIResProtocolHandler.idl darin: if you can't find a fix soon, you might want to back this out for the time being as it makes debugging web pages with <select> elements in them difficult. [Note: the earlier statement about cache setting is IMHO in error].
Assignee: dp → darin
Summary: Cache setting causes <select> with no drop-down arrows, 100% CPU usage, flickering caret → <select> triggers 100% CPU usage, when visible, flickering caret, possibly missing arrows
*** Bug 98897 has been marked as a duplicate of this bug. ***
*** Bug 98903 has been marked as a duplicate of this bug. ***
*** Bug 98911 has been marked as a duplicate of this bug. ***
*** Bug 98942 has been marked as a duplicate of this bug. ***
I see this with a new profile too (2001-09-09-08, Win NT). Arrows are missing with classic theme only.
*** Bug 99011 has been marked as a duplicate of this bug. ***
res/jar changes backed out... marking this bug FIXED. please verify.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
wfm with current cvs
*** Bug 99012 has been marked as a duplicate of this bug. ***
Worksforme in a cvs build on win32 built in the past hour. Verified. Thanks.
Status: RESOLVED → VERIFIED
*** Bug 98898 has been marked as a duplicate of this bug. ***
*** Bug 99302 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.