1006576 - some table borders disappear when printing

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect)

Description

[yannis.delmas]

Attachment: 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.

Comment 1

[[:Aleksej]]

-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

Comment 2

[[:Aleksej]]

-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

Comment 3

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

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.

Comment 4

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

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.

Comment 5

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

Attachment: 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.

Comment 6

[Matt Woodrow (:mattwoodrow)]

(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.

Comment 7

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

I guess that's true.

Comment 8

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

Although arguably whether or not "device pixels" are really device pixels is a reasonable thing to make a property of a DrawTarget.

Comment 9

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/564504fcbca5

Comment 10

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

We'd better fix this in aurora/beta

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/564504fcbca5

Comment 12

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

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

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Tracking because this is related to the pdf printing issue (which was the drive of 29.0.1)

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/70e5f9d723ed
https://hg.mozilla.org/releases/mozilla-beta/rev/a8baa327bc5f

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a8baa327bc5f

Comment 16

[Paul Silaghi, QA [:pauly]]

Reproduced in nightly 2015-05-18, Ubuntu 13.04 x64.
Verified fixed FF 30b8, 32.0a1(2014-05-27), Ubuntu 13.04 x64.

Comment 17

[Paul Silaghi, QA [:pauly]]

Also verified fixed FF 31.0a2 (2014-05-28), Ubuntu 13.04 x64.