Closed
Bug 435664
Opened 17 years ago
Closed 16 years ago
Crash after clicking 'Print This Page' on National Grid website (Firefox 3 RC1) [@ ReparentFrame(nsIFrame*, nsIFrame*, nsIFrame*)]
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: clark.andy, Assigned: dholbert)
References
()
Details
(5 keywords)
Crash Data
Attachments
(1 file)
(deleted),
text/html
|
Details |
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•17 years ago
|
||
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
Comment 2•17 years ago
|
||
Comment 3•17 years ago
|
||
Comment 4•17 years ago
|
||
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
Comment 5•17 years ago
|
||
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
Comment 6•17 years ago
|
||
s/propagate/propagate it to/
Comment 7•17 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•17 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.
Comment 9•17 years ago
|
||
(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.)
Updated•17 years ago
|
Flags: wanted1.9.0.x?
Comment 10•17 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.
Updated•16 years ago
|
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Comment 11•16 years ago
|
||
Mats, can you look at this?
Flags: wanted1.9.1? → wanted1.9.1+
Assignee | ||
Comment 12•16 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•16 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 13•16 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
Updated•16 years ago
|
Flags: blocking1.9.2?
Assignee | ||
Comment 14•16 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
Closed: 16 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.2?
Comment 15•16 years ago
|
||
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•16 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
Updated•16 years ago
|
Flags: wanted1.8.1.x-
Comment 17•16 years ago
|
||
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.
Updated•14 years ago
|
Crash Signature: [@ ReparentFrame(nsIFrame*, nsIFrame*, nsIFrame*)]
You need to log in
before you can comment on or make changes to this bug.
Description
•