Closed
Bug 239725
Opened 21 years ago
Closed 19 years ago
crash on print preview of chrome uri
Categories
(SeaMonkey :: General, defect)
SeaMonkey
General
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
![]() |
||
Comment 1•21 years ago
|
||
> 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?
Comment 2•21 years ago
|
||
worksforme with build 2004-04-04-13 on WinXP.
Reporter | ||
Comment 3•21 years ago
|
||
(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.
![]() |
||
Comment 4•21 years ago
|
||
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.
Comment 6•21 years ago
|
||
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.
Comment 7•21 years ago
|
||
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.
Comment 8•21 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 9•20 years ago
|
||
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?
![]() |
||
Comment 10•20 years ago
|
||
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.
Comment 11•19 years ago
|
||
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/
Comment 12•19 years ago
|
||
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.
Description
•