Closed Bug 1006576 Opened 6 years ago Closed 6 years ago
some table borders disappear when printing
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
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
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.
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.
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.
I guess that's true.
Although arguably whether or not "device pixels" are really device pixels is a reasonable thing to make a property of a DrawTarget.
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
Tracking because this is related to the pdf printing issue (which was the drive of 29.0.1)
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.
You need to log in before you can comment on or make changes to this bug.