nbedos/termtosvg

Firefox: slider in window_frame_js template misplaced and moving to the wrong direction, when SVG is in an HTML file

mestaritonttu opened this issue · 1 comments

This is an issue seen with Firefox 74, on Windows and Linux. This is not an issue with Chrome (tested on Windows).

I rendered a short animation with --template=window_frame_js.
I put it inside an object element, as seen in the minimal HTML file below.
The slider works just fine, if I open the SVG file directly in Firefox.
However, if I open the HTML file, the slider circle is located at the left side of the play button and moves slowly leftward.

Weirded out by this, I tested the animation found on the front page of termtosvg. If I save the page and open the file locally, the slider moves just fine at first, but if I reload the page while the animation is playing it sometimes misbehaves. It never seems to misbehave, if I reload the page while the animation is paused.
Strangely, I was unable to make it misbehave by testing the version online at nbedos.github.io.

Could it be related to the WebKitCSSMatrix used in the getTranslateX function?

I searched Mozilla's BZ and found a report filed 3 years ago Update Geometry interfaces and impl (DOMMatrix, DOMMatrixReadOnly, WebkitCSSMatrix) to latest spec.

Possibly there is no need to change anything in termtosvg, but it would be nice to somehow verify the cause of the issue.

Thanks for creating this tool!

Minimal HTML file:

<!DOCTYPE html>
<html class="no-js" lang="en">
<head>
    <meta charset="utf-8">
    <title>Term to SVG</title>
    <meta content="" name="description">
    <meta content="width=device-width, initial-scale=1" name="viewport">
</head>
<body>
    <object data="termtosvg_yjb4z6y3.svg"></object>
</body>
</html>

Interesting finding: while looking into moving the JS from the SVG to the HTML file, I noticed that after I changed this to false in Firefox's about:config

security.fileuri.strict_origin_policy

the problem with the freaky slider circle was gone!

In a way, this explains how I could not reproduce with the online example.

I did the setting change because I wanted to locally test accessing the contentDocument of the object element. Firefox normally returns null due to same origin policy affecting local file access.