435664 - Crash after clicking 'Print This Page' on National Grid website (Firefox 3 RC1) [@ ReparentFrame(nsIFrame*, nsIFrame*, nsIFrame*)]

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[Andy Clark]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

When you click 'Print This Page' at http://www.nationalgrid.com/uk/Gas/Connections/CompetitiveQuotationForm/CompetitiveQuotation.htm Firefox crashes.  This works in IE, Opera and Safari.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.nationalgrid.com/uk/Gas/Connections/CompetitiveQuotationForm/CompetitiveQuotation.htm
2. Click 'Print this page' on upper right hand side
3. Watch it crash
Actual Results:  
Firefox terminates, then I get the dialog box asking me if I want to send info to Microsoft.

Expected Results:  
data should be sent to the printer

Fails every time.

Comment 1

[Mats Palmgren (inactive)]

Also crashes Fx3 RC1 on Linux: bp-fe38b9cc-2a82-11dd-b362-001cc4e2bf68
No crash with Fx2.0.0.14 (it doesn't print all content though)

Comment 2

[Mats Palmgren (inactive)]

Regression window: 2007-12-05-04 -- 2007-12-06-04
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-05+03%3A00&maxdate=2007-12-06+05%3A00&cvsroot=%2Fcvsroot

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 4

[Mats Palmgren (inactive)]

I see the following assertions before the crash in a debug build:

###!!! ASSERTION: unexpected flow: 'mFrames.ContainsFrame(nextInFlow)', file /usr/moz/checkin/mozilla/layout/generic/nsInlineFrame.cpp, line 469

###!!! ASSERTION: StealFrame failure: 'NS_SUCCEEDED(rv)', file /usr/moz/checkin/mozilla/layout/generic/nsContainerFrame.cpp, line 1116

Comment 5

[Mats Palmgren (inactive)]

Adding back "availableWidth = PR_MAX(0, availableWidth);" in
nsInlineFrame.cpp fixes the crash, thus a regression from bug 405577.

Printing the values that makes the local 'availableWidth' negative
(without the PR_MAX): aReflowState.availableWidth -300, leftEdge 0, aReflowState.mComputedBorderPadding.right 0

With PR_MAX, aReflowState.availableWidth still is negative, it's just
that we don't propagate BeginSpan().

Comment 6

[Mats Palmgren (inactive)]

s/propagate/propagate it to/

Comment 7

[Dave Garrett]

Attempted to reproduce in 3rc1 under Linux and Windows XP using both the link at the URL and in the attached testcase.  Cannot reproduce at all.

This happens in a new profile, I assume?  Maybe a plugin's doing?

Comment 8

[Andy Clark]

I removed all add-ons(one was disabled, two were not) so now I have no add-ons at all.  Problem remains exactly as before.

Comment 9

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

(In reply to comment #7)
> Attempted to reproduce in 3rc1 under Linux and Windows XP using both the link
> at the URL and in the attached testcase.  Cannot reproduce at all.
> 
> This happens in a new profile, I assume?  Maybe a plugin's doing?

Given that Mats (a developer) can reproduce the bug just fine, it seems somewhat unnecessary to make the reporter jump through a whole bunch of additional hoops here.  (For that matter, I see it as well on Linux.)

Comment 10

[Dave Garrett]

(In reply to comment #9)
> Given that Mats (a developer) can reproduce the bug just fine, it seems
> somewhat unnecessary to make the reporter jump through a whole bunch of
> additional hoops here.  (For that matter, I see it as well on Linux.)

Just a generic question; no "hoops" implied. I'm just curious as to what's causing this, as the testcases don't seem to work for me in multiple OSes.  If Mats or someone else can reproduce and fix it satisfactorily, great, then it doesn't really matter.  Just curious as to what's actually triggering this, that's all.

Comment 11

[Samuel Sidler (old account; do not CC)]

Mats, can you look at this?

Comment 12

[Daniel Holbert [:dholbert]]

I can reproduce the crash with both the URL and the attached testcase, using Print Preview in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081016 Minefield/3.1b2pre.

However, the crash goes away when I apply attachment 343277 [details] [diff] [review], the patch for the bug 440149. (That patch basically adds back the line that Mats mentioned in Comment 5, but just for certain conditions.)

--> Stealing this bug, and adding dependency on bug 440149, since it looks like that bug's patch may fix this one.

Comment 13

[Daniel Holbert [:dholbert]]

FWIW:
 - The URL no longer crashes for me, using an up-to-date m-c nightly.  I'm guessing the web host changed their site.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090106 Minefield/3.2a1pre
 
 - This bug's testcase still crashes for me, when I print-preview it.

 - roc's patch (attachment 355727 [details] [diff] [review]) on bug 440149 fixes this crash.

I still get these assertions after applying that patch, though:
###!!! ASSERTION: We placed a float where there was no room!: 'psd->mX - mTrimmableWidth <= psd->mRightEdge', file nsLineLayout.cpp, line 345
###!!! ASSERTION: the pointer to this sibling will be overwritten: '!aNewFrame->GetNextSibling()', file nsFrameList.cpp, line 176
#
###!!! ASSERTION: root view manager's default background isn't opaque: 'needTransparency || NS_GET_A(backgroundColor) == 255', file nsPresShell.cpp, line 5345

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to comment #13)
>  - roc's patch (attachment 355727 [details] [diff] [review]) on bug 440149 fixes this crash.

That patch just landed, and I subsequently confirmed that an updated mozilla-central build no longer crashes when print-previewing this bug's testcase.
 --> Resolving as FIXED.

Comment 15

[Mats Palmgren (inactive)]

I only see the "We placed a float where there was no room!" assertion
in a current trunk build on Linux, not the other ones above.
I've added a comment about it in bug 439204.

Comment 16

[Daniel Holbert [:dholbert]]

The patch for bug 440149 just landed for 1.9.1 and 1.9.0.7, fixing this in those builds.  --> Adding appropriate fixed keywords here.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

Verified fixed in 1.9.0.7 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7pre) Gecko/2009021304 GranParadiso/3.0.7pre. 

Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090213 Shiretoko/3.1b3pre.