1342800 - SVG invalid scaling inside IFrame due to ignored width/height

Status: RESOLVED FIXED

(Core :: SVG, defect, P3)

Description

[rustamabd]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Open an SVG object which has a width and height specified, inside an IFrame.

Examples:
https://rustyx.org/temp/svg-scaling/svg-scaling-test.html


Actual results:

Notice the object scaled to the size of the IFrame.


Expected results:

When an SVG has width and height specified, those must be honored, also inside IFrame.
It worked in FF before, and it still works in Chrome, IE, Edge.

Comment 1

[Robert Longson [:longsonr]]

When did this change? Can you use -moz-regression (http://mozilla.github.io/mozregression/) to give us a range?

Comment 2

[Robert Longson [:longsonr]]

By the way I'm not entirely sure this is valid but I am still curious as to when it changed.

If I give the object tag the same sizing information as the iframe i.e. style="width:100%;height:500px" it displays the same as the iframe.

Comment 3

[YF (Yang)]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ebc38a4eea8e66724294eb0e186ee158c8e41a8f&tochange=381a072b2525082f28154f865e7a2efd25886604

381a072b2525	Robert Longson — Bug 843480 - zoom on iframe is applied twice. r=jwatt

Comment 4

[Robert Longson [:longsonr]]

That just makes iframes behave the same as everything else i.e as comment 2.

Comment 5

[rustamabd]

IFrames don't work that way. An IFrame works more like a Window, you can't apply the style of the IFrame to the document displayed inside the IFrame, also in case of SVG. The inside of the IFrame is completely isolated from the outside.

Please see how this page looks in other browsers and compare it to FF:
https://rustyx.org/temp/svg-scaling/svg-scaling-test.html

Our site is completely broken on FF now. We have to block FF users for now.

Comment 6

[Robert Longson [:longsonr]]

iframes don't work what way? iframe, object and embed are all replaced elements, they work exactly the same way. It's true that styles are not cross document but I don't see why that's relevant.

Comment 7

[Robert Longson [:longsonr]]

Maybe we have some scaling problem across all the tags but it's not down to iframes. All we've done is make iframes work like object and embed but that doesn't mean that object and embed are right.

Comment 8

[rustamabd]

Sorry, let me clarify. All I'm saying is that normally any URL displayed inside an IFrame should look exactly as if it would be opened in a top-level window. There is normally no way to influence the scaling or any other aspect of the document displayed inside an IFrame from the page that contains the IFrame (except for manual intervention using JavaScript etc.). The only thing that can be influenced is the position of the IFrame itself, not its contents.

Right now an SVG opened inside an IFrame is scaled differently from when it is opened in a top-level window. That should not be the case.

Comment 9

[Robert Longson [:longsonr]]

There are rules for embedded documents that are different to those for top level windows. I.e. https://www.w3.org/TR/SVG/coords.html#ViewportSpace

You'll get further looking at how object differs between browsers (assuming it does) as our object sizing matches our iframe sizing now so if object/iframe is different to some other UAs object/iframe then we could look at changing both if that's sensible and we can all agree on what the rules should be.

Comment 10

[rustamabd]

The SVG Viewport spec does not apply, because iframing does not constitute embedding in the sense that is meant in the spec. The spec itself never mentions iframe: "the SVG content is a separately stored resource that is embedded by reference (such as the ‘object’ element in XHTML [XHTML]), or the SVG content is embedded inline within a containing document".

OBJECT and IFRAME are not the same things. OBJECT is intended for embedding content into the page, it *represents* an embedded object, and has the same size. An IFRAME is a *view* into another, independent *document*. And IFRAME has scrollbars, because it's outer size has no relation to the size of what is displayed inside (unless the displayed document explicitly uses window-relative sizing).

Whether an HTML document, an image or anything else is displayed inside an IFRAME does not make a difference. You don't scale an iframed HTML page, do you? Why should this basic rule change for SVG? Sure enough, not a single other browser does it this way, because it makes no sense.

Comment 11

[Amelia Bellamy-Royds]

The scaling & sizing differences between SVG objects, SVG in iframes, and SVG in img are not well spec'd.  They fall into the nether-region between the HTML, CSS, and SVG specs and working groups.  So I understand why Robert is hesitant to declare the current Firefox behavior a bug.

Nonetheless, prior to this change in Firefox, there was a de-facto, interoperable standard in all major browsers.  I've summarized the cases, with examples, in this CodePen:
http://codepen.io/AmeliaBR/full/VpPWOo/

For iframes, the expected behavior based on other browsers & older Firefox, is just as @rustamabd says.  An SVG with declared height and width should be rendered at that height and width in an iframe, just as it would in a top-level window of the same dimensions.  Scrollbars should be added if the SVG content box is larger than the frame.  Otherwise, the extra space is blank except for any root-element background, the same as if an HTML page had declared height and width on the root element.  If either height or width is not specified, they default to 100% (of the iframe's inner dimensions).

I was really disappointed when I opened up an object vs iframe comparison demo, and saw this was broken in Firefox.   Although I use object more often, the iframe behavior is really important if you want to create a scrollable view of a large SVG.

(PS: I have an outstanding action item from November to try to organize a WICG discussion on coming up with a spec to handle this and weird edge-cases like drawing an SVG image to canvas, but it's somewhat fallen off of priority what with everything else that happened to the SVG WG.  If anyone wants to get that discussion started, please ping me!)

Comment 12

[Robert Longson [:longsonr]]

Our previous behaviour simply didn't work at all if you tried to zoom the image. That's why we've changed. Bug 843480  has the details on that.

Comment 14

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 15

[violet.bugreport]

Attachment: Bug 1342800 - ComputeSize should not treat iframe as object

We should not treat <iframe> as <object> for SVG, otherwise there will
be unexpected sizing and other webcompat problem (e.g. getScreenCTM).

It behaved correctly before, the change was introduced to solve a double
zooming problem (bug 843480) for <iframe>. Actually the zooming problem
can be solved by avoiding zooming when the window frame is an <iframe>.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6ab85d4927b5
ComputeSize should not treat iframe as object r=firefox-svg-reviewers,longsonr

Comment 17

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/6ab85d4927b5