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

RESOLVED FIXED in Firefox 12

Status

()

Core
Printing: Output
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Rob S, Assigned: mats)

Tracking

(Depends on: 1 bug, {regression, relnote})

11 Branch
mozilla14
regression, relnote
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox12+ fixed, firefox13+ fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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

5 years ago
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.
Status: UNCONFIRMED → NEW
Component: General → Printing: Output
Ever confirmed: true
Product: SeaMonkey → Core
QA Contact: general → printing
Version: SeaMonkey 2.8 Branch → 11 Branch

Comment 2

5 years ago
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
Blocks: 619273
Keywords: regression

Updated

5 years ago
Summary: Print Selection fails in 2.8 → Print Selection fails in SeaMonkey2.8 & Firefox11 and later
(Assignee)

Updated

5 years ago
Assignee: nobody → matspal
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: Print Selection fails in SeaMonkey2.8 & Firefox11 and later → Print Selection prints a blank page when the selection is inside a table in SeaMonkey2.8 & Firefox11 and later
(Assignee)

Comment 3

5 years ago
Created attachment 607438 [details] [diff] [review]
fix

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

Comment 4

5 years ago
Created attachment 607441 [details] [diff] [review]
wdiff of the same
(Assignee)

Comment 5

5 years ago
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.
Attachment #607441 - Flags: review?(bzbarsky)

Comment 6

5 years ago
The problem is also reproducible on Mozilla Italia Forum (http://forum.mozillaitalia.org/) or on Google News Home Page (http://news.google.com/).
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

5 years ago
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
(Assignee)

Comment 9

5 years ago
Created attachment 608029 [details] [diff] [review]
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].
Attachment #607438 - Attachment is obsolete: true
(Assignee)

Comment 10

5 years ago
> 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 on attachment 607441 [details] [diff] [review]
wdiff of the same

r=me
Attachment #607441 - Flags: review?(bzbarsky) → review+

Updated

5 years ago
tracking-firefox12: --- → ?
(Assignee)

Comment 12

5 years ago
Created attachment 609069 [details] [diff] [review]
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
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.
tracking-firefox12: ? → +
tracking-firefox13: --- → +
Duplicate of this bug: 739539

Updated

5 years ago
Keywords: relnote
(Assignee)

Comment 15

5 years ago
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.
Depends on: 428037
Target Milestone: --- → mozilla14
https://hg.mozilla.org/mozilla-central/rev/6642b531a08a
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

5 years ago
I want it open so I don't forget to land the tests once I get review on bug 428037.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 18

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

Comment 19

5 years ago
cmarche@talktalk.net, the fix hasn't been included in a Nightly build yet.
Please try again in a day or two.  Thanks.

Comment 20

5 years ago
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.
Flags: in-testsuite?
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.
Attachment #608029 - Flags: approval-mozilla-beta?
Attachment #608029 - Flags: approval-mozilla-aurora?
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.
Attachment #608029 - Flags: approval-mozilla-beta?
Attachment #608029 - Flags: approval-mozilla-beta+
Attachment #608029 - Flags: approval-mozilla-aurora?
Attachment #608029 - Flags: approval-mozilla-aurora+
http://hg.mozilla.org/releases/mozilla-aurora/rev/d4c63d6b84db
http://hg.mozilla.org/releases/mozilla-beta/rev/6d2430c8bf00
status-firefox12: --- → fixed
status-firefox13: --- → fixed
(Assignee)

Updated

5 years ago
Duplicate of this bug: 747439
(Assignee)

Updated

5 years ago
Duplicate of this bug: 738373
(Assignee)

Updated

5 years ago
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.