New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 24 users

Issue metadata

Status: Verified
Closed: Oct 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Regression: SVG in IFrame uses maximum height of container instead of specified dimensions.

Reported by, Oct 3 2011 Back to list

Issue description

Chrome Version       : 15.0.874.58
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 4.x: OK
IE 7/8/9:

What steps will reproduce the problem?
1. Create an svg element within an iframe. Specify height and width on the svg element.

What is the expected result?
The svg element has the specified dimensions

What happens instead?
The svg element takes up the maximum amount of space it can in the iframe.

Please provide any additional information below. Attach a screenshot if possible.

I'm seeing this on Mac and Windows in Beta (15.0.874.58) and Dev (16.0.891.0).  However, this works as expected in production Chrome (14.0.835.187)

These links will demonstrate:

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.58 Safari/535.2

Labels: -Area-Undefined Area-WebKit

Comment 2 by, Oct 4 2011

Labels: SVG Mstone-16
Could you provide us with the detail steps to reproduce?

Tried with , I could not notice any change even though  I run the tool after changing the ht & width of the element.

Comment 4 by, Oct 6 2011

Try with this link instead:

The border surrounds an SVG element which should be 90px tall.  In the IFrame it's significantly taller even though the HTML is the same.
Any known workaround for this issue?

Comment 7 by, Oct 15 2011

Labels: -Type-Bug -Pri-2 -OS-Windows Type-Regression Pri-1 OS-All
Status: Untriaged
Word on the street is that this makes google docs unhappy.

Comment 8 by, Oct 18 2011

This is breaking a production application for us, for which we'll have to rely on Firefox.

Comment 9 by, Oct 18 2011

Just to be a little bit more explicit, we're using a GraphViz-generated SVG image as a navigable, clickable map of the configuration in our application.

As more items are added, we need scroll bars to appear, instead of the whole graph to be scaled down to fit the iframe into which the graph is loaded, because when it gets scaled down too much you can't even read which item you're clicking on.
I'm seeing this too.  It's especially obvious when I have multiple <svg> elements in one <iframe>, and I only see the first one because the rest are shunted out of view.
You can also see the problem in this simple example:

The results table is placed below the svg element (which in this case makes it invisible). 

In older versions of Chrome the table is placed to the right of the svg element.

Comment 12 by, Oct 19 2011

Have a fix in the pipeline now.

Comment 13 by, Oct 19 2011

Labels: Webkit-ID-64823
Uhm... I guess this fix doesn't touch our use case, that is to use the svg document (with a root svg element) as the iframe src.

What sense does it make to have the iframe dimensions override the perfectly valid and absolute values of width and height attributes in the svg element, forcing it to be up- or down-scaled to match the iframe, instead of allowing scrollbars like it would be done with an oversize html doc in src?

Comment 15 by, Oct 19 2011

It fixes the test cases attached to this bug. Please file another to track your issue and cc me on it.
@leviw - When submitted, I don't suppose there's any way we could get this fix into Chrome 15? (given that's where it regressed). Totally understand that it wouldn't be in the first stable release

Comment 17 by, Oct 20 2011

There's no reason on my end it shouldn't go into M15. It's a very simple fix.
Labels: Hotlist-GoogleApps
Project Member

Comment 19 by, Oct 24 2011

Labels: -Webkit-ID-64823 WebKit-ID-64823-NEW
The fix for this has gone into WebKit's trunk ( I'll work on getting it into M15/16.
Project Member

Comment 21 by, Oct 25 2011

Labels: -WebKit-ID-64823-NEW WebKit-ID-64823-RESOLVED

Comment 22 by, Oct 25 2011

Labels: Merge-Requested
@laforge what do you need from me to get this merged into M16? Looks like M15 already sailed...

Comment 23 by, Oct 25 2011

Labels: -Merge-Requested Merge-Approved

Comment 24 by, Oct 25 2011

Status: Fixed
Landed in M16 (

Comment 25 by, Nov 2 2011

Shouldn't we also be fixing this on 15 because it's a regression from Chrome 14?
I'm not against merging into 15. I went straight to M16 since M15 had already gone to stable. See c22 above.
Merged into M15 in

Comment 28 by, Nov 10 2011

So did this fix get into the just released 15.0.874.120 update or not?

Comment 29 by, Nov 11 2011

@krtul It's not fixed in 15.0.874.120...

Comment 30 by Deleted ...@, Nov 11 2011

Not fixed in 17.0.932.0 dev-m

Comment 31 by, Nov 11 2011

Ugh, 15 was a Drover failure on my part. It merged layout tests but not the code change. ToT has been fixed awhile, but if 17 is still broken it must have missed the branch date. I'll check.

Fixed the 15 branch in :(

Comment 32 by, Nov 11 2011

I'm running 17.0.932.0... it's fixed for me.
seems fixed, please refer the attachment
133 KB View Download

Comment 34 by, Nov 15 2011

Labels: -Merge-Approved Merge-Merged-912
Updating Merge-Merged based on history/comments.
Status: Verified
verified on 15.0.874.121 in Win7 and Linux, issue is fixed.
Project Member

Comment 36 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 37 by, Mar 9 2013

Labels: -Type-Regression -Area-WebKit -Mstone-16 Cr-Content Type-Bug-Regression M-16
Project Member

Comment 38 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 39 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment