1679242 - SVG: <g> element bounding boxes size up automatically

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[d_ominik.meixner]

Attachment: Screenshot of Chrome + Screenshot of Mozilla + SVG

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

I displayed a SVG file. (attached)

Actual results:

The bounding boxes of SOME <g> elements were dramatically out of bounds (e.g. The ones with the class "system" or "measure" (it does not depend on the class, at least i tried to manipulate it to a working class, which did not change anything).

Expected results:

The bounding boxes should have been according to the individual elements (system -> bounding box on the system / measure -> bounding box on the measure). It does work in chrome and I attached screenshots.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Jonathan Kew [:jfkthame]]

From a brief look, it seems like it's the <use xlink:href=...> elements where things go wrong; they're often indicating wildly inaccurate bounds, even though the content renders in the right place. And those bounds then contribute to their parent <g> elements.

Comment 3

[matthias.nowakowski]

I currently experience the same problem (with the same js package Verovio with the current Firefox Version (Mac and Windows). Chrome (Windows & Mac), Edge(Windows and Mac), Safari(Mac) are computing and displaying the bounding boxes correctly.

This is also verified by the respective js methods Element.getBoundingClinetRect() and SVGGraficsElement.getBBox()

However, the SVG is displayed correctly on older versions of Firefox.

Current Versions Tested on:
User Agent Mac: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Firefox/92.0

User Agent Windows: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92:0) Gecko/20100101 Firefox/92.0
Example for the same measure element:

Old Version tested on:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73:0) Gecko/20100101 Firefox/73.0

Comment 4

[Robert Longson [:longsonr]]

If it works on some prior version of Firefox then would you mind using mozregression to find a regression range please?

Comment 5

[matthias.nowakowski]

Thanks for the hint!
The last working release was 82.

Comment 6

[Robert Longson [:longsonr]]

A regression range should be a set of mercurial changesets within a date range or ideally only one change. Do post that in the bug if you get those details.

Comment 7

[lxpugin]

(In reply to Jonathan Kew (:jfkthame) from comment #2)

From a brief look, it seems like it's the <use xlink:href=...> elements where things go wrong; they're often indicating wildly inaccurate bounds, even though the content renders in the right place. And those bounds then contribute to their parent <g> elements.

I can confirm that it comes from the <use xlink:href>. If I remove all the SVG element that use it, then the problem disappears and the bounding box shown is correct.

Comment 8

[matthias.nowakowski]

The only info I have about the range set from the tool is this id:
a5cdfde00f159276453541049a8cbb5f7043ae2a
build_date: 2020-09-21

This is the changeset of the last release in which I could observe the right behaviour.

The problem was observed from the following release on:
e90233e0fe710a06566d5eb4711ca6743db37c14
build_date: 2020-10-19

Comment 9

[Robert Longson [:longsonr]]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a5cdfde00f159276453541049a8cbb5f7043ae2a&tochange=e90233e0fe710a06566d5eb4711ca6743db37c14

Comment 10

[matthias.nowakowski]

(In reply to Robert Longson [:longsonr] from comment #9)

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a5cdfde00f159276453541049a8cbb5f7043ae2a&tochange=e90233e0fe710a06566d5eb4711ca6743db37c14

Thanks for the link, but could you be more specific about, what you want me/ anybody to do?
In my opinion we have a pretty severe problem which can lead to unsatisfactory and problem specific workarounds.

Comment 11

[Robert Longson [:longsonr]]

I asked for a regression range and you provided it. Once you did that I removed the needinfo. I haven't asked for anything since and I'm not expecting you to do anything further. If you want to fix the bug yourself of course I'd be happy to review any patch you might supply.

Comment 12

[Robert Longson [:longsonr]]

Attachment: reporter's testcase

Comment 13

[Robert Longson [:longsonr]]

Attachment: Chrome rendering

Comment 14

[Robert Longson [:longsonr]]

Attachment: firefox rendering

Comment 15

[Robert Longson [:longsonr]]

`Firefox 112:
document.getElementById("measure-0000000329041036").getBoundingClientRect()
DOMRect { x: 597.88330078125, y: 24.833328247070312, width: 6436.58349609375, height: 3096.85009765625, top: 24.833328247070312, right: 7034.466796875, bottom: 3121.6834259033203, left: 597.88330078125 }

Chrome:
document.getElementById("measure-0000000329041036").getBoundingClientRect()
DOMRect {x: 319.680419921875, y: 58.59962844848633, width: 53.21795654296875, height: 29.183887481689453, top: 58.59962844848633, …}

Firefox with patch from bug 1827662
document.getElementById("measure-0000000329041036").getBoundingClientRect()
DOMRect { x: 587.4833374023438, y: 31.583328247070312, width: 29.866668701171875, height: 21.416671752929688, top: 31.583328247070312, right: 617.3500061035156, bottom: 53, left: 587.4833374023438 }