Object does not adjust its size to the SVG data it currently refers to.
Categories
(Core :: SVG, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox141 | --- | fixed |
People
(Reporter: fuchsiahoney, Assigned: longsonr)
Details
Attachments
(7 files, 3 obsolete files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0
Steps to reproduce:
In an HTML file, an object element can refer to a SVG file like this:
<object data="small.svg"></object>
with small.svg being:
<svg xmlns="http://www.w3.org/2000/svg" width="160" height="120">
<a href="large.svg">
<image href="small.jpg"/>
</a>
</svg>
and large.svg being:
<svg xmlns="http://www.w3.org/2000/svg" width="800" height="600">
<a href="small.svg">
<image href="large.jpg"/>
</a>
</svg>
Actual results:
The object element initially takes on the size of small.svg correctly, 160x120. Upon clicking the link in small.svg, the object grows to 300x150, and remains at that size even after clicking the link in large.svg
Expected results:
The object should initially be 160x120, grow to the size of large.svg, 800x600, after clicking the link in small.svg, and shrink to the size of small.svg, its initial size, after clicking the link in large.svg
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Assignee | ||
Comment 2•2 years ago
|
||
Odd, seems like we should have fixed this in bug 1063073 That bug has a test: https://searchfox.org/mozilla-central/source/dom/svg/test/test_object-delayed-intrinsic-size.html
Reporter | ||
Comment 3•2 years ago
|
||
If a border is added to the object, and the inner link is clicked over and over again quickly, the border alone will sometimes be the correct size for an instant, before being shrunken to 300x150.
Reporter | ||
Comment 4•2 years ago
|
||
Reporter | ||
Comment 5•2 years ago
|
||
Reporter | ||
Comment 6•2 years ago
|
||
Reporter | ||
Comment 7•2 years ago
|
||
Reporter | ||
Comment 8•2 years ago
|
||
Assignee | ||
Comment 9•2 years ago
|
||
Assignee | ||
Comment 10•2 years ago
|
||
Assignee | ||
Comment 11•2 years ago
|
||
Assignee | ||
Comment 12•2 years ago
|
||
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 13•2 years ago
|
||
Seems to be a race between the new frame creation and the old frame destruction. The new frame creation happens first and then the old frame destruction sets the size back to the default.
Old frame destruction doesn't happen till nsDocumentViewer::Show when the previous document viewer is destroyed.
Assignee | ||
Comment 14•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
Comment 16•1 years ago
|
||
The severity field is not set for this bug.
:tlouw, could you have a look please?
For more information, please visit BugBot documentation.
Updated•1 years ago
|
Comment 17•1 day ago
|
||
Comment 18•1 day ago
|
||
Comment 19•1 day ago
|
||
Reverted this as requested by longsonr because it requires a reland with some adjustements.
Assignee | ||
Comment 20•1 day ago
|
||
Comment 21•1 day ago
|
||
Comment 22•20 hours ago
|
||
bugherder |
Description
•