47843 - style overflow: scroll crashes

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[gabriel]

Linux build 2000080505.

http://www.gigabeat.com


Mozilla starts loading and then freezes totally.

Comment 1

[Jeffrey Baker]

Yes, it does.

Comment 2

[Eugene Savitsky]

WFM WinMe build 2000080208, but is rendered stupid...

Comment 3

[Mats Palmgren (inactive)]

I see the weird layout too, but no freeze or crash. I have made a testcase for
the layout bug and hopefully it shows the freeze problem too (on Linux.)
The layout problem seems to be caused by this style rule:
BODY {overflow:scroll;}

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 5

[gabriel]

Yup, testcase is an instant crasher :-(

Comment 6

[Marcello Nuccio]

Test case freezes on linux build 080720, but no crash accur.

Comment 7

[gabriel]

That's what I meant ;-)

Comment 8

[Jeffrey Baker]

Minimal, HTML 4.01 Strict testcase is attached.  Bug is also apparent with
Transitional DTD.  The problem is the overflow: scroll style declaration.
Reassigning to style system.

Comment 9

[Jeffrey Baker]

Attachment: Minimal testcase

Comment 10

[Marcello Nuccio]

minimal testcase works (freezes) on linux build 080720.

Comment 11

[Hixie (not reading bugmail)]

This is WORKSFORME on Windows 2000, build 6.0.18.2000080908.
Is this a pp bug?

Comment 12

[Pierre Saslawsky]

No crash for me either. Reassigned to pavlov to investigate on Linux.

gabriel@: could you attach a stack trace? Thanks.

Comment 13

[gabriel]

Attachment: Stack trace (I think)

Comment 14

[Peter Trudelle]

reassigning to waterson, per pav (who thinks this is a layout problem)

Comment 15

[Chris Waterson]

Crasher. Marking [nsbeta3+]. Layout is somehow getting wedged in an infinite
loop (Linux only!) on a ridiculously simple test case. I doubt this is a
layout-specific problem, but I'll do initial investigation.

Comment 16

[Chris Waterson]

Because the body is set to have "overflow: scroll", the nsGfxScrollFrameInner
decides that it should turn its scrollbars on in the initial reflow.

To do this, it sets an attribute which makes the scrollbar become visible. This
triggers a reflow, and causes us to re-enter layout while doing the initial
reflow. From here, all hell breaks loose.

I think that the problem is that the pres shell doesn't think that it's
reflowing while it's doing the initial reflow (because nobody sets
mIsReflowing), and this causes it to merrily process the reflow commands.

Setting mIsReflowing before reflowing the root frame in
nsPresShell::InitialReflow() seems to fix the problem. Will this have other bad
side effects? It seems to pass initial sniff tests...

Comment 17

[Chris Waterson]

Attachment: set nsPresShell::mIsReflowing during initial reflow

Comment 18

[Chris Waterson]

fix checked in.

Comment 19

[Christine Hoffman]

No problem on the 8/28 build on Linux. Verifying bug fixed.

Comment 20

[Jesse Ruderman]

Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/5a6def05ccbc