561114 - object tag width incorrect when rendering external SVG

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Jamie Thompson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

I am seeing rendering glitches when loading SVg files into object tags (as they won't load into IMG tags either as per bug: https://bugzilla.mozilla.org/show_bug.cgi?id=276431).

When displayed in a list styled to look like a table using the "display: table-*" properties, the last object tag gains additional width (the images are square and should render as 14x14 as per "height: 14px" on the object tag, but the last renders as a 14x14 image centred on a 19x14 canvas).

Additionally, when rendered in a span with some other nodes as per:
<span><span>A</span><object data="a.png"></object> B<object data="B.svg" ></object>12+</span>

My object tag renders out as 36x14!

If I adjust any width-altering properties using Firebug the width snaps to the expected width and stays there until the page reloads.

Reproducible: Always

Steps to Reproduce:
1. Load an SVG file into an object tag mixed into some other html content.
2. Set a height for the object tag, so the SVG scales the width to fit.
3. Observe the width of the object tag is often incorrect.
Actual Results:  
The object tag is rendered with undesired horizontal margins.

Expected Results:  
The SVG file renders as per the viewBox.

Comment 1

[Robert Longson [:longsonr]]

object is a block level element but span is not.

Comment 2

[Robert Longson [:longsonr]]

Although the table thing may be bug 489924. Examples added as attachments would help of course.

Comment 3

[Robert Longson [:longsonr]]

Reopening. Is this bug 489924 reporter? If not can you attach an example.

Comment 4

[Jamie Thompson]

(In reply to comment #3)
> Reopening. Is this bug 489924 reporter? If not can you attach an example.

Bug 489924 is not mine. I'll try and put together test cases when I get some free moments. I can't put in the actual output due to disclosure issues, but I should be able to simplify things enough over lunch tomorrow as it was appearing in multiple scenarios.

(In reply to comment #1)
> object is a block level element but span is not.

Quite right, but I would expect behaviour to be consistent (loading a PNG into an object is correctly rendered with the correct width, whilst the SVG is not - an in several cases the first few SVG object were correct and it was just the last one in the series that had the "bonus" width).

Comment 5

[Robert Longson [:longsonr]]

What I meant was, Is the issue you have the same as the one described in bug 489924?

Comment 6

[Jamie Thompson]

Attachment: Sample SVG file

Originally taken from Wikipedia, but edited to remove height and width and use viewBox instead so it scales.

Comment 7

[Jamie Thompson]

Attachment: Sample page displaying width issues

As can be seen when rendered, the square SVG file loaded in the object tag with a max-height applied does not retain it's aspect ratio.

Comment 8

[Jamie Thompson]

(In reply to comment #7)
> Created an attachment (id=441003) [details]
> Sample page displaying width issues
> 
> As can be seen when rendered, the square SVG file loaded in the object tag with
> a max-height applied does not retain it's aspect ratio.

Ignore that attachment - my attempts to get a test case left accidetally left the height and width attributes on the tags. Back to notepad ;)

Comment 9

[Robert Longson [:longsonr]]

You can click on the details button for an attachment and check the obsolete checkbox to indicate that an attachment is to be ignored.

Comment 10

[Jamie Thompson]

Attachment: Visual of incorrect width

Snapshot of the problem as seen in a list whose items are aligned using display: "table: cell".

All non-test images are SVGs, and object tags have a border to highlight the issue.

Comment 11

[Jamie Thompson]

Attachment: Visual of the problem when multiple object tags are used inline

Snapshot of the problem as seen in a container with multiple SVG objects.

All images aside from the blue flag are SVGs, and object tags have a border to highlight the issue.

As you can see, the first (ESRB-M) has the correct width, but the PEGI does not.
Additionally, you can see the enlarged PEGI on it's own has the extra width.

You can see from the list attachment that when it's not the last object in the tag it has the correct width.

Comment 12

[Jamie Thompson]

Attachment: Visual of the problem when multiple object tags are used inline

Snapshot of the problem as seen in a container with multiple SVG objects.

All images aside from the blue flag are SVGs, and object tags have a border to highlight the issue.

As you can see, the (ESRB-M) has the correct width inline as it is not the first item but you can see when enlarged on it's own it has the extra width.

Comment 13

[Jamie Thompson]

Ok, I think I know what's "triggering" this issue. My images are inside ASP update panels, and the width isn't being correctly determined when the content is updated.

Is there anything I can do to force FireFox to recalculate the widths when the content is updated as a work around?

Comment 14

[Robert Longson [:longsonr]]

Can you provide a complete testcase please? You should be able to link your html wrapper file to any svg files you have previously uploaded if you need to do that.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Or just upload a zip file.

Comment 16

[Jamie Thompson]

I wasn't able to produce a minimal test case at work as I'd hoped. If the problem is indeed due to the object-tag-hosted SVG files being located in ASP.net Update Panels (http://www.asp.net/ajax/documentation/live/overview/UpdatePanelOverview.aspx) as I believe it to be, then a test case would probably require a ASP-enabled server. Given one of those the test case is trivial.

As I don't have one available (my home server runs Debian...so ASP.net isn't really available ;) ) I'll attempt to put together something this weekend that adds these SVG objects in a similar manner using plain vanilla JavaScript and see if it behaves the same. Alas, I suspect, given the weight of the ASP.net AJAX framework, it won't be.

For the record, the way I attempted to get a minimal test case was to save the html of a page exhibiting the problem and then stripping out as much content as I could. Once I got close to the bare minimum (literally just the containing DIV chain back to the form tag, the script tags, and the head tag containing copies of all the normally-external CSS rules), the issue became intermittent. Perhaps I damaged too much of the page structure for the JavaScript to get far enough to trigger the problem, or perhaps the speed solved it, but regardless, there was a change.

However, once I removed the script tags I was unable to trigger the problem until re-adding the JavaScript. Unfortunately, most of the JavaScript is just ASP framework gubbins that are useless without the server-side components, so completely useless as a test case for you developers.

I'll get back to you with the vanilla JavaScript test case.

Comment 17

[Jamie Thompson]

Attachment: Self-contained testcase showing the incorrect width of dynamically-added SVG object tags

The top row is SVG, the bottom row is baked PNG. Click the buttons to observe the problem.

Comment 18

[Jamie Thompson]

Attachment: SVG baked into a PNG for testcase.

Comment 19

[Jamie Thompson]

Attachment: Self-contained testcase showing the incorrect width of dynamically-added SVG object tags

The top row is SVG, the bottom PNG. Click the buttons to cone them and see from the red border that the width comes out wring for the most recently-added SVG.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Hmm.  I got that testcase to show the problem exactly once for me: on the very first load before cloning anything.

Robert, if layout happens for the <object> before we've parsed the size of the contained SVG document, what makes sure we update the <object> size once that SVG document's size is known?

Comment 21

[Robert Longson [:longsonr]]

Pretty much the same here on the reproducibility. I did see it again once but it's pretty rare.

jwatt is the expert for object sizing.

Comment 22

[Jonathan Watt [:jwatt]]

nsSVGOuterSVGFrame::AttributeChanged takes care of updating the <object> size once the SVG document's size is known.

http://mxr.mozilla.org/mozilla-central/source/layout/svg/base/src/nsSVGOuterSVGFrame.cpp#482

Comment 23

[Boris Zbarsky [:bzbarsky]]

Jonathan, how does that help if the object is reflowed between when we decide the document is svg (so have a subframe) and the creation of the outermost svg frame in the subdocument?

Comment 24

[Jonathan Watt [:jwatt]]

It won't. :-) How would it be best to solve this? Is it okay to request reflow of one frame at the time when another is constructed?

Comment 25

[Boris Zbarsky [:bzbarsky]]

Probably not in general, though might be ok in this case.  And it's certainly fine to post an event to request reflow.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Note that comment 23 just describes my best guess for what's happening in this bug, btw.  There could be something else going on.

Comment 27

[actium]

Attachment: stand-alone testcase showing incorrect width of svg statically included via object-tag

I just stumbled upon this one trying to steer clear of 600207 (and add a fallback solution for non SVG-capable IE-versions). The only way to solve this I came up with is to add width- and height-attributes to the object tag.

Does anyone have an idea for a server-side quick'n'dirty-fix that does not involve adding width- and height-attributes?


Tested versions:
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 and
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120407 Firefox/13.0a2

Reproducible: Always

Steps to reproduce: Open index.html in attached zip-file

Expected result: Text in adjacent table-cell does not overlap with SVG-image when height- and width-attributes are not specified.

Actual result: Text does overlap with SVG.

Comment 28

[Robert Longson [:longsonr]]

I can't get this to happen any more.

Comment 29

[actium]

(In reply to Robert Longson from comment #28)
> I can't get this to happen any more.

Unfortunately my test-case from comment #27 still produces (exactely) the same result as in the screenshot included in the attachment.

now I'm running Firefox 21 on Fedora 19 ("Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0")

tell me if you need any additional information to track this down.

Comment 30

[Robert Longson [:longsonr]]

Works now. jwatt landed a fix for this some time ago although I can't find the bug number.

Comment 31

[Robert Longson [:longsonr]]

Probably fixed by bug 1063073