My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  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
Owner:  leviw@chromium.org
Closed:  Oct 2011
Cc:  dglazkov@chromium.org, gregsimon@chromium.org, lafo...@chromium.org
SVG

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
 
Reported by jon...@gmail.com, 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.
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



Oct 3, 2011
#1 willchan@chromium.org
(No comment was entered for this change.)
Labels: -Area-Undefined Area-WebKit
Oct 4, 2011
#2 kar...@google.com
(No comment was entered for this change.)
Labels: SVG Mstone-16
Oct 6, 2011
#3 ligim...@chromium.org
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.
Oct 6, 2011
#4 jon...@gmail.com
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.
Oct 14, 2011
#5 michaelt...@google.com
Any known workaround for this issue?
Oct 15, 2011
#7 thakis@chromium.org
Word on the street is that this makes google docs unhappy.
Status: Untriaged
Cc: dglazkov@chromium.org gregsimon@chromium.org
Labels: -Type-Bug -Pri-2 -OS-Windows Type-Regression Pri-1 OS-All
Oct 18, 2011
#8 skanda...@gmail.com
This is breaking a production application for us, for which we'll have to rely on Firefox.
Oct 18, 2011
#9 skanda...@gmail.com
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
#10 jason.da...@gmail.com
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
#11 sbanna...@concord.org
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.
Oct 19, 2011
#12 leviw@chromium.org
Have a fix in the pipeline now.

https://bugs.webkit.org/show_bug.cgi?id=64823
Owner: leviw@chromium.org
Oct 19, 2011
#13 lafo...@google.com
(No comment was entered for this change.)
Labels: Webkit-ID-64823
Oct 19, 2011
#14 skanda...@gmail.com
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
#15 leviw@chromium.org
It fixes the test cases attached to this bug. Please file another to track your issue and cc me on it.
Oct 20, 2011
#16 jeffhar...@google.com
@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
#17 leviw@chromium.org
There's no reason on my end it shouldn't go into M15. It's a very simple fix.
Oct 21, 2011
#18 jeffhar...@google.com
(No comment was entered for this change.)
Labels: Hotlist-GoogleApps
Oct 24, 2011
#19 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Webkit-ID-64823 WebKit-ID-64823-NEW
Oct 24, 2011
#20 levi.wei...@gmail.com
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.
Oct 25, 2011
#21 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -WebKit-ID-64823-NEW WebKit-ID-64823-RESOLVED
Oct 25, 2011
#22 leviw@chromium.org
@laforge what do you need from me to get this merged into M16? Looks like M15 already sailed...
Cc: lafo...@chromium.org
Labels: Merge-Requested
Oct 25, 2011
#23 lafo...@google.com
(No comment was entered for this change.)
Labels: -Merge-Requested Merge-Approved
Oct 25, 2011
#24 leviw@chromium.org
Landed in M16 (http://trac.webkit.org/changeset/98370).
Status: Fixed
Nov 2, 2011
#25 mal@google.com
Shouldn't we also be fixing this on 15 because it's a regression from Chrome 14?
Nov 2, 2011
#26 leviw@chromium.org
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
#28 krtul...@gmail.com
So did this fix get into the just released 15.0.874.120 update or not?

Nov 10, 2011
#29 orik...@gmail.com
@krtul It's not fixed in 15.0.874.120...
Nov 11, 2011
#30 oneadv...@gmail.com
Not fixed in 17.0.932.0 dev-m
Nov 11, 2011
#31 leviw@chromium.org
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 :(
Nov 11, 2011
#32 leviw@chromium.org
I'm running 17.0.932.0... it's fixed for me.
Nov 15, 2011
#33 pavanv@chromium.org
seems fixed, please refer the attachment
svg-issue.jpg
133 KB   View   Download
Nov 15, 2011
#34 lafo...@google.com
Updating Merge-Merged based on history/comments.
Labels: -Merge-Approved Merge-Merged-912
Nov 16, 2011
#35 pavanv@chromium.org
verified on 15.0.874.121 in Win7 and Linux, issue is fixed.
Status: Verified
Oct 12, 2012
#36 bugdro...@chromium.org
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
#37 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Type-Regression -Area-WebKit -Mstone-16 Cr-Content Type-Bug-Regression M-16
Mar 13, 2013
#38 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Apr 5, 2013
#39 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Sign in to add a comment

Powered by Google Project Hosting