Closed Bug 239725 Opened 21 years ago Closed 19 years ago

crash on print preview of chrome uri

Categories

(SeaMonkey :: General, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: eck, Unassigned)

References

()

Details

(Keywords: crash)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 First, open a internal chrome:-uri in the browser, second open the print-preview. Mozilla chrashes. Every time. On Linux and on Win32. Reproducible: Always Steps to Reproduce: 1. open a internal chrome:-uri in the browser, eg. chrome://messenger/content/messenger.xul 2. open the print-preview. Actual Results: Mozilla chrashes. Every time. On Linux and on Win32. Expected Results: show the print-preview of the chromes xul-file
> First, open a internal chrome:-uri in the browser That's not supported, you realize. Doing this is at your own risk. Is there a talkback incident ID for this crash?
worksforme with build 2004-04-04-13 on WinXP.
(In reply to comment #1) > That's not supported, you realize. Doing this is at your own risk. Sure. But it should not crash the whole browser, I think. Even disabling the print preview is better than a crash. > Is there a talkback incident ID for this crash? Nope, sorry.
Personally I think we should simply disallow entry of chrome:// URIs in the location bar. As for this crash, in a debug build I get: ###!!! ASSERTION: XUL documents should never be scrollable - see above: '!isXUL', file /home/bzbarsky/mozilla/xlib/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 3677 ###!!! ASSERTION: grandparent should be root box: 'NS_SUCCEEDED(res)', file /home/bzbarsky/mozilla/xlib/mozilla/layout/xul/base/src/nsPopupSetFrame.cpp, line 165 ###!!! ASSERTION: unexpected null pointer: 'rootBox', file /home/bzbarsky/mozilla/xlib/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 5651 ###!!! ASSERTION: Unable to install the scrollbar mediator on the listbox widget. You must be using GFX scrollbars.: 'Error', file /home/bzbarsky/mozilla/xlib/mozilla/layout/xul/base/src/nsListBoxBodyFrame.cpp, line 253 ###!!! ASSERTION: no font available: 'font && font->entry', file /home/bzbarsky/mozilla/xlib/mozilla/gfx/src/ps/nsFontMetricsPS.cpp, line 166 ###!!! ASSERTION: Error: Could not find pageSequence!: 'NS_SUCCEEDED(rv)', file /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsPresShell.cpp, line 3533 This last one is what leads to the crash: (gdb) frame #0 0x4135d906 in nsPrintEngine::ReflowPrintObject(nsPrintObject*, int) (this=0x8e71640, aPO=0x8e71868, aDoCalcShrink=1) at /home/bzbarsky/mozilla/xlib/mozilla/content/base/src/nsPrintEngine.cpp:2823 2823 pageSequence->GetSTFPercent(aPO->mShrinkRatio); (gdb) p pageSequence $1 = (class nsIPageSequenceFrame *) 0x0 So the executive summary is: printing documents like this is totally broken, and we really have no incentive to fix it except in the grand context of fixing XUL printing.
Yeah, we should disable print and print preview of XUL documents until XUL printing does something reasonable.
Robert O'Callahan wrote: > Yeah, we should disable print and print preview of XUL documents until XUL > printing does something reasonable. 1. AFAIK this was tried long ago and was removed again since it regressed something else. 2. Not all XUL documents crash. HTML with embedded XUL widgets did work some time ago... still... many XUL widgets are hightly allergic against printing. But that doesn't mean we should disable that completely.
For the log: I would vote to continue to make the XUL implementation in Mozilla better - less hacks and more standard ways to handle XUL. Right now XUL is implemented as a horrible hack which causes many of the problems... but I guess this will be solved step-by-step (for example making XUL proprtly working with DOM etc.). Instead of turning XUL printing OFF I suggest that someone makes testcases for each type of XUL widget and tests whether that prints and files bug reports for problems... that way we could eliminate the bugs. Just turning XUL printing OFF would prevent people from fixing bugs in that area.
Keywords: crash
Print Preview of a chrome:// URI such as chrome://messenger/content/messenger.xul itself doesn't crash for me, however CLOSING that Print Preview window does, indeed. See bug 243669 for that.
Product: Browser → Seamonkey
With 2005031005/SM-trunk/WXP I can't open Print Preview for messenger.xul. After Print Preview progress dialog, error message "Print Preview Error - We are unable to Print or Print Preview this page" appear. Should this be closed as WFM?
Adam, a hackaround was implemented to simply prevent all print printing or print preview of XUL pages until bugs like this one are fixed. So I wouldn't resolve this bug unless you want to make sure that we're never able to print XUL.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.