387414 - Firefox hangs with 100% CPU on View Page Source / Wrap Long Lines

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Marco Bonardo [:mak]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070912 Minefield/3.0a7pre

Browser hangs on unchecking Wrap Long Lines in View Source

1. Navigate to a website (http://www.mozilla.org/projects/minefield/)
2. From context menu choose View Page Source
3. In The source window menu check View / Wrap Long Lines
4. long lines are wrapped
5. Again: In The source window menu uncheck View / Wrap Long Lines
6. cpu goes to 100% and browser hangs

i can reproduce this every time

Comment 1

[Radek 'sysKin' Czyz]

I can confirm, but ONLY with syntax highlighting off.

Comment 2

[Marco Bonardo [:mak]]

i can reproduce with sintax hilighting on or off, does not make difference on my system

Comment 3

[-fullmetaljacket-]

yes, i can only reproduce the hang when i turn off syntax highlighting.

Comment 4

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #2)
> i can reproduce with sintax hilighting on or off, does not make difference on
> my system
>
The same here. 

Comment 5

[Peter Weilbacher]

Happens with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/200707110202 SeaMonkey/2.0a1pre, too.

Comment 6

[Peter Weilbacher]

I am not 100% sure it is useful but as the symptoms are the same in SeaMonkey on OS/2 I think this is relevant. I ran a SeaMonkey OS/2 debug build of the current trunk and got the following three assertions _many_ times, after a while it ends in an NS_ABORT:

###!!! ASSERTION: Invalid offset: 'aOffset <= mSkipChars->mCharCount',
   file <path>/gfx/thebes/src/gfxSkipChars.cpp, line 92
###!!! ASSERTION: redo line on totally empty line: 'aState.IsImpactedByFloat()', 
   file <path>/layout/generic/nsBlockFrame.cpp, line 3428
###!!! ASSERTION: unconstrained height on totally empty line: 
   'NS_UNCONSTRAINEDSIZE != aState.mAvailSpaceRect.height',
   file <path>/layout/generic/nsBlockFrame.cpp, line 3430
[...]
###!!! ASSERTION: Invalid offset: 'aOffset <= mSkipChars->mCharCount',
   file <path>/gfx/thebes/src/gfxSkipChars.cpp, line 92
###!!! ASSERTION: redo line on totally empty line: 'aState.IsImpactedByFloat()', 
   file <path>/layout/generic/nsBlockFrame.cpp, line 3428
###!!! ASSERTION: unconstrained height on totally empty line: 
   'NS_UNCONSTRAINEDSIZE != aState.mAvailSpaceRect.height', file 
   <path>/layout/generic/nsBlockFrame.cpp, line 3430
Block(pre)(0)@0x221325f4: yikes! spinning on a line over 1000 times!
###!!! ABORT: file <path>/layout/generic/nsBlockFrame.cpp, line 3211

Comment 7

[Elmar Ludwig]

I see this on Linux as well, this is likely caused by the textframe changes in bug 367177 (need to check regression range to be sure). See also bug 387058, which is about some of the same assertions.

Comment 8

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

marking blocking-1.9 because it was blocking firefox3

Comment 9

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

Attachment: simplified testcase

Here's what happens:
-- we reflow the text with -moz-pre-wrap first. This produces three frames: "Hello", "\n", "Kitty"
-- the style changes to pre. We reconstruct text runs, and assign one run to the first line "Hello\n", and another run to the second line "Kitty".
-- we reflow the first frame. It gets the text "Hello\n".
-- we reflow the second frame. It gets no text at all because its text run has no text left in it. This is incorrect and eventually leads to assertions and an abort.

We could try to make textrun construction avoid stopping at preformatted \n when there are more frames than necessary mapping the text up to the \n, but that's expensive to check --- it could require checking of all the text in a large plain text page. So it's probably better to detect situations where a text frame's text run is insufficiently long to reflow the text in the frame, and reconstruct the text run in that case.

Comment 10

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

Attachment: fix

As described in the above comment. We detect when we're at the end of the textrun and recover by recreating our textrun.

Comment 11

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

Checked in

Comment 12

[Elmar Ludwig]

Verified fixed in Minefield/3.0a9pre ID:2007101214