Open Bug 1867409 Opened 5 months ago Updated 3 months ago

Object does not adjust its size to the SVG data it currently refers to.


(Core :: SVG, defect, P3)

Firefox 119





(Reporter: fuchsiahoney, Assigned: longsonr)



(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="" width="160" height="120">
<a href="large.svg">
<image href="small.jpg"/>

and large.svg being:

<svg xmlns="" width="800" height="600">
<a href="small.svg">
<image href="large.jpg"/>

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

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.

Component: Untriaged → SVG
Product: Firefox → Core

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.

Attached file test.html
Attached image small.jpg
Attached image large.jpg
Attached image small.svg (obsolete) —
Attached image large.svg (obsolete) —
Attached image large.svg
Attachment #9366220 - Attachment is obsolete: true
Attached image small.svg (obsolete) —
Attachment #9366219 - Attachment is obsolete: true
Attached image small.svg
Attachment #9366239 - Attachment is obsolete: true
Attachment #9366241 - Attachment mime type: text/plain → text/html

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: nobody → longsonr
Ever confirmed: true

The severity field is not set for this bug.
:tlouw, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(tlouw)
Severity: -- → S3
Flags: needinfo?(tlouw)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.