SVG stroke-dasharray is reversed on rect elements

VERIFIED FIXED in Firefox 36



5 years ago
5 years ago


(Reporter: kari_pihkala, Assigned: jwatt)



Dependency tree / graph
Bug Flags:
in-testsuite +
qe-verify +

Firefox Tracking Flags

(firefox35 unaffected, firefox36+ verified, firefox37+ verified, firefox38 verified)



(4 attachments, 1 obsolete attachment)

Posted image rect-dasharray.svg
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)
Ever confirmed: true
Component: Untriaged → SVG
Product: Firefox → Core
Version: Firefox 38 → Trunk
Posted patch reftest (obsolete) — Splinter Review
Attachment #8550930 - Attachment is obsolete: true
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:

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)
Attachment #8551513 - Flags: review?(bas) → review+
Attachment #8551516 - Flags: review?(longsonr)
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+
Resetting 38 status to affected until this lands on m-c.
Closed: 5 years ago
Flags: in-testsuite+
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
Attachment #8551513 - Flags: approval-mozilla-beta?
Attachment #8551513 - Flags: approval-mozilla-aurora?
Attachment #8551513 - Flags: approval-mozilla-beta?
Attachment #8551513 - Flags: approval-mozilla-beta+
Attachment #8551513 - Flags: approval-mozilla-aurora?
Attachment #8551513 - Flags: approval-mozilla-aurora+
Whiteboard: qa should test on mac 10.9 and 10.10
Flags: qe-verify+
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.
Per Comment 14, clear "qawanted" in Keywords.
Keywords: qawanted
Whiteboard: qa should test on mac 10.9 and 10.10
You need to log in before you can comment on or make changes to this bug.