701 bytes, image/svg+xml
13.27 KB, image/png
1.64 KB, patch
|Details | Diff | Splinter Review|
3.79 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150116030203 Steps to reproduce: Open the attached svg file in Firefox. OSX 10.10.1 FF 38.0a1 (nightly 2015-01-16) Actual results: The red rectangle on the left side renders the border incorrectly. The dash starts at the top right corner and points anti-clockwise. Expected results: The rectangle on the left side should render like the one on the right side, but just without rounded corners. The dash should start at the top left corner and point clockwise. (there was actually a similar bug for ellipses, see bug 944704)
This is a regression somewhere between Firefox 35 (working) and trunk(not)
Component: Untriaged → SVG
Product: Firefox → Core
Version: Firefox 38 → Trunk
regression range (from mozregression) https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2f7a7cce07b6&tochange=3ce0af074cf0
Seems this is down to a Core Graphics bug where CGContextStrokeRect starts at a different position and moves in a different direction depending on the OS X version. All non-OS X backends plus at least OS X 10.6 stroke DrawTarget::StrokeRect() starting at the top-left corner and moving clockwise. OS X 10.9 and 10.10 start at the top-right corner and stroke anti-clockwise. I'm not sure about other OS X versions yet. The behavior in later OS X versions contradicts the behavior described in Apple's documentation: https://developer.apple.com/library/ios/documentation/GraphicsImaging/Reference/CGContext/index.html#//apple_ref/c/func/CGContextStrokeRect We're hitting this Moz2D backend difference because in nsSVGPathGeometryFrame::Render we now call drawTarget->StrokeRect() instead of drawTarget->Stroke() (which on OS X calls DrawTargetCG::StrokeRect, which calls CGContextStrokeRect).
Assignee: nobody → jwatt
Attachment #8551513 - Flags: review?(bas) → review+
Attachment #8551516 - Attachment is patch: true
Comment on attachment 8551516 [details] [diff] [review] part 2 - reftest I suspect this will pass with/without this fix as we don't have OSX 10.9/10.10 test infrastructure. I discovered this when I tried to write a reftest which passed everywhere (see the obsolete patch).
Attachment #8551516 - Flags: review?(longsonr) → review+
[Tracking Requested - why for this release]: SVG regression with simple fix. https://hg.mozilla.org/integration/mozilla-inbound/rev/a6c6ba9c0fca https://hg.mozilla.org/integration/mozilla-inbound/rev/fa573923e21d
Resetting 38 status to affected until this lands on m-c.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Comment on attachment 8551513 [details] [diff] [review] part 1 - Moz2D fix Approval Request Comment [Feature/regressing bug #]: bug 1074161 [User impact if declined]: some broken SVG [Describe test coverage new/current, TreeHerder]: merged from m-i to m-c [Risks and why]: very low - doing exactly what Apples docs say should be done [String/UUID change made/needed]: none
Reproduced on Nightly 2015-01-12 under Mac OS X 10.9.5 with the attached svg file. Verified as fixed on Fx 36 beta 4 (Build ID: 20150126151838), DevEd 37.0a2 (Build ID: 20150126004016) and Nightly 38.0a1 (Build ID: 20150126030202) e10s enabled/disabled under Mac OS X 10.9.5 and 10.10.
You need to log in before you can comment on or make changes to this bug.