Project: chromium Issues People Development process History Sign in
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
Status: Verified
Owner:
Last visit > 30 days ago
Closed: Oct 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression
SVG

Restricted
  • 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 jon...@gmail.com, Oct 3 2011 Back to list
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.
2.
3.

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:
http://jonnew.com/js/svgIframe.html
http://jsfiddle.net/newtang/e7Nsq/

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 kareng@google.com, Oct 4 2011
Labels: SVG Mstone-16
Could you provide us with the detail steps to reproduce?

Tried with http://jsfiddle.net/newtang/e7Nsq/ , I could not notice any change even though  I run the tool after changing the ht & width of the element.
Comment 4 by jon...@gmail.com, Oct 6 2011
Try with this link instead: http://jonnew.com/js/svgIframe.html

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 tha...@chromium.org, Oct 15 2011
Cc: dglazkov@chromium.org gregsimon@chromium.org
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 skanda...@gmail.com, Oct 18 2011
This is breaking a production application for us, for which we'll have to rely on Firefox.
Comment 9 by skanda...@gmail.com, 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: http://bl.ocks.org/1296930

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 le...@chromium.org, Oct 19 2011
Owner: le...@chromium.org
Have a fix in the pipeline now.

https://bugs.webkit.org/show_bug.cgi?id=64823
Comment 13 by laforge@google.com, 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 le...@chromium.org, 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 le...@chromium.org, 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 bugdroid1@chromium.org, Oct 24 2011
Labels: -Webkit-ID-64823 WebKit-ID-64823-NEW
The fix for this has gone into WebKit's trunk (http://trac.webkit.org/changeset/98263). I'll work on getting it into M15/16.
Project Member Comment 21 by bugdroid1@chromium.org, Oct 25 2011
Labels: -WebKit-ID-64823-NEW WebKit-ID-64823-RESOLVED
Comment 22 by le...@chromium.org, Oct 25 2011
Cc: lafo...@chromium.org
Labels: Merge-Requested
@laforge what do you need from me to get this merged into M16? Looks like M15 already sailed...
Comment 23 by laforge@google.com, Oct 25 2011
Labels: -Merge-Requested Merge-Approved
Comment 24 by le...@chromium.org, Oct 25 2011
Status: Fixed
Landed in M16 (http://trac.webkit.org/changeset/98370).
Comment 25 by mal@google.com, 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 http://trac.webkit.org/changeset/99115.
Comment 28 by krtul...@gmail.com, Nov 10 2011
So did this fix get into the just released 15.0.874.120 update or not?

Comment 29 by orik...@gmail.com, 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 le...@chromium.org, 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 http://trac.webkit.org/changeset/100034 :(
Comment 32 by le...@chromium.org, Nov 11 2011
I'm running 17.0.932.0... it's fixed for me.
seems fixed, please refer the attachment
svg-issue.jpg
133 KB View Download
Comment 34 by laforge@google.com, 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 bugdroid1@chromium.org, 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 bugdroid1@chromium.org, Mar 9 2013
Labels: -Type-Regression -Area-WebKit -Mstone-16 Cr-Content Type-Bug-Regression M-16
Project Member Comment 38 by bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 39 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment