1954044 - anseki.github.io - The LeaderLine Javascripts objects don't work anymore

Status: VERIFIED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[railioaie]

Environment:
Operating system: Mac OS X 10.15
Firefox version: Firefox 137.0

Preconditions:
Clean profile

Steps to reproduce:

1. Navigate to : https://anseki.github.io/leader-line/
2. Observe

Expected Behavior:
The page is displayed correctly

Actual Behavior:
The LeaderLine Javascripts objects don't work anymore(see attachments)

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/150099

Comment 1

[railioaie]

Attachment: Screenshot 2025-03-14 at 09.54.07.png

Comment 2

[railioaie]

Attachment: Screenshot 2025-03-14 at 09.53.42.png

Comment 3

[Alice0775 White]

I can reproduce the issue on Nightly138.0a1 Windows11.

The following error is shown in Browser Console.

TypeError: can't access property "results", queryContext is undefined

Uncaught TypeError: SVGPathElement.setPathData: Element of argument 1 does not implement interface SVGPathSegment.
$e https://anseki.github.io/leader-line/js/libs-d4667dd-211118164156.js:3
it https://anseki.github.io/leader-line/js/libs-d4667dd-211118164156.js:3
setOptions https://anseki.github.io/leader-line/js/libs-d4667dd-211118164156.js:3
ot https://anseki.github.io/leader-line/js/libs-d4667dd-211118164156.js:3
<anonymous> https://anseki.github.io/leader-line/:45
EventListener.handleEvent* https://anseki.github.io/leader-line/:42
libs-d4667dd-211118164156.js:3:45362
$e https://anseki.github.io/leader-line/js/libs-d4667dd-211118164156.js:3
it https://anseki.github.io/leader-line/js/libs-d4667dd-211118164156.js:3
setOptions https://anseki.github.io/leader-line/js/libs-d4667dd-211118164156.js:3
ot https://anseki.github.io/leader-line/js/libs-d4667dd-211118164156.js:3
<anonymous> https://anseki.github.io/leader-line/:45
(Async: EventListener.handleEvent)
<anonymous> https://anseki.github.io/leader-line/:42

*** snip ***

Comment 4

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=25a5d0ca6443dbf09f26e10da77bba528d798359&tochange=99281d5df65b0081d3066ad9a09e3d3d5b5b7c1c

Comment 5

[Robert Longson [:longsonr]]

It's creating functions getPathData & setPathData on the path element. Unfortunately they already have meaning in the new SVG path specification.

Comment 6

[Robert Longson [:longsonr]]

I suspect the javascript tries to implement the SVG Path data interface but the interface it implements is not quite the same as the interface that the specification defines. It can't or doesn't override the native interface but then when it tries to use the SVG Path interface it runs into trouble because the way the SVG Path interface actually works isn't the same as the implementer of the site thought it should work.

Comment 7

[Dennis Schubert [:denschub][OOO, back Aug 11]]

I wanted to suggest outreach, but their repo is archived. Unless this is being used on a real site instead of just a demo page, there isn't much we can do.

Comment 8

[Dennis Schubert [:denschub][OOO, back Aug 11]]

James, can you maybe try to find real-world sites that use this library?

Comment 9

[Holger Benl [:hbenl]]

