My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 98951: Regression: SVG in IFrame uses maximum height of container instead of specified dimensions.
24 people starred this issue and may be notified of changes. Back to list
Status:  Verified
Closed:  Oct 2011

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Reported by, Oct 3, 2011
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

Oct 3, 2011
(No comment was entered for this change.)
Labels: -Area-Undefined Area-WebKit
Oct 4, 2011
(No comment was entered for this change.)
Labels: SVG Mstone-16
Oct 6, 2011
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.
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.
Oct 14, 2011
Any known workaround for this issue?
Oct 15, 2011
Word on the street is that this makes google docs unhappy.
Status: Untriaged
Labels: -Type-Bug -Pri-2 -OS-Windows Type-Regression Pri-1 OS-All
Oct 18, 2011
This is breaking a production application for us, for which we'll have to rely on Firefox.
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.
Oct 18, 2011
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.
Oct 18, 2011
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.
Oct 19, 2011
Have a fix in the pipeline now.
Oct 19, 2011
(No comment was entered for this change.)
Labels: Webkit-ID-64823
Oct 19, 2011
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?

Oct 19, 2011
It fixes the test cases attached to this bug. Please file another to track your issue and cc me on it.
Oct 20, 2011
@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
Oct 20, 2011
There's no reason on my end it shouldn't go into M15. It's a very simple fix.
Oct 21, 2011
(No comment was entered for this change.)
Labels: Hotlist-GoogleApps
Oct 24, 2011
(No comment was entered for this change.)
Labels: -Webkit-ID-64823 WebKit-ID-64823-NEW
Oct 24, 2011
The fix for this has gone into WebKit's trunk ( I'll work on getting it into M15/16.
Oct 25, 2011
(No comment was entered for this change.)
Labels: -WebKit-ID-64823-NEW WebKit-ID-64823-RESOLVED
Oct 25, 2011
@laforge what do you need from me to get this merged into M16? Looks like M15 already sailed...
Labels: Merge-Requested
Oct 25, 2011
(No comment was entered for this change.)
Labels: -Merge-Requested Merge-Approved
Oct 25, 2011
Landed in M16 (
Status: Fixed
Nov 2, 2011
Shouldn't we also be fixing this on 15 because it's a regression from Chrome 14?
Nov 2, 2011
I'm not against merging into 15. I went straight to M16 since M15 had already gone to stable. See c22 above.
Nov 10, 2011
So did this fix get into the just released 15.0.874.120 update or not?

Nov 10, 2011
@krtul It's not fixed in 15.0.874.120...
Nov 11, 2011
Not fixed in 17.0.932.0 dev-m
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 :(
Nov 11, 2011
I'm running 17.0.932.0... it's fixed for me.
Nov 15, 2011
seems fixed, please refer the attachment
133 KB   View   Download
Nov 15, 2011
Updating Merge-Merged based on history/comments.
Labels: -Merge-Approved Merge-Merged-912
Nov 16, 2011
verified on 15.0.874.121 in Win7 and Linux, issue is fixed.
Status: Verified
Oct 12, 2012
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.
Labels: Restrict-AddIssueComment-Commit
Mar 9, 2013
(No comment was entered for this change.)
Labels: -Type-Regression -Area-WebKit -Mstone-16 Cr-Content Type-Bug-Regression M-16
Mar 13, 2013
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Apr 5, 2013
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Sign in to add a comment

Powered by Google Project Hosting