Re: Allow auto-resize on iframe

On 27 Jan 2016, at 13:02, Simon Pieters <simonp@opera.com> wrote:

> CORS doesn't require an extra request for normal GETs. But I think we should investigate the use cases for cross-origin autoresize more first; maybe using CORS is not suitable because it would expose "too much", and autoresize was the only thing people wanted to enable?



Good point, has been a while since I last did any CORS work.

When you say it will expose "too much", what do you mean by this?

I'm just thinking of the height of the iframed page allowing a malicious website (the one that created the iframe) to infer something about the victim website within the iframe (e.g. is this user logged in).



I think in most cases iframes work exceptionally well at allowing you to include content from elsewhere.

This is often because another website is providing the content, or because you have some content that you want to sandbox (because it's potentially untrusted).

But the problem I often face is getting the iframe to have the right height (just so it does not create scroll bars):

http://stackoverflow.com/search?q=resize+iframe

The dumb approach is to set its height to something ridiculously tall.

Or the more complicated one involves JavaScript + postMessage(), and this is always implemented slightly differently between websites.



And you won't hear any complaints from me about it being done via "height: max-content" :-)

Craig




> On 27 Jan 2016, at 13:02, Simon Pieters <simonp@opera.com> wrote:
> 
> On Wed, 27 Jan 2016 12:56:55 +0100, Craig Francis <craig.francis@gmail.com> wrote:
> 
>> On 26 Jan 2016, at 19:23, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 
>>> Some quick conversation with fantasai suggests a few routes that we could take that would avoid a new property:
>> 
>> 
>> 
>> 
>> Thanks TJ,
>> 
>> Personally I like the idea of "height: auto" on an iframe, where the UA stylesheet sets it to 150px, but completely understand that compatibility might be an issue there (even if developers are doing this just to get this specific behaviour).
> 
> I suspect height:auto won't be Web compatible. For one thing, I believe it would change the heights of iframes for pages that do
> 
>    * { box-sizing: border-box; }
> 
> 
>> Having said that, as the child document will need to opt-in to this, then maybe this won't be a problem?
>> 
>> From my understanding, the opt-in is required as someone malicious could iframe another website where the user might be logged in, and depending on if they are logged in or not, the height of the document might be different.
>> 
>> CORS might work, and uses existing technology, but this does require an additional HTTP request (not so good for performance)... so maybe there as other options? I was thinking of the X-Frame-Options header, but this seems to be moving to CSP2 frame-ancestors[1]
> 
> CORS doesn't require an extra request for normal GETs. But I think we should investigate the use cases for cross-origin autoresize more first; maybe using CORS is not suitable because it would expose "too much", and autoresize was the only thing people wanted to enable?
> 
> 
>> But if this doesn't work, then "height: max-content" would also be perfectly fine for me (I just don't want to continue setting up more iframes, with 2 JavaScript files, just to avoid a scroll bar).
> 
> height:max-content WFM.
> 
> -- 
> Simon Pieters
> Opera Software

Received on Thursday, 28 January 2016 11:57:42 UTC