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

Status: VERIFIED FIXED

(Core :: Preferences: Backend, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Screenshot: No arrows.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Adding keywords.  This is highly visible so adding topperf in addition to perf.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

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?

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

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

[R.K.Aa.]

Hmm. With an hour old CVS build, Linux, arrows are all there..

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

blizzard, is this caused by your recent checkins in widget ?

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

Dont know what I was thinking when I entered the perf keywords.  Just the shock
of this bug overwhelmed me :)

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 10

[Markus Gerstel]

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

[Markus Gerstel]

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 [e-mail]

Comment 12

[Blake Ross]

If this was caused by bug 97528, then dp should own it.

Comment 13

[Aleksander Adamowski]

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

[Aleksander Adamowski]

Attachment: Testcase: A form with SELECT and INPUT that causes the problem

Comment 15

[Aleksander Adamowski]

Attachment: Testcase: A similar form but without SELECT to show the difference

Comment 16

[Markus Gerstel]

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.

Comment 17

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

[Aleksander Adamowski]

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

[John Morrison]

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].

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[John Morrison]

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

Comment 22

[John Morrison]

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

Comment 23

[R.K.Aa.]

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

Comment 24

[Andreas M. "Clarence" Schneider]

I see this with a new profile too (2001-09-09-08, Win NT).
Arrows are missing with classic theme only.

Comment 25

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 26

[Darin Fisher]

res/jar changes backed out... marking this bug FIXED.  please verify.

Comment 27

[Markus Gerstel]

wfm with current cvs

Comment 28

[Matthias Versen [:Matti]]

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

Comment 29

[John Morrison]

Worksforme in a cvs build on win32 built in the past hour. Verified. Thanks.

Comment 30

[Jon Granrose]

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

Comment 31

[Boris Zbarsky [:bzbarsky]]

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