Closed Bug 1006576 Opened 6 years ago Closed 6 years ago

some table borders disappear when printing

Categories

(Core :: Graphics: Layers, defect)

29 Branch
x86
Linux
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla32
Tracking Status
firefox30 + verified
firefox31 + verified
firefox32 --- verified
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: yannis.delmas, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached file jsfiddle example
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140428194004

Steps to reproduce:

HTML : A table with rowspan and colspan.
CSS : Cell border and table border-collapse.
Action : tried to print.
Example (to test) : http://fiddle.jshell.net/ydelmas/yu8mW/7/show/light/
Example (to play with) : http://jsfiddle.net/ydelmas/yu8mW/7/


Actual results:

In this situation (and similar ones) :
- normal screen display : is OK
- media emulate print (with devbar) : is OK
- print preview : is OK
- printed (PDF or printer) : some borders lacks


Expected results:

Printed version should be conform to print preview, borders should all be present.
-g = good, -b = bad
-g 2013-11-23-03-02-08-mozilla-central-firefox-28.0a1.en-US.linux-x86_64
-g 2014-01-30-03-02-02-mozilla-central-firefox-29.0a1.en-US.linux-x86_64
-g 2014-02-03-03-02-03-mozilla-central-firefox-29.0a1.en-US.linux-x86_64
-g 2014-02-16-03-02-03-mozilla-central-firefox-30.0a1.en-US.linux-x86_64
-g 2014-03-31-03-02-01-mozilla-central-firefox-31.0a1.en-US.linux-x86_64
-g 2014-04-07-03-02-03-mozilla-central-firefox-31.0a1.en-US.linux-x86_64 5405d6f4e3c6
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5405d6f4e3c6&tochange=8883360b1edb
-b 2014-04-08-03-02-05-mozilla-central-firefox-31.0a1.ru.linux-x86_64 8883360b1edb
-b 2014-05-12-03-02-02-mozilla-central-firefox-32.0a1.ru.linux-x86_64.

-g firefox-29.0b1.en-US.linux64
-g firefox-29.0b4.ru.linux64
-g firefox-29.0b7.ru.linux64
-b firefox-29.0.ru.linux64
Status: UNCONFIRMED → NEW
QA Whiteboard: [bugday-20140512]
Component: Untriaged → Layout: Tables
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
-g firefox-29.0b8.en-US.linux64 3a4f085a6398
-b firefox-29.0b9.en-US.linux64 da279b9f523a
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=3a4f085a6398&tochange=da279b9f523a

Bug 991767 - Use Moz2D for printing surfaces. r=roc 
author	Matt Woodrow
	Mon Apr 07 16:07:12 2014 +1200 (at Mon Apr 07 16:07:12 2014 +1200)
changeset 177228	7248b992c6b2
Blocks: 991767
Flags: needinfo?(matt.woodrow)
Component: Layout: Tables → Graphics: Layers
Flags: needinfo?(roc)
I think this is happening due to pixel snapping, though I'm not sure why it regressed with Moz2D. We shouldn't be doing any pixel snapping when drawing to PDF, but gfxContext::GetFlags doesn't have FLAG_DISABLE_SNAPPING set on it.
Flags: needinfo?(roc)
Aha, it's because we're creating the gfxContext in mozilla::layers::BasicThebesLayer::Validate with a DrawTarget, and gfxContext::gfxContext(DrawTarget *aTarget) doesn't do the mFlags = surface->GetDefaultContextFlags() that gfxContext::gfxContext(gfxASurface *surface) does.
Attached patch fixSplinter Review
This works for now and should fix all platforms.

I wonder how to handle this in a future world where we only have Moz2D. I think we probably need to expose a method DrawTarget::ShouldSnapToDevicePixels which tells the caller whether to use snapping or not.
Assignee: nobody → roc
Attachment #8427649 - Flags: review?(matt.woodrow)
Attachment #8427649 - Flags: review?(matt.woodrow) → review+
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5)
> Created attachment 8427649 [details] [diff] [review]
> fix
> 
> This works for now and should fix all platforms.
> 
> I wonder how to handle this in a future world where we only have Moz2D. I
> think we probably need to expose a method
> DrawTarget::ShouldSnapToDevicePixels which tells the caller whether to use
> snapping or not.

It's basically just UserData, right? Not sure if we need proper Moz2D API.
Flags: needinfo?(matt.woodrow)
Although arguably whether or not "device pixels" are really device pixels is a reasonable thing to make a property of a DrawTarget.
We'd better fix this in aurora/beta
https://hg.mozilla.org/mozilla-central/rev/564504fcbca5
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Comment on attachment 8427649 [details] [diff] [review]
fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 991767
User impact if declined: missing lines and uneven spacing in printouts
Testing completed (on m-c, etc.): none
Risk to taking this patch (and alternatives if risky): very low risk indeed. Just restores behavior that was there before 991767, with a very simple patch.
String or IDL/UUID changes made by this patch: none
Attachment #8427649 - Flags: approval-mozilla-beta?
Attachment #8427649 - Flags: approval-mozilla-aurora?
Tracking because this is related to the pdf printing issue (which was the drive of 29.0.1)
Attachment #8427649 - Flags: approval-mozilla-beta?
Attachment #8427649 - Flags: approval-mozilla-beta+
Attachment #8427649 - Flags: approval-mozilla-aurora?
Attachment #8427649 - Flags: approval-mozilla-aurora+
Reproduced in nightly 2015-05-18, Ubuntu 13.04 x64.
Verified fixed FF 30b8, 32.0a1(2014-05-27), Ubuntu 13.04 x64.
Also verified fixed FF 31.0a2 (2014-05-28), Ubuntu 13.04 x64.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.