Closed
Bug 156982
Opened 23 years ago
Closed 20 years ago
close button in print preview crashes [@ nsContainerFrame::Destroy]
Categories
(Core :: Web Painting, defect, P2)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: tuukka.tolvanen, Assigned: roc)
References
()
Details
(Keywords: crash, testcase, topcrash)
Crash Data
Attachments
(14 files, 3 obsolete files)
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain; charset=UTF-8
|
Details |
Found this while testing for bug 156965, stack and timing are different. From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020711 BuildID: trunk cvs 2002-07-11 1) load http://www.fileplanet.com/index.asp 2) file>print preview 3) hit 'close' -> crashes. Reproducible: Always
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'[JavaScript Error: "rogressParams is not defined" {file: "chrome://global/content/printPreviewProgress.js" line: 79}]' when calling method: [nsIWebProgressListener::onProgressChange]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://navigator/content/browser.js :: FinishPrintPreview :: line 284" data: yes] ************************************************************ {~/src/mozilla/mozilla}$ egrep -r --line-number "[^[:alpha:]]rogressParams" . ./xpfe/global/resources/content/printPreviewProgress.js:79: var docURLStr = elipseString(rogressParams.docURL, true);
Reporter | ||
Comment 3•23 years ago
|
||
fixing the typo (comment 2) doesn't fix the crash -> spun off to bug 156984
WFM with N7.0PR1. However, I was able to crash a couple of Mozilla builds (attached) with rather different stacktraces.
The first stack trace reported in greer's stacks atachment 91024 matches the one in bug 138349, see that bug for details on why it's happening.
Comment 7•22 years ago
|
||
current CVS is crashing just opening Print Preview. Some different assertions: ###!!! ASSERTION: no prev in flow: 'PR_FALSE', file nsBlockFrame.cpp, line 5516 (a whole lot of that one) ###!!! ASSERTION: bad geometric parent: '(childState & NS_FRAME_OUT_OF_FLOW) || IsChild(aPresContext, aChild)', file nsBlockFrame.cpp, line 5288 ###!!! ASSERTION: no prev in flow: 'PR_FALSE', file nsBlockFrame.cpp, line 5516 4 of those (no prev in flow) ###!!! ASSERTION: bad geometric parent: '(childState & NS_FRAME_OUT_OF_FLOW) || IsChild(aPresContext, aChild)', file nsBlockFrame.cpp, line 5288 ###!!! ASSERTION: no prev in flow: 'PR_FALSE', file nsBlockFrame.cpp, line 5516 4 more of those (no prev in flow) ###!!! ASSERTION: bad push: 'overBegin != begin_lines()', file nsBlockFrame.cpp, line 4569 ###!!! ASSERTION: running past end: 'mCurrent != mListLink', file nsLineBox.h, line 537 (crash)
Comment 8•22 years ago
|
||
this crashes linux trunk build 20020728 and CVS when opening print preview. the stack is similar to the first one in greer's attachment (nsContainerFrame::Destroy). Debug build does not throw any assertions. if you remove almost anything from the testcase (even the action attribute on the form), it will not crash when opening print preview or closing it.
Comment 9•22 years ago
|
||
mozilla crash when just open "print preview" with the trunk(2002-8-6) But "http://www.fileplanet.com/index.asp" can be previewed on mozilla1.0, and browser won't crash when close preview dialog. There is another testcase which can cause mozilla1.0 crash when close print preview dialog.It's resource:///res/samples/test12.html
Comment 10•22 years ago
|
||
URL crashes with trunk build 2002052908 but not 2002052808 testcase crashes with trunk build 2002071708 but not 2002071522 current 1.0 branch builds do not crash on URL or testcase
Comment 11•22 years ago
|
||
using valgrind (http://developer.kde.org/~sewardj/) to open the testcase in print preview, it identifies these problems. Basically, it appears to be trying to double-free an nsView.
Comment 13•22 years ago
|
||
This patch could avoid crash for attachment 94901 [details] in comment 12. But can't resolve the preview display problem for that page. That problem is because print preview doesn't support CSS2 style. Should be another bug I think.
Comment 15•22 years ago
|
||
Comment on attachment 95082 [details] [diff] [review] patch to avoid crash for attachment 94901 [details] this patch does not fix this bug. it does not fix the URL or the testcase. it seems that the crash with attachment 94901 [details] is not related to this bug.
Comment 16•22 years ago
|
||
Seems like the original problem of this bug has been fixed.
The crash of attachment 94901 [details] must be another bug. Let me check and file.
![]() |
||
Comment 17•22 years ago
|
||
Comment on attachment 95082 [details] [diff] [review] patch to avoid crash for attachment 94901 [details] So.... 1) What actually triggers the crash if we have neither scrollbar? and 2) Why do we have neither scrollbar?
Comment 19•22 years ago
|
||
I don't know how relevant it is here, but see bug 161834 for some funny-business with mHas(Horizontal/Vertical)Scrollbar. It might be that one of those is erroneously set to "true" (something other than 0). You might check the actual value to see if it's 0, 1, or something random.
Comment 20•22 years ago
|
||
The reason is the <DIV> with position:fixed attribute can not be shown on preview page. So, the scroll frame be destroied without remove it's mInner from document's observers list. Who has idea how to fix the fixed problem in print preview?
Comment 21•22 years ago
|
||
Comment on attachment 95082 [details] [diff] [review] patch to avoid crash for attachment 94901 [details] r=rods
Attachment #95082 -
Flags: review+
Updated•22 years ago
|
Attachment #95082 -
Flags: review+
Comment 22•22 years ago
|
||
Comment on attachment 95082 [details] [diff] [review] patch to avoid crash for attachment 94901 [details] never mind on the r=rods, problems with "fixed" are known but have been low priority since very few sites use it.
Comment 25•22 years ago
|
||
Comment on attachment 95959 [details] [diff] [review] patch with Andrew Schultz's comments wouldn't it be better to set aHasScrollbar to PR_FALSE within AddRemoveScrollbar?
Comment 26•22 years ago
|
||
>So does the patch stop the PP crash? You mean the print preview crash? Yes, it stops the crash in attachment 94901 [details] >wouldn't it be better to set aHasScrollbar to PR_FALSE within >AddRemoveScrollbar? Yes, maybe it's better. a new patch iscoming
Comment 27•22 years ago
|
||
Comment 28•22 years ago
|
||
I was going to test the patch, but attachment 94901 [details] does not crash any of my
linux builds (current trunk, 1.1b, 1.0 or 1.0rc1).
Comment 29•22 years ago
|
||
I do crash with attachment 94901 [details] if I just add "aHasScrollbar=PR_FALSE;"
the check you added does then prevent the crash.
Comment 30•22 years ago
|
||
>I was going to test the patch, but attachment 94901 [details] does not crash any of my
>linux builds (current trunk, 1.1b, 1.0 or 1.0rc1).
Please make sure the window small enough that you can see the scrollbar of the
fixed DIV.
Comment 31•22 years ago
|
||
> Please make sure the window small enough that you can see the scrollbar of the
> fixed DIV.
that was it. Now I see the crash.
Comment 32•22 years ago
|
||
The "fileplanet" site is only using relative and absolute positioning. It would be very helpful if someone could reduce it down to a simplier testcase. I threw together a simple relative/abs example and it preinted fine. I think it is really unclear as to how a "fixed" positioned element should print, because it is fixed to the "viewport" what is a "viewport" when printing. Also, does the CSS spec say anothing about printing and fixed positioned elements? IE 6.x doesn't even support fixed position. I think we need to figure out why the rel/abs example doesn't work.
Comment 33•22 years ago
|
||
> The "fileplanet" site is only using relative and absolute positioning. It would > be very helpful if someone could reduce it down to a simplier testcase. that would be attachment attachment 93248 [details] (the third attachment here)
Comment 35•22 years ago
|
||
The reduced testcase (attachment #3 [details] [diff] [review]) doesn't crash on Win2k with the last patch applied, but the original site still crashes. So I am hoping there is a different reduced testcase that will crash on Win2k.
Comment 36•22 years ago
|
||
I think there are definitely multiple problems with the fileplanet page under Linux. The patch apparently fixes one of them, which might be the only one under Windows. On Linux, the first patch did not fix the testcase or the URL (I didn't try out the most recent patch). I tried tracking down what caused the regression, but (on Linux), the testcase regressed at a different time than the URL. see comment 10.
Comment 38•22 years ago
|
||
Yes, there are lots of problem here. I tested trunk build(Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020820) and got this result: 1)URL: crash when preview 2)testcase (attachment 932488) doesn't crash at preview and close preview 3)testcase for comment 9 (attachment 94091 [details]) crash when close preview. My last patch can fix the 3th problem.
Comment 39•22 years ago
|
||
The problem of attachment 94901 [details] will be fixed in a separate bug.(bug 163800)
![]() |
||
Comment 40•22 years ago
|
||
> Also, does the CSS spec say anothing about printing and fixed positioned > elements? From http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-position: In the case of paged media, the box is fixed with respect to the page, even if that page is seen through a viewport (in the case of a print-preview, for example) In other words, any position:fixed element should appear on all pages when printing, with the top/left/right/bottom offsets measured from the page content edge. Now that bug 163800 is fixed, what is left to do here?
Comment 41•22 years ago
|
||
> what is left to do here? stop double-freeing an nsView (comment 11) the behavior of attachment 93248 [details] has not changed on Linux.
Updated•22 years ago
|
Summary: close button in print preview crashes → close button in print preview crashes [@ nsContainerFrame::Destroy ]
Comment 43•22 years ago
|
||
roc :)
Assignee: pete.zha → roc+moz
Component: Print Preview → Layout: View Rendering
QA Contact: sujay → ian
Comment 46•22 years ago
|
||
This bug causes http://www.dto.tudelft.nl/ to crash 1.3 just by visiting it. See Bug 194631 for more details.
Assignee | ||
Comment 47•22 years ago
|
||
I retested all these on a new build and everything works --- except for the original crasher, print preview on http://www.fileplanet.com/index.asp! Can someone please confirm this? If this is correct, then we need a new reduced testcase for fileplanet. Thanks in advance...
Whiteboard: [wfm]
Comment 48•22 years ago
|
||
testcase crashes with linux trunk 2003041508
Attachment #93248 -
Attachment is obsolete: true
Comment 51•22 years ago
|
||
Yes, closing print preview is still crashing. Here is a recent incident: Incident ID 20041191 Stack Signature 0x0000009b 68744419 Email Address aha@pinknet.cz Product ID MozillaTrunk Build ID 2003051214 Trigger Time 2003-05-13 02:21:42 Platform Win32 Operating System Windows NT 5.0 build 2195 Module URL visited User Comments Trigger Reason Access violation Source File Name Trigger Line No. Stack Trace 0x0000009b nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 140] ViewportFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 68] nsLineBox::DeleteLineList [c:/builds/seamonkey/mozilla/layout/html/base/src/nsLineBox.cpp, line 307] nsBlockFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 425] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsTableFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableFrame.cpp, line 312] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsTableOuterFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 83] nsLineBox::DeleteLineList [c:/builds/seamonkey/mozilla/layout/html/base/src/nsLineBox.cpp, line 307] nsBlockFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 425] nsLineBox::DeleteLineList [c:/builds/seamonkey/mozilla/layout/html/base/src/nsLineBox.cpp, line 307] nsBlockFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 425] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] ViewportFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 68] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsBoxFrame::Destroy [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1104] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] nsBoxFrame::Destroy [c:/builds/seamonkey/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1104] nsGfxScrollFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 460] nsFrameList::DestroyFrames [c:/builds/seamonkey/mozilla/layout/base/src/nsFrameList.cpp, line 131] nsContainerFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 143] ViewportFrame::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 68] FrameManager::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp, line 517] PresShell::Destroy [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 1843] DocumentViewerImpl::InstallNewPresentation [c:/builds/seamonkey/mozilla/content/base/src/nsDocumentViewer.cpp, line 3747] nsPrintEngine::FinishPrintPreview [c:/builds/seamonkey/mozilla/content/base/src/nsPrintEngine.cpp, line 4551] nsPrintEngine::PrintPreview [c:/builds/seamonkey/mozilla/content/base/src/nsPrintEngine.cpp, line 1272] DocumentViewerImpl::PrintPreview [c:/builds/seamonkey/mozilla/content/base/src/nsDocumentViewer.cpp, line 3139] XPTC_InvokeByIndex [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102] XPCWrappedNative::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025] XPC_WN_CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1285] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 845] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2853] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 861] nsXPCWrappedJSClass::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1334] nsXPCWrappedJS::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 429] PrepareAndDispatch [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 119] SharedStub [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147] nsPrintProgress::DoneIniting [c:/builds/seamonkey/mozilla/embedding/components/printingui/src/win/nsPrintProgress.cpp, line 228] XPTC_InvokeByIndex [c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102] XPCWrappedNative::CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025] XPC_WN_CallMethod [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1285] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 845] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2853] js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 861] js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 936] JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3529] nsJSContext::CallEventHandler [c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1082] I just marked bug 205478 a dup...the stack above is from there.
Summary: close button in print preview crashes [@ nsContainerFrame::Destroy ] → close button in print preview crashes [@ nsContainerFrame::Destroy]
Comment 54•22 years ago
|
||
The URL from Bug 206156 crashes in todays win2k build (crash in the browser and not in print preview or while printing)
Assignee | ||
Comment 55•22 years ago
|
||
Matti, why did you mark 206156 a duplicate of this?
Priority: -- → P2
Comment 56•22 years ago
|
||
because I compared the top of the stacks in both bugs ? Sorry if i did a mistake with the duping...
Comment 58•22 years ago
|
||
Here is another testcase that cause the Mozilla crash on 'Scale' Selection menu bar, 'Landscape/Portrait' Button and 'Close' Button. Any one of those three features cause a top crash in Mozilla. For some reason, When I remove any one of those HTML tags such as DIV, P, <br>, etc... It no longer crash Mozilla. This testcase come from a duplicate of bug# 207098. More testcases is good, better than one testcase only.
Comment 59•22 years ago
|
||
Can anyone update the summary to include the 'Scale' Select-Option Bar and 'Portrait/Landscape' Menu bar which bug# 207098 is a duplicate of this bug? I don't have the permission for that.
Updated•22 years ago
|
Attachment #124233 -
Attachment mime type: text/plain → text/html
Comment 61•22 years ago
|
||
the URL hangs both Mozilla and Firebird 20030529. the testcase (attachment 120673 [details]) works in both. attachment 124233 [details] also induces the crash.
No longer blocks: 169811
Assignee | ||
Comment 62•22 years ago
|
||
None of these testcases work for me anymore, but fileplanet.com still crashes. This testcase is reduced from the fileplanet page and it DOES work for me as of today.
Assignee | ||
Comment 64•22 years ago
|
||
Better testcase. Here's roughly what happens: -- the frame for "featuredmod" is relatively positioned, so has a view. Furthermore it spans the page boundary so its continuation also has a view. -- the view for the relatively-positioned last "dailydlimg" is not correctly reparented from the first "featuredmod" view to the view for the continuation. That is why we crash. What I have to figure out is why the view for "dailydlimg" is not being reparented when that frame is pushed to the second page.
Assignee | ||
Updated•22 years ago
|
Attachment #124791 -
Attachment is obsolete: true
Assignee | ||
Comment 65•22 years ago
|
||
This reduces things even further by eliminating the wrapper DIVs that were present before. "dailydlimg" is a relatively positioned float which appears to get split. hmmmmm
Attachment #124795 -
Attachment is obsolete: true
Comment 66•22 years ago
|
||
chrome://global/content/MPL-1.1.html Mozilla crashes on this url as well. When I click close on the print preview button. Also print preview only shows 2 pages, when there should be more. Not sure if that's a new bug or related. Mozilla 1.4b In my opinion this is a blocker bug. I was typing a long email when Mozilla crashed. Any always reproducible bug on such a common feature is a blocker. Please do not release 1.4 with this bug.
Comment 67•21 years ago
|
||
Hey Folks! Just saw the bug fix on bug #212821. That bug is not related to this one but it spoke of print preview that show only one page in print preview while there is actually more than 1 pages. I will have to re-read that bug just a few more times to find out what that bug is really about. For now, I wonder if that bug fix might help to ease the aggrivated situation on this existing bug we have. So, can you all folks try out the newer build and see if this situation remain unchanged or just got a bit easier? Something that might will bring in some changes that we haven't see before? It should be interesting to find out what have changed or not. I can't download the latest build for a while. Thanks!
Comment 68•21 years ago
|
||
Used the nightly build, and it still crashes. Using:Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030908 Firebird/0.6.1+ I have also made some -I think- related testcases. http://home.hccnet.nl/m.wargers/test/mozilla/crash/print/ The first one in this directory crashes immediately in print preview. Te second one by closing the print preview. In the second testcase I have onley removed this style-rule: .groep{ background-color:#66cccc; width:950px; } To reproduce the crash: -you have to use the 'shrink to fit' scale option in print preview. -The test-case has to span more than one page. -I have to use boxes with float:left; position:relative;
Comment 69•21 years ago
|
||
Comment 70•21 years ago
|
||
Comment 71•21 years ago
|
||
2003090809/trunk/W2K is crashing on "Martijn's testcase 1" (-> TB23454385Y), "Martijn's testcase 2" (-> TB23454454H) and "even better" testcase (-> TB23454698M). All other testcases WFM.
Comment 72•21 years ago
|
||
Comment 73•21 years ago
|
||
Updated•21 years ago
|
Flags: blocking1.6?
Comment 75•21 years ago
|
||
You can't just block the Mozilla 1.6 release without a working patch. I have seen it all too often on other bugs which Asa commented that bug can't be blocked without a working patch.
Comment 76•21 years ago
|
||
That's not a requirement. However, we're unlikely to hold for bugs that we've shipped with before.
Comment 77•21 years ago
|
||
renominate if we get close to a fix for 1.6
Flags: blocking1.6? → blocking1.6-
Keywords: topcrash
Comment 78•20 years ago
|
||
Still confirmable with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040723 Firefox/0.9.1+.
Comment 79•20 years ago
|
||
still confirmable with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1 Talkback incident: TB1626150Q
With a current trunk build: 2004-12-03-04, I don't crash on neither any of the testcases listed in this bug, nor the site of www.fileplanet.com
Comment 81•20 years ago
|
||
Stephen, in comment #66 is repro (chrome://global/content/MPL-1.1.html -> Print Preview -> close), which is still crashing for me with 2004112306/SM-trunk/W2k. Unfortunatelly, I'm unable to submit Talkback incident ID. Could you retry it? Previously crashing "Martijn's testcase 1", "Martijn's testcase 2" and "even better" testcases are WFM with same build.
Adam, chrome printing/print-preview bugs are covered in bugs such as bug 218304, and are known to still crash on the trunk.
Comment 83•20 years ago
|
||
Stephen, all attached testcases and FilePlanet title page are WFM in 2004120304/SM-trunk/W2K. I'll fill bug for MPL issue. Could anybody try it on Linux, so we could mark it as WFM?
Reporter | ||
Comment 84•20 years ago
|
||
With seamonkey trunk linux gtk2+xft 20041204 I crash at step 2 of comment 0 [@ nsLineBox::IsEmpty], so I can't really test this one...
Updated•20 years ago
|
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Comment 85•20 years ago
|
||
Jay, this bug still exists on branch builds of Firefox. Seems that there is a patch which isn't currently checked into the trunk? -> REOPEN
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 86•20 years ago
|
||
Possibly related/dup printing problems using the URL from comment 0: Bug 273363 preview formatting out of bounds on Win2K Bug 278868 crash on print+preview on Win98SE
Comment 87•20 years ago
|
||
All the testcase don't crash for me on print preview, as far as I can tell, in the 2005-02-23 build (part of them already might have worked before the fix of bug 263825). However, the url crashes for me now on print preview. Talkback ID: TB4557724M The stack of that leads to bug 262403. A fix for that bug is already there and will probably be checked in soon.
Depends on: 262403
Comment 88•20 years ago
|
||
Ok, doesn't crash anymore in 20050324 build. Most likely fixed by the fix for bug 262403.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
Comment 89•20 years ago
|
||
v. (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+)
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsContainerFrame::Destroy]
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•