This can be reproduced in the console: let temp0 be an SVG <path> element, then evaluate temp0.setPathData([{"type":"M","values":[0,0]}]) in the console. In Firefox this throws an exception but it works in Chrome (and sets temp0's d attribute to M 0 0).

Comment 10

[James Graham [:jgraham]]

The fact that this is a regression from adding the feature is known, the question is whether there's any compat impact other than breaking the demo page of an unmaintained library.

From the HTTPArchive 10k sample I found https://chartink.com/build/assets/vue-clipboard-c01e20e0.js that's using this library. I didn't immediately find any breakage on chartlink.com

https://www.npmjs.com/browse/depended/leader-line also shows 34 packages that depend on leader-line, some of which seem to have relatively recent updates. However the vast majority have <10 weekly downloads. https://www.npmjs.com/package/deseruntnam has the most weekly downloads, and https://github.com/EstevanKlein/deseruntnam/blob/440d6c65cb872469704da3b332a3b2c0c4e71821/products/devex/src/components/DetailsPages/TxnDetailsPage/TxBlock.tsx#L53 does seem to use this library, but I have no idea what that repo is or where it's deployed.

Just searching for \.(?:get|set)PathData returns a lot of matches (~1000): https://docs.google.com/spreadsheets/d/1wnfzNUt5Alc6sldUFvyv_0zMcwv4P_owqNwXESkscro/edit?gid=82029868 but the ones I sampled seemed to be use defined functions.

Maybe this is a case where we should put a use counter on the API itself, so we at least have some idea how many users the problem might be affecting, even if we can't work out URLs?

Comment 11

[Dennis Schubert [:denschub][OOO, back Aug 11]]

Let's triage this as if it would be a real site, where it would probably be "content missing". It technically is a regression, so we'll leave the flag for now, but it's hard to track it as such because this is just a demo page of an archived library. Things would be different if we had good evidence of this breaking real sites, but we don't have that.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1934525

Comment 13

[Jarek Foksa]

SVGPathElement.prototype.setPathData() API as introduced in Firefox 137 seems to require all segments to be instances of SVGPathSegment rather than plain JS objects, so it will break any app that relies on https://www.npmjs.com/package/path-data-polyfill. I already received several complains from users of https://boxy-svg.com/app.

Comment 14

[Robert Longson [:longsonr]]

Attachment: Bug 1954044 - Implement https://github.com/w3c/editing/issues/483 so that setPathData can accept a plain javascript object that matches the structure of SVGPathSegment r=emilio

Comment 15

[Robert Longson [:longsonr]]

with the patch, temp0.setPathData([{"type":"M","values":[0,0]}]) will set the path data i.e. you'd just need a javascript object with the same properties, i.e. not necessarily an SVGPathSegment object.

Comment 16

[Robert Longson [:longsonr]]

https://treeherder.mozilla.org/jobs?repo=try&revision=f73536e240c718b52c23e90b82e2101397d3fbba

Comment 17

[Robert Longson [:longsonr]]

https://treeherder.mozilla.org/jobs?repo=try&revision=bffc2a218af56b16793ac3ec1aee713752044a70

Comment 18

[Robert Longson [:longsonr]]

https://treeherder.mozilla.org/jobs?repo=try&revision=238eab951df1b64b0772d8a41312a6058507a50e

Comment 19

[Jarek Foksa]

Thanks for patch. I also updated the polyfill so that it should work on Firefox with and without the patch.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/94b9436ff8ff
Implement https://github.com/w3c/editing/issues/483 so that setPathData can accept a plain javascript object that matches the structure of SVGPathSegment r=emilio

Comment 22

[Cristian Tuns]

Backed out for causing hazard failures

• Backout link
• Push with failures
• Failure Log
• Failure line: gmake[4]: *** Deleting file 'DOMtoATK.o'
  /builds/worker/checkouts/gecko/obj-analyzed-browser/dist/include/mozilla/Assertions.h:495:60: error: ignoring attributes on template argument 'mozilla::StringBuffer*' [-Werror=ignored-attributes]

Comment 23

[Josh Diehl]

Reading previous comments about impact radius of this issue... be aware that https://github.com/AhmedAyachi/LinkerLine is the ongoing active fork of LeaderLine, and there are active users of it. https://github.com/AhmedAyachi/LinkerLine/issues/12 .

Comment 24

[Cristian Tuns]

Regarding the backout, it looks like it that fail was caused by another bug, I will reland it.
Sorry for that.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fe3e6fc7196a
Implement https://github.com/w3c/editing/issues/483 so that setPathData can accept a plain javascript object that matches the structure of SVGPathSegment r=emilio

Comment 26

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/fe3e6fc7196a

Comment 27

[Robert Longson [:longsonr]]

The patch should be in the next nightly. Please let us know if everything is OK now. If not, do raise other bugs and CC me.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:longsonr, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox138 to wontfix.

For more information, please visit BugBot documentation.

Comment 29

[Raul Bucata]

Verified as FIXED using the RC Build

Tested with:

Browser / Version: Firefox 138.0-candidate build 1
Operating System: Windows 10 PRO x64
Operating System: Mac OS X 10.15

Comment 30

[Robert Longson [:longsonr]]

The fix isn't in Firefox 138 though, it's only in 139 at the moment.

Comment 31

[Raul Bucata]

We are conducting a series of tests before 138 is released on the RC Build. If it does not reproduce there, we classify the issue as verified in 138, since it is in the list of issues that need to be verified.

Comment 32

[Jarek Foksa]

I performed some tests using Firefox Nightly version 139.0a1 (2025-04-22, Linux, aarch64) and I confirm that the patch fixes compatibility issues with apps that rely on older version of path-data-polyfill.

The only potential problems might arise from the fact that the polyfilled setPathData() method was (incorrectly?) very permissive about "Z" segment syntax while Firefox allows only {type: "Z", values: []}, but not {type: "Z"} (throws an error) or {type: "Z", values: [0, 0]} (ignores the segment without throwing an error). I'm not sure how large impact this might have.

Comment 33

[Robert Longson [:longsonr]]

Comment on attachment 9478731 [details]
Bug 1954044 - Implement https://github.com/w3c/editing/issues/483 so that setPathData can accept a plain javascript object that matches the structure of SVGPathSegment r=emilio

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: some sites that depend on setPathData/getPathData polyfill won't work correctly now that Firefox implements these methods natively.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Makes setPathData more permissive in what it accepts but does not otherwise change how it works.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 34

[Dianna Smith [:diannaS]]

Comment on attachment 9478731 [details]
Bug 1954044 - Implement https://github.com/w3c/editing/issues/483 so that setPathData can accept a plain javascript object that matches the structure of SVGPathSegment r=emilio

There are no more betas in 138. I will leave this request open in case of an RC re-spin or for consideration for the 138 dot release.

Comment 35

[Dianna Smith [:diannaS]]

:longsonr this will need a release patch

Comment 36

[Robert Longson [:longsonr]]

Are there some instructions somewhere as to how to do that?

Comment 37

[Daniel Holbert [:dholbert]]

Same steps that generated comment 33, I think (via Lando / request uplift from the original patch, but just selecting release as the target branch).

Documentation/instructions are at https://wiki.mozilla.org/Release_Management/Uplift_rules

Comment 38

[Robert Longson [:longsonr]]

Attachment: Bug 1954044 - Implement https://github.com/w3c/editing/issues/483 so that setPathData can accept a plain javascript object that matches the structure of SVGPathSegment

Original Revision: https://phabricator.services.mozilla.com/D245342

Comment 39

[Robert Longson [:longsonr]]

Comment on attachment 9485291 [details]
Bug 1954044 - Implement https://github.com/w3c/editing/issues/483 so that setPathData can accept a plain javascript object that matches the structure of SVGPathSegment

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: The interface for setPathData is not compatible with how it's used by a widely used polyfill. The polyfill accepts a plain javascript object with the correct fields and this patch mirrors that.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Makes an existing interface more flexible.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 40

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/2bff31cf3089

Comment 41

[Bogdan Maris, Desktop Test Engineering]

Verified that this is fixed on both 138.0.3 and 139.0b7 using Windows 11 and Mac OS X 10.15.