1447169 - <textPath> position is (incorrectly?) influenced by "y" on parent <text> elem, if it's the first child of that elem

Status: UNCONFIRMED

(Core :: SVG, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Load attached testcase.
 (The first row has "y" set on the <text> elements. The second row does not.)

EXPECTED RESULTS:
The "PATH" text should all be in the same position in each box.

ACTUAL RESULTS:
In the first and third box (the only cases where there's nothing before the <textPath> element), the "PATH" text is shifted down and to the left (partially out of view).


(I noticed this bug when playing around with a new reftest, in bug 1446650 comment 2.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Chrome 65 and Edge 16 give "EXPECTED RESULTS".

Comment 3

[Daniel Holbert [:dholbert]]

Robert, maybe you'd be interested in taking a look as part of the textPath work that you're doing?

Comment 4

[Robert Longson [:longsonr]]

Not sure this isn't intentional by Cam per https://dxr.mozilla.org/mozilla-central/rev/6ff60a083701d08c52702daf50f28e8f46ae3a1c/layout/svg/SVGTextFrame.cpp#4576

The spec (https://www.w3.org/TR/SVG2/text.html#TextpathLayoutRules) has this to say...

When the inline-base direction is horizontal, then any ‘x’ attributes on ‘text’ or ‘tspan’ elements represent new absolute offsets along the path, thus providing explicit new values for startpoint-on-the-path. Any ‘y’ attributes on ‘text’ or ‘tspan’ elements are ignored. When the inline-base direction is vertical, then any ‘y’ attributes on ‘text’ or ‘tspan’ elements represent new absolute offsets along the path, thus providing explicit new values for startpoint-on-the-path. Any ‘x’ attributes on ‘text’ or ‘tspan’ elements are ignored.

Comment 5

[Jet Villegas (inactive)]

[Triage 2018/03/23 - P3]

Comment 6

[Robert Longson [:longsonr]]

Chrome doesn't support side at all.

Comment 7

[Robert Longson [:longsonr]]

Attachment: testcase 2

Comment 8

[Robert Longson [:longsonr]]

bug 1677187 makes us more like Chrome. Not sure whether the third testcase (after) is still wrong or not though.