736915 - Print Selection prints a blank page when the selection is inside a table in SeaMonkey2.8 & Firefox11 and later

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Rob S]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8
Build ID: 20120312220748

Steps to reproduce:

Selected a paragraph (topic)  in the Seamonkey forum, click file, print, set "selection", 


Actual results:

and got a blank page with headers only 

See also http://forums.mozillazine.org/viewtopic.php?f=40&t=2445071


Expected results:

Should have printed the selected text

This same process worked fine in recent versions

Comment 1

[Philip Chee]

Possible duplicates:
Bug 441189 - printing selection from comments on "derstandard.at" yields blank output
Bug 436178 - Print selection prints blank pages, with absolutely-positioned div that's shifted upwards
Bug 436041 - 'Print Selection Only' produces illegible or blank PDF documents at tages-anzeiger.ch
Bug 431308 - Print Selection gives blank output within 'position: absolute' div
Bug 428109 - 'Print Selection' prints nothing on page with very wide div.

Comment 2

[Alice0775 White]

Regression window(m-c),
Works:
http://hg.mozilla.org/mozilla-central/rev/c7101dec8deb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111220 Firefox/11.0a1 ID:20111220083550
Fails:
http://hg.mozilla.org/mozilla-central/rev/a8506ab2c654
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111220 Firefox/11.0a1 ID:20111220085450
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c7101dec8deb&tochange=a8506ab2c654


Regression window(m-i),
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/feaccb6a4c35
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111219 Firefox/11.0a1 ID:20111219235256
Fails:
http://hg.mozilla.org/integration/mozilla-inbound/rev/0aa9c3a5b7e1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111219 Firefox/11.0a1 ID:20111220011653
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=feaccb6a4c35&tochange=0aa9c3a5b7e1

Suspected: Bug 619273

Comment 3

[Mats Palmgren (inactive)]

Attachment: fix

https://tbpl.mozilla.org/?usebuildbot=1&tree=Try&rev=0596d478b223

Comment 4

[Mats Palmgren (inactive)]

Attachment: wdiff of the same

Comment 5

[Mats Palmgren (inactive)]

Comment on attachment 607441 [details] [diff] [review]
wdiff of the same

This should fix printing normal selection inside tables; it doesn't fix
printing of "table selections", but that didn't work before either.

Comment 6

[RNicoletto]

The problem is also reproducible on Mozilla Italia Forum (http://forum.mozillaitalia.org/) or on Google News Home Page (http://news.google.com/).

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 607441 [details] [diff] [review]
wdiff of the same

So what's the net effect of this?  Walking down into the kids even if IsVisibleInSelection() returns false or something?  Why is that needed for cells?

I'd really like to see a checkin comment explaining what's going on, at least.

Comment 8

[RNicoletto]

Just to report I can replicate this with latest Nightly on Windows XP.
Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120321 Firefox/14.0a1

Comment 9

[Mats Palmgren (inactive)]

Attachment: fix

Appended the following explanation to the commit message:

When rendering just the current Selection (Print - Selection) then don't create display items
for table-related frames unless the frame itself is part of the selection, and always ask
descendant frames to build display lists [in case they are selected].

Comment 10

[Mats Palmgren (inactive)]

> So what's the net effect of this?

Creating display items for the frame(s) inside the table cell that are selected.

>  Walking down into the kids even if
> IsVisibleInSelection() returns false or something?

Yes. And suppressing border/backgrounds etc for table elements that are not part of
the selection.

> Why is that needed for cells?

I don't see why cell frames are special, we need to process its descendants like
other frames.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 607441 [details] [diff] [review]
wdiff of the same

r=me

Comment 12

[Mats Palmgren (inactive)]

Attachment: A few reftests

These tests use the new "reftest-print-selection" class in bug 428037.
https://tbpl.mozilla.org/?usebuildbot=1&tree=Try&rev=7090d18774c8

Comment 13

[Alex Keybl [:akeybl]]

Tracking for Firefox 12 since this was a recent regression. Please nominate for Beta approval as soon as you're comfortable with the testing the patch has received on m-c. Preferably, we'd land this before Beta 4 on 4/3.

Comment 15

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6642b531a08a

Please keep bug open after m-c merge to land tests which depends on bug 428037.

Comment 16

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/6642b531a08a

Comment 17

[Mats Palmgren (inactive)]

I want it open so I don't forget to land the tests once I get review on bug 428037.

Comment 18

[cmarche]

Just tried it on one of the pages I had problems with, not Fixed
page on http://www.dawanda.com
Please keep open, thanks

Comment 19

[Mats Palmgren (inactive)]

[e-mail], the fix hasn't been included in a Nightly build yet.
Please try again in a day or two.  Thanks.

Comment 20

[[e-mail]]

The problem also exists for me. I disabled all add-ons to no avail. It worked in Firefox 10. I'm running Firefox 11.0, Windows 7 SP1.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 608029 [details] [diff] [review]
fix

[Approval Request Comment]
Regression caused by (bug #): 619273
User impact if declined: Printing selections that are inside tables doesn't work.
Testing completed (on m-c, etc.): Passes the attached tests, presumably.
Risk to taking this patch (and alternatives if risky): Probably some risk.  The
   only obvious alternative is backing out bug 619273, which is probably riskier.
String changes made by this patch:  None.

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 608029 [details] [diff] [review]
fix

[Triage Comment]
Approved, please land on beta branch by 2:30pm PDT today for beta4 go-to-build, thank you.

Comment 23

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/d4c63d6b84db
http://hg.mozilla.org/releases/mozilla-beta/rev/6d2430c8bf00