1689732 - Mouse interaction with SVG Elements failing after altering style and appending.

Status: RESOLVED DUPLICATE of bug 1683652

(Core :: SVG, defect)

Description

[michael.woolnough]

Attachment: Reduced example of the bug

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Step 1: Set width/height of an SVG element via style attribute.
Step 2: (Re-)Attach element to DOM.

With the attached file, clicking Small, and then clicking Large should show this problem.

Actual results:

The enlarged SVG Element doesn't respond to the mouse as it should beyond the original dimensions.

With the attached file, after clicking Small, and then clicking Large, only the area of the Green Rectangle which was contained within it's smaller self has a pointer cursor and the onclick event.

Expected results:

The enlarged SVG Element should be clickable over it's entire size, not just the original size.

With the attached file, after clicking Small, and then clicking Large, the entire Green Rectangle should have the pointer cursor and be clickable.

This is what happens if you click Large first, and then go between clicking Small and Large.

Some geometry that is used to determine mouse interactions is not being updated correctly when the node is not attached.

Comment 1

[Daniel Holbert [:dholbert]]

Hmm, I can't reproduce in Nightly 87.0a1 (2021-01-30) (64-bit) on Ubuntu 20.10, for some reason. I click "Small", and then "Large", I can successfully hover + click the extreme bottom-right corner of the now-larger square just fine.

So perhaps this has been fixed, or perhaps there's some subtlety to the conditions required for reproducing this...

Comment 2

[Daniel Holbert [:dholbert]]

Aha -- it turns out there's one more important step in the Steps To Reproduce (with the attached testcase).

STEPS TO REPRODUCE:

1. Load testcase.
2. Click "Small"
3. Hover the square.
4. Click "Large"
5. Hover (and/or click) the bottom right of the square.

Without step 3 -- hovering while you're at the "Small" phase -- I can't reproduce any issues. But with that step included, I can reproduce the described problem in e.g. the Nightly from December 1, 2020.

Good news, though! It's been fixed in newer Nightlies. A run of mozregression --find-fix tells me it was fixed in this range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=70234746857ecbee1a02212ca146d50224bcb11a&tochange=c38b504a94295b09dce13d91e04ff9714b0eb67b

So, this is effectively a duplicate of (and fixed by) bug 1683652.