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

RESOLVED FIXED

Status

()

--
critical
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: clark.andy, Assigned: dholbert)

Tracking

(5 keywords)

Trunk
x86
All
assertion, crash, regression, verified1.9.0.7, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 +
wanted1.9.0.x +
wanted1.8.1.x -

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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.
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)
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: General → Printing
Ever confirmed: true
Keywords: crash, regression
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → printing
Summary: Crash after clicking 'Print This Page' on National Grid website (Firefox 3 RC1) → Crash after clicking 'Print This Page' on National Grid website (Firefox 3 RC1) [@ ReparentFrame(nsIFrame*, nsIFrame*, nsIFrame*)]
Version: unspecified → Trunk
Created attachment 322450 [details]
Testcase #1
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
Keywords: assertion
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().
Blocks: 405577
Component: Printing → Layout: Block and Inline
QA Contact: printing → layout.block-and-inline
s/propagate/propagate it to/

Comment 7

11 years ago
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?
(Reporter)

Comment 8

11 years ago
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.
(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

11 years ago
(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.
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Mats, can you look at this?
Flags: wanted1.9.1? → wanted1.9.1+
(Assignee)

Comment 12

11 years ago
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.
Assignee: nobody → dholbert
Depends on: 440149
(Assignee)

Updated

11 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 13

10 years ago
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
Flags: blocking1.9.2?
(Assignee)

Comment 14

10 years ago
(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.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Flags: blocking1.9.2?
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.
(Assignee)

Comment 16

10 years ago
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.
Keywords: fixed1.9.0.7, fixed1.9.1
Flags: wanted1.8.1.x-
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.
Keywords: fixed1.9.0.7, fixed1.9.1 → verified1.9.0.7, verified1.9.1
Crash Signature: [@ ReparentFrame(nsIFrame*, nsIFrame*, nsIFrame*)]
You need to log in before you can comment on or make changes to this bug.