176305 - overflow:auto applied to option creates an infinite loop

Status: RESOLVED DUPLICATE of bug 210269

(Core :: Layout, defect, P2)

Description

[Gérard Talbot]

The CSS rule
option { overflow:auto; }
will max the CPU usage %tage in windows task manager as the page loads. The CPU
usage %tage is maintained in the high 90%+, suggesting an infinite loop.
This is not happening in MSIE 6.

Reproducible: always. XP Pro SP1, build 2002102308.

Comment 1

[Gérard Talbot]

Attachment: Reduced test case

Open Windows Task Manager, Processes tab. Make sure the CPU [CPU usage in
View/Select Columns...] is visible.
Load the reduced test case.
The CPU usage percentage will be maintained very high.

Comment 2

[Copperfield]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021023
Confirming this behaviour.  When attempting to view the testcase, CPU usage
skyrocketed, and Mozilla never did render the testcase page; I had to
CTRL+ALT+DEL and terminate the browser window.

Comment 3

[Christopher Hoess (gone)]

WFM in 1.1 final, so it may be a regression. cc'ing jkeiser.

Comment 4

[Boris Zbarsky [:bzbarsky]]

we seem to be stuck in ::Reflow() continuously...

Comment 5

[Madhur Bhatia]

This is a regression.

I checked in the 2002-09-30trunk build (win2k)..... the testcase does not cause
the browser to hang.
Then I checked in 2002-10-03trunk build (win2k).... I see the hang here.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: stack showing how each reflow command posts a new one

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It seems like the problem is in nsGfxScrollFrameInner::AddRemoveScrollbar, where
we hit the code that does two opposite calls to SetScrollbarVisibility:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsGfxScrollFrame.cpp&rev=3.109&mark=1091-1092,1104-1105#1084

The UnsetAttr from the first of these (it's unsetting the "collapsed" attribute)
posts a reflow command with the stack in attachment 104052 [details].  Then we set the
attribute back, rinse, and repeat. :-)

So who owns nsGfxScrollFrame these days?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Judging from that checkin window, I'd guess this is the result of bug 145212.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No doubt.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll check it out, but not until next week. In the meantime feel free to assign
it to me.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

OK. :-)

I suspect it's not really your fault, just some somewhat broken code that you
exposed, but I could be wrong (and I'm not sure I'm understanding the code
correctly)...

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think that right now I understand the scrolling code as well as anyone, so it
might as well be mine :-).

Comment 13

[Andrew Schultz]

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

Comment 14

[Andrew Schultz]

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

Comment 15

[Christian Eyrich]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[Andrew Schultz]

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

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This should be fixed by my patch in bug 210269.

*** This bug has been marked as a duplicate of 210269 ***