240490 - M17x FF10PR1 crash after closing Print Preview of XUL page [@ gklayout.dll - nsTreeBoxObject::GetTreeBody] [@ 0x00000000 - nsSplittableFrame::RemoveFromFlow] [@ PresShell::`vftable']

Status: VERIFIED FIXED

(Core :: Print Preview, defect)

Description

[Adam Hauner]

2004041310/trunk/W2K -> TB18570H

I was able to display Print Preview of XUL page (!) from bug 240484, but Mozilla
crashes after Print Preview was closed.

Repro:
1. open http://www.global-centre.com/interact/forums/xul/
2. Print Preview
3. close
-> crash

Comment 1

[Boris Zbarsky [:bzbarsky]]

Adam, you should be able to get the stack off the talkback server...

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

I can reproduce this with build 2004-04-14-08 on Windows XP (seamonkey).

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

TB19104Z, but I'm having problems finding either Adam's or my incidents on the
following page:

http://talkback-public.mozilla.org/

Comment 4

[Adam Hauner]

Yep, public TalkBack server doesn't show many of incidents. Maybe Jay should
know more?

Comment 5

[Olivier Cahagne]

in case stack is different, Talkback ID from Firefox 20040413 on Linux: TB19229M.

Comment 6

[Jay Patel [:jay]]

Regarding Talkback: Our current db server is running out of space and we have a
huge backlog of incidents waiting to be processed.  A few crashes are being
stored into the db daily, but most of them are stuck in a queue.  I know it
sucks, but there isn't much we can do about it until we get our new server and
upgrade the db.  We're hoping that will be soon. Sorry!

Comment 7

[Boris Zbarsky [:bzbarsky]]

So the summary is that something is very wrong.

Details are as follows:  We're crashing because PresShell::GetPageSequenceFrame
returns null (or at least something that does not QI to nsIPageSequenceFrame. 
What this code does is the following:

1)  Get the root frame (viewport)
2)  Get its first child (call it X)
3)  If X is a nsIScrollableFrame, return the scrolled frame
4)  Else, if we have a print preview prescontext, return the first child of X
5)  Else, return X

Now for HTML the child of the viewport is _always_ a scrollable frame, so we
follow the step 3 codepath.

For XUL, we don't create scrollbars on the viewport.  The child of the viewport
is the RootBoxFrame or PageSequenceFrame, depending on whether we're printing.

When we close print preview here, we hit step 4, and return the first child of
the PageSequenceFrame, which naturally does not QI to nsIPageSequenceFrame,
being a pageframe.

So the first thing I tried doing was eliminating step 4 altogether (since it
seems totally bogus).  But if I do that, I crash when going _into_ print preview
on the document in question.  At the time of that crash, the frame hierarchy
looks like this:

     ViewPortFrame
         ^
         |
     ScrollPortFrame
         ^
         |
     PageSequenceFrame

which is totally bogus -- there shouldn't be a scrollport frame hanging about
outside a GfxScrollFrame.  I assume step 4 was initially added as a workaround
for this bogus frame structure.  The question is how it manages to correct
itself by the time we're exiting print preview....  :(

Oh, the caller of GetPageSequenceFrame is nsPrintEngine::ReflowPrintObject,
which naturally does not check the rv (which is NS_OK in error cases anyway) or
the frame (and the best it could do would be to bail, I guess).

So the real problem is this random ScrollPortFrame that just shouldn't be there.

Comment 8

[Adam Hauner]

Boris: with 2004042009/trunk/W2K I'm not longer able to reproduce this crash
with  "load page -> Print Preview -> close" sequence.

But this build is crashing after changing anything in Print Preview (background
off -> TB26608, Portrait to Landscape -> TB26606, to 50% -> TB26604; public TB
server has all these stacktraces available, previous incidents are probably gone).

Comment 9

[H Beitman]

I am using 1.7RC1 on Win XP.  Print Preview causes immediate closing of the
browser (not e-mail) on all pages tried.  Printing works fine, but I can not
print preview at all.  This may be a different, but similar bug or the same issue.

H. Beitman

Comment 10

[Bruno 'Aqualon' Escherl]

I've seen the same with Mozilla 1.7RC2 (Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7) Gecko/20040514)

TalkBack ID: TB51091X

Comment 11

[Olivier Cahagne]

Attachment: Talkback data TB51091X

Comment 12

[Jay Patel [:jay]]

Adding M17rc2 and [@ 0x00000000 - nsSplittableFrame::RemoveFromFlow] to summary
and topcrash keyword for tracking.  I see a few crashes in early Mozilla 1.7 rc2
Talkback data and this has the potential to be topcrash.

Comment 13

[Jay Patel [:jay]]

Well, I was able to reproduce this with Mozilla 1.7 rc2, but my stack looked
different than the ones posted here.  I updated bug 243669 with my crash...but I
think it might be a dup of this one.  Steps to reproduce are the same.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If we care about this, then we should disable print and print preview for XUL. I
think there's probably a whole lot of issues with printing XUL and we shouldn't
try to get it working for 1.7.

Comment 15

[Roland Mainz]

Robert O'Callahan wrote:
> If we care about this, then we should disable print and print preview for XUL. 

That's no solution - that's only wallpapering over the problem. When you disable
it (again; a while ago the attempt was made to disable XUL printing/print
preview... but later that change was reversed) noone will care fixing the root
of the problem.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could disable it for 1.7.

Comment 17

[Bruno 'Aqualon' Escherl]

Since Mozilla 1.7 is the next long time stable release and developers are
supposed to use it as basis for their XUL developments it should contain the
ability to print XUL without any crashes.

I'm not a C++ programmer, so I can't say what's the definite problem here and
how long developing of a patch would need. I would prefer to delay Mozilla 1.7
final and bring another 2 or 3 RCs in the hope, that someone is able to find a
working solution for Mozilla 1.7 final. This way developers would also have more
time to work on the 1.8 trunk before branching of 1.8a, which would (at least in
my opinion) not be a bad idea.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can you explain why it's important for users to be able to print XUL?

Comment 19

[Bruno 'Aqualon' Escherl]

(In reply to comment #18)
> Can you explain why it's important for users to be able to print XUL?

For example if you want to print the error messages in the JavaScript Console.
With XUL-printing you would only have to call
chrome://global/content/console.xul and print it. Without you can either make a
screenshot (which probably doesn't contain all errors on one screen) and print
that or you copy each error, which would need a lot of time.

Another example could be the history. At the moment you have to make a
screenshot of the history and print it in another program. With XUL-printing you
could simply load chrome://communicator/content/history/history.xul and print
that page.

I think that there are even more things (perhaps a preferences dialog or), which
would profit from the ability of printing XUL.

I know, that this is something 99% of all users will never do and perhaps most
users don't even know, that you can open the dialogs directly in the browser
with chrome://...

One can certainly argue if it's really needed, but I would regard it as a useful
feature.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't think any of these reasons justify getting XUL printing working on the
branch. We should try to get it working for 1.8 I guess.

Comment 21

[Jay Patel [:jay]]

Adding [@ gklayout.dll - nsTreeBoxObject::GetTreeBody]  to summary since I'm
crashing under that stack signature closing print preview of
http://www.global-centre.com/interact/forums/xul/

See:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=60597

Comment 22

[Jay Patel [:jay]]

*** Bug 243669 has been marked as a duplicate of this bug. ***

Comment 23

[Olivier Cahagne]

*** Bug 240484 has been marked as a duplicate of this bug. ***

Comment 24

[Brian Bitzkowski]

(In reply to comment #0)
> 2004041310/trunk/W2K -> TB18570H
> I was able to display Print Preview of XUL page (!) from bug 240484, but 
Mozilla
> crashes after Print Preview was closed.
> Repro:
> 1. open http://www.global-centre.com/interact/forums/xul/
> 2. Print Preview
> 3. close
> -> crash

I have this problem too, Mozilla 1.8 Alpha 1. I also have many problems, only 
recently of Mozilla crashes. It seems that it gets caught into a loop, where it 
crashes every few hours, I reboot, Mozilla stays stable until next crash. It 
seems you have a higher chance of crashes if you have several tabs open 
(bookmark important tabs often). If you need more info about my errors, I can 
post them. I would like to help Mozilla be as stable as MSIE.

Comment 25

[Jay Patel [:jay]]

Adding [@  PresShell::`vftable'] to summary since my most recent crash with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040804
Firefox/0.9.1+ showed that stack signature when closing print preview:
http://talkback-reports.mozilla.org/talkback/quicksearch.jsp?search=2&type=iid&id=484719

Also marking this blocking-aviary1.0+ since many people are able to easily
reproduce this and it has been a topcrasher across many releases.

Comment 26

[Jay Patel [:jay]]

Definitely still crashing with Firefox 1.0 PR1.  We should probably find an
owner for this one if it's going to be looked at for 1.0.

Comment 27

[chris hofmann]

dbaron will have a look

Comment 28

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I agree with comment 14 that the appropriate branch solution is to back out bug
137526.

Comment 29

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: disable XUL printing / print preview

This is basically a backout of bug 137526.

Comment 30

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 161317 [details] [diff] [review]
disable XUL printing / print preview

bsmedberg, since I'm not sure what the late localization change policy
currently is, you get the review request

Comment 31

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Note that if we don't want the l10n change, the best error to use is probably:

NS_ERROR_NOT_IMPLEMENTED=Some printing functionality is not implemented yet.

Comment 32

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: alternative with no l10n change

Comment 33

[Benjamin Smedberg]

I prefer the version without the l10n change at this time... does this display a
generic error dialog to the user?

Comment 34

[Asa Dotzler [:asa]]

Bsmedberg, yes, it does. It displays "Some printing functionality is not
implemented yet"

Can you r=? 

Comment 35

[chris hofmann]

Comment on attachment 161318 [details] [diff] [review]
alternative with no l10n change

a=chofmann for the branches

Comment 36

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-10-09 00:15 -0700.
Fix checked in to MOZILLA_1_7_BRANCH, 2004-10-09 00:16 -0700.

Comment 37

[Jay Patel [:jay]]

dbaron:  It looks like this is checked in everywhere and Asa said the merge with
the Trunk was complete...so is this safe to mark fixed?

Comment 38

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

No, nothing has been checked in to the trunk.

Comment 39

[Jay Patel [:jay]]

*** Bug 218304 has been marked as a duplicate of this bug. ***

Comment 40

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Fix checked in to trunk, 2004-12-24 14:27 -0800.

Comment 41

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED, because now we don't print preview XUL pages at all anymore.

Build 2005-01-17, Windows XP Seamonkey trunk.

Comment 42

[Simon Montagu :smontagu]

After reading all the comments in this bug, I still don't understand the
justification for checking into trunk a patch designed as wallpaper for the
branch. Can somebody explain?

Comment 43

[Boris Zbarsky [:bzbarsky]]

Note that this caused bug 275996 because the UI doesn't deal with the exception....

Comment 44

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

(In reply to comment #42)
> After reading all the comments in this bug, I still don't understand the
> justification for checking into trunk a patch designed as wallpaper for the
> branch. Can somebody explain?

If somebody (e.g., gisburn) wants to implement XUL printing, it's their
responsibility to make it work before turning it on.  They shouldn't just turn
it on and then complain to other people when it crashes.