794579 - Hang when trying to print / print-preview from Google Maps

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

Attempting to print from Google Maps hangs browser 'not-responding' , have to kill the browser process after the hang.

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f731fa718465&tochange=488beb32bca5
Good cset: f731fa718465 
bad cset:  488beb32bca5 

bad cset is a m-i->m-c merge containing 71 patches

regression help needed to triage m-i

Comment 1

[Daniel Holbert [:dholbert]]

I can reproduce on Linux x86_64.

m-i regression range:
Good: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-09-19-mozilla-inbound-debug/firefox-18.0a1.en-US.debug-linux-x86_64.txt
Bad: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-09-20-mozilla-inbound-debug/firefox-18.0a1.en-US.debug-linux-x86_64.txt

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6eed25d2f2c9&tochange=b3e66a4b7c0b
Suspected cause: bug 468568 (the only obviously-print-related thing there)

(Clarifying bug summary -- not sure what the "or Selected Text" part was about -- I can select text on google maps just fine.  I can confirm that print-preview hangs as well, though.)

I can reproduce this at both basic "http://maps.google.com" as well as at the simpler "print view" that Google Maps pops up in a new window when you hit the print button.  (basically just adding "pw=2" to the end of the URL)

Comment 2

[Daniel Holbert [:dholbert]]

NOTE: in the 2012-09-19 mozilla-inbound-debug build (just before this regressed), I get these assertions when I print-preview http://maps.google.com?pw=1 :
###!!! ASSERTION: Unexpected containers: 'SameCOMIdentity(debugDocContainer, debugDocShell)', file ../../../layout/base/nsDocumentViewer.cpp, line 2151
###!!! ASSERTION: Unexpected containers: 'SameCOMIdentity(debugDocContainer, debugDocShell)', file ../../../layout/base/nsDocumentViewer.cpp, line 2151
... (but other than that, things seem to work fine)

And in the 2012-09-20 mozilla-inbound-debug build (just after this regressed), I get no assertions, but I do get a hang.

The prior assertion-failures indicate that were already violating some invariants here -- so it's possible that bug 468568 didn't *directly* cause this, but rather changed the behavior that those violated-invariants would produce.  (or not; just throwing out a possibility)

Comment 3

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

We removed that assertion because Olli said it was bogus.

Comment 4

[Daniel Holbert [:dholbert]]

Ah, ok -- disregard comment 2, then.

Comment 5

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

We're hanging because an nsIView has itself as its own next sibling!

Comment 6

[Jim Jeffery not reading bug-mail 1/2/11]

@dholbert

By 'selected text' I mean..  take any text on any page, highlight it, then from the Firefox/Nightly Button Choose 'Print' - Print 'Selection' and the browser will hang.

Comment 7

[Daniel Holbert [:dholbert]]

I can't reproduce the print-selection hang.  Selecting text & doing print-selection on e.g. https://ftp.mozilla.org/pub/mozilla.org/README works just fine for me, in current nightly.

Could you file a separate bug on that, with a specific URL where you can reproduce it?  (the simpler the better -- e.g. use https://ftp.mozilla.org/pub/mozilla.org/README , if that reproduces the bug for you)

Let's make this bug specificially about print/print-preview hanging on google maps.

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> I can't reproduce the print-selection hang.  Selecting text & doing
> print-selection on e.g. https://ftp.mozilla.org/pub/mozilla.org/README works
> just fine for me, in current nightly.
> 
> Could you file a separate bug on that, with a specific URL where you can
> reproduce it?  (the simpler the better -- e.g. use
> https://ftp.mozilla.org/pub/mozilla.org/README , if that reproduces the bug
> for you)
> 
> Let's make this bug specificially about print/print-preview hanging on
> google maps.

Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=794684 

Feel free to dup if it turns out to be related to same root-cause as this bug.

Comment 9

[Tom Kloos]

It isn't just Google Maps that fails.  Attempting to print "complex" pages does it.
Print or print-preview of these locks up the browser:
http://online.wsj.com/
http://acid3.acidtests.org/

It also doesn't appear to be related to the default printer since printing to something like "Fineprint" or PDFCreator also fails.

Seen on these versions:
firefox-18.0a1.en-US.win32_20120930030610.zip
seamonkey-2.15a1.en-US.win32_20120930003004.zip
seamonkey-2.15a1.en-US.win32_20120930051951.zip

Comment 10

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

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) (offline September 29-30 NZ time, i.e. 28-29 US time) from comment #5)
> We're hanging because an nsIView has itself as its own next sibling!

That's because nsViewManager::SetRootView adds aView as the first child of its parent view. That's strange, but OK. In this case aView is already the first child of its parent view.

Comment 11

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

Attachment: fix

Comment 12

[Daniel Holbert [:dholbert]]

> Jim Jeffery not reading bug-mail 1/2/11 2012-10-02 04:30:25 PDT
> Keywords: checkin-needed

Jim: Did roc ask you to add that "checkin-needed" keyword?

If not, please don't add that keyword to bugs -- that's keyword is generally reserved for patch-authors to use, when they explicitly want someone else to check in their patch for them.

(That might be the case here, but roc is the one to make that call -- he might e.g. have a final tweak he wants to make to the patch or commit message before landing it, and he'd lose that opportunity if someone came along and checked this in for him.)

 --> removing "checkin-needed

Comment 13

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Daniel Holbert [:dholbert] from comment #12)
> > Jim Jeffery not reading bug-mail 1/2/11 2012-10-02 04:30:25 PDT
> > Keywords: checkin-needed
> 
> Jim: Did roc ask you to add that "checkin-needed" keyword?
> 
> If not, please don't add that keyword to bugs -- that's keyword is generally
> reserved for patch-authors to use, when they explicitly want someone else to
> check in their patch for them.
> 
> (That might be the case here, but roc is the one to make that call -- he
> might e.g. have a final tweak he wants to make to the patch or commit
> message before landing it, and he'd lose that opportunity if someone came
> along and checked this in for him.)
> 
>  --> removing "checkin-needed

Yes, I asked roc this morning and he said mark it checkin-needed 
I asked on IRC and he responded on IRC in the 'gfx' channel.

Comment 14

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9b9bf8702da4

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #13)
> Yes, I asked roc this morning and he said mark it checkin-needed 
> I asked on IRC and he responded on IRC in the 'gfx' channel.

Ah, excellent! My mistake, sorry for the confusion.

Comment 16

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Daniel Holbert [:dholbert] from comment #15)
> (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #13)
> > Yes, I asked roc this morning and he said mark it checkin-needed 
> > I asked on IRC and he responded on IRC in the 'gfx' channel.
> 
> Ah, excellent! My mistake, sorry for the confusion.

No problem.  I take part of the misunderstanding from not posting clearing that I going to set check-in needed per conversation with roc on IRC.  Won't make that mistake again 
:)

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9b9bf8702da4

Should this have a crashtest?