Closed Bug 1288194 Opened 3 years ago Closed 3 years ago

[e10s] Some SVG images do not print

Categories

(Core :: Security: Process Sandboxing, defect)

x86
Windows 10
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla51
Tracking Status
e10s + ---
firefox49 --- unaffected
firefox50 + verified
firefox51 --- verified

People

(Reporter: alice0775, Assigned: bobowen)

References

Details

(Keywords: regression, Whiteboard: sbwc1)

Attachments

(2 files)

[Tracking Requested - why for this release]:

+++ This bug was initially created as a clone of Bug #1287512 +++

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

1. Open attachment 8772049 [details] of Bug 1287512
2. Print with "Microsoft XPS Document Writer"
   and Save as XPS document like test.xps

Actual results:
With HWA on
SVG image prints anything
Pure Image print "gray rectangle"

With HWA off
SVG image prints properly("light-blue filled circle").
Pure Image print "light-blue filled circle" and "gray rectangle" background

Expected results:
Both types should print "light-blue filled circle"
This seems affected to nightly channel only.
Because, it was fixed when it merged to [2]Aurora49.0a2 from [1]Nightly49.0a1.

[1]
https://hg.mozilla.org/mozilla-central/rev/0a3b6e2df6567d845f31c000c68dd67816c6153d
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 ID:20160606025732

[2]
https://hg.mozilla.org/releases/mozilla-aurora/rev/cea65ca3d0bdd8325dc556f6bfde6277fc83fe6e
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 ID:20160606144834
OS: Unspecified → Windows 10
Hardware: Unspecified → x86
Version: 50 Branch → Trunk
So, seems process sandboxing problem.
Component: Printing: Output → Security: Process Sandboxing
Blocks: 1105816
Whiteboard: sb?
tracking-e10s: --- → ?
It works as expected if set the following preferences.
user_pref("print.print_via_parent", false);
user_pref("security.sandbox.content.level", 0);
Summary: Some SVG images do not print → [e10s] Some SVG images do not print
Flags: needinfo?(bobowen.code)
Tracking 50+ for this printing regression.
Are we letting this aspect of sandboxing ride in 50?
Flags: needinfo?(jmathies)
(In reply to Andrew Overholt [:overholt] from comment #5)
> Are we letting this aspect of sandboxing ride in 50?

Yes, the low integrity sandbox settings will (hopefully :-) ) be riding in 50.
This is actually not a problem with the sandbox directly, but with the print via parent, which we need to be able to turn on sandboxing.

Something must be going wrong with the recording or playback of the DrawTarget calls.
I'll look into it.
Assignee: nobody → bobowen.code
Status: NEW → ASSIGNED
Flags: needinfo?(jmathies)
Flags: needinfo?(bobowen.code)
Whiteboard: sb? → sbwc1
The missing circles is down to this:
https://hg.mozilla.org/mozilla-central/file/5df2781a3b0c/gfx/2d/PathRecording.h#l66

Where we are just throwing away calls to PathBuilderRecording::Arc

Looks like that is pretty easy to fix.

The grey rectangle appears to be something else that I haven't tracked down yet.
... and the grey rectangle is down to me botching the recording of DrawTargetRecording::PushLayer, possibly an IntelliSense blunder.
Comment on attachment 8778966 [details]
Bug 1288194 Part 1: Implement PathBuilderRecording::Arc correctly.

https://reviewboard.mozilla.org/r/70040/#review67656
Attachment #8778966 - Flags: review?(bas) → review+
Comment on attachment 8778967 [details]
Bug 1288194 Part 2: Fix incorrectly recorded argument in DrawTargetRecording::PushLayer.

https://reviewboard.mozilla.org/r/70042/#review67658
Attachment #8778967 - Flags: review?(bas) → review+
Pushed by bobowencode@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/a0c1998f35d2
Part 1: Implement PathBuilderRecording::Arc correctly. r=bas
https://hg.mozilla.org/integration/autoland/rev/a31335a3173a
Part 2: Fix incorrectly recorded argument in DrawTargetRecording::PushLayer. r=bas
https://hg.mozilla.org/mozilla-central/rev/a0c1998f35d2
https://hg.mozilla.org/mozilla-central/rev/a31335a3173a
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Bob, could you fill the uplift request to 50 to fix this new regression? Thanks
Flags: needinfo?(bobowen.code)
Comment on attachment 8778966 [details]
Bug 1288194 Part 1: Implement PathBuilderRecording::Arc correctly.

(In reply to Sylvestre Ledru [:sylvestre] from comment #15)
> Bob, could you fill the uplift request to 50 to fix this new regression?
> Thanks

Thanks for reminding me.

Approval Request Comment
[Feature/regressing bug #]:
Introduced by the use of Moz2D recording for printing via the parent.

[User impact if declined]:
Certain pages won't render properly when printing.

[Describe test coverage new/current, TreeHerder]:
Manual testing.
Good candidate for QE verification.

[Risks and why]:
Low - both patches are simple and localised.

[String/UUID change made/needed]:
None.
Flags: needinfo?(bobowen.code)
Attachment #8778966 - Flags: approval-mozilla-aurora?
Flags: qe-verify+
Hi Alice0775 White, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(alice0775)
Comment on attachment 8778966 [details]
Bug 1288194 Part 1: Implement PathBuilderRecording::Arc correctly.

Fix for a recent regression, stabilized on nightly for ~2 weeks, Aurora50+
Attachment #8778966 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Ritu Kothari (:ritu) from comment #17)
> Hi Alice0775 White, could you please verify this issue is fixed as expected
> on a latest Nightly build? Thanks!

The problem is fixed on Nightly51.0a1 23-Aug-2016 build with/without HWA. 
Thanks!
Flags: needinfo?(alice0775)
(In reply to Alice0775 White from comment #19)
> (In reply to Ritu Kothari (:ritu) from comment #17)
> > Hi Alice0775 White, could you please verify this issue is fixed as expected
> > on a latest Nightly build? Thanks!
> 
> The problem is fixed on Nightly51.0a1 23-Aug-2016 build with/without HWA. 
> Thanks!

Fantastic! Thank you for the verification.
Status: RESOLVED → VERIFIED
I reproduced the issue using an old Nightly 50.0a1 (2016-07-14) build, on Windows 10 Pro x64, with both enabled/disabled HWA.

The fix is now verified on Firefox Beta 50.0b4 on same platform, with both enabled/disabled HWA.
No longer depends on: 1287512
Duplicate of this bug: 1287512
You need to log in before you can comment on or make changes to this bug.