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

Steps to reproduce:

If a child <svg> element contains an <image> element, then later content in the root SVG will be clipped to the child SVG element's bounds.

First reported here: https://stackoverflow.com/questions/65525755/svg-rendering-problem-firefox-cuts-off-the-sibling-svg-elements-is-there-a-w

Here is a test case: https://jsfiddle.net/ajuqb49o/2/

<svg width="800" height="800"
style="background-color: pink">

<svg x="10" y="10" width="200" height="200">
<rect width="200" height="200" fill="blue"/>
<image width="200" height="200" href="http://www.placekitten.com/200/200"/>
</svg>

<rect width="220" height="220" fill="green" fill-opacity="0.5"/>

</svg>

Actual results:

The translucent green rectangle is being clipped to the bounds of the preceding child <svg> element. But that only happens if the child SVG contains an <image> element.

Expected results:

The green rectangle should be larger than the image. If you delete the <image> element, or view this test in a different browser, you will see the correct behaviour.

Alternate test link using a data url, in case the image doesn't load:

https://jsfiddle.net/z31Lsujt/

Attached comparison screenshots of results from Chrome and Firefox

Using https://mozilla.github.io/mozregression/ to find a regression range would be helpful if you're up for it Paul.

No problemo.

2021-01-01T21:49:13.752000: DEBUG : Found commit message:
Bug 1555356 - Make images inside of SVGs active. r=aosmond

(rebased Alexis' patch)

Differential Revision: https://phabricator.services.mozilla.com/D59925

2021-01-01T21:49:13.752000: DEBUG : Did not find a branch, checking all integration branches
2021-01-01T21:49:13.754000: INFO : The bisection is done.
2021-01-01T21:49:13.755000: INFO : Stopped

app_name: firefox
build_date: 2020-05-15 21:23:59.719000
build_file: C:\Users\Paul.mozilla\mozregression\persist\febf9ee6d477-shippable--autoland--target.zip
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/R0ZcKDl7R0K8DFLakUYAGQ/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: febf9ee6d477b5c892683cb9c0faae7970e9b883
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f340bbb582d16c083344b1370bd4e4d4caf5fb17&tochange=febf9ee6d477b5c892683cb9c0faae7970e9b883
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: R0ZcKDl7R0K8DFLakUYAGQ

Alexis, this appears to be another regression from bug 1555356, which already has several open. Would you be able to take a look?

I'm no longer on the graphics team, but I handed this work off to Jeff.

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

https://hg.mozilla.org/mozilla-central/rev/9efb772f0e09

I don't understand why, but this issue reproduces in the original version it was reported (Release v83), appears to have been fixed in Nightly v87.0a1 and Beta v86.0b5, but also does not reproduce in Release v85.0 and ESR v78.7.0esr, where it should probably be affected, considering the fix was pushed into v86.

Is it expected that Release and ESR versions do not reproduce the issue?

This is a webrender bug so if webrender is not enabled you'll not see it. Different releases have different webrender default on/off rules.