<select> triggers 100% CPU usage, when visible, flickering caret, possibly missing arrows

VERIFIED FIXED

Status

()

--
blocker
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: caillon, Assigned: darin.moz)

Tracking

(4 keywords)

Trunk
perf, regression, smoketest, topperf
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

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
Created attachment 48680 [details]
Screenshot: No arrows.
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.

Comment 6

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

Comment 10

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

Comment 11

17 years ago
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 dp@netscape.com
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

Comment 12

17 years ago
If this was caused by bug 97528, then dp should own it.
Assignee: bnesse → dp
Severity: major → blocker
Keywords: smoketest
OS: Linux → All
Hardware: PC → All

Comment 13

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

Comment 14

17 years ago
Created attachment 48724 [details]
Testcase: A form with SELECT and INPUT that causes the problem

Comment 15

17 years ago
Created attachment 48725 [details]
Testcase: A similar form but without SELECT to show the difference

Comment 16

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

Comment 18

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

Comment 19

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

Comment 21

17 years ago
*** Bug 98903 has been marked as a duplicate of this bug. ***

Comment 22

17 years ago
*** Bug 98911 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Keywords: perf, topperf

Comment 23

17 years ago
*** Bug 98942 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → benc
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. ***
(Assignee)

Comment 26

17 years ago
res/jar changes backed out... marking this bug FIXED.  please verify.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 27

17 years ago
wfm with current cvs
*** Bug 99012 has been marked as a duplicate of this bug. ***

Comment 29

17 years ago
Worksforme in a cvs build on win32 built in the past hour. Verified. Thanks.
Status: RESOLVED → VERIFIED

Comment 30

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