W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: Allow auto-resize on iframe

From: Craig Francis <craig.francis@gmail.com>
Date: Sat, 6 Feb 2016 19:34:37 +0000
Cc: Simon Pieters <simonp@opera.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-Id: <972FA66A-EB71-4961-8CEF-E35A5DEBA0C4@gmail.com>
To: Craig Francis <craig.francis@gmail.com>
On 1 Feb 2016, at 10:08, Craig Francis <craig.francis@gmail.com> wrote:

> Mike West and Anne van Kesteren from WebAppSec both think that a custom header would be best when working cross origin.
> 
> Something like:
> 
>    Expose-Height-Cross-Origin: 1;
> 
>    https://github.com/whatwg/html/issues/555#issuecomment-177797476
> 
> So assuming there aren't any better solutions (or header names), and using the following CSS for compatibility reasons:
> 
>    iframe { height: max-content; }
> 
> What's the next step?




Assuming the next step is to raise this with the different browsers, I've created the following feature requests:

Chrome
https://crbug.com/584913

Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1246423

Edge
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/12237801-feature-request-auto-resize-iframes-based-on-cont

Opera
https://forums.opera.com/discussion/1870727/feature-request-auto-resize-iframes-based-on-content#Item_1

Safari
https://bugs.webkit.org/show_bug.cgi?id=153952

And put all of my notes on:

https://github.com/craigfrancis/iframe-height


Where a second thought did occur to me... we could look at a new keyword for the resize[1] property, which would be useful for a <textarea> that automatically increases its height based on its content - another problem which requires JavaScript to solve.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/resize


Craig





> On 1 Feb 2016, at 10:08, Craig Francis <craig.francis@gmail.com> wrote:
> 
> On 29 Jan 2016, at 16:50, Craig Francis <craig.francis@gmail.com> wrote:
>> Maybe a new header, or maybe CSP, or something else?
> 
> 
> 
> 
> 
> Mike West and Anne van Kesteren from WebAppSec both think that a custom header would be best when working cross origin.
> 
> Something like:
> 
>    Expose-Height-Cross-Origin: 1;
> 
>    https://github.com/whatwg/html/issues/555#issuecomment-177797476
> 
> So assuming there aren't any better solutions (or header names), and using the following CSS for compatibility reasons:
> 
>    iframe { height: max-content; }
> 
> What's the next step?
> 
> Craig
> 
> 
> 
> 
> 
> 
> 
>> On 29 Jan 2016, at 16:50, Craig Francis <craig.francis@gmail.com> wrote:
>> 
>> On 28 Jan 2016, at 12:23, Simon Pieters <simonp@opera.com> wrote:
>> 
>>> For instance, adding CORS means that the content is also readable with XHR.
>> 
>> 
>> 
>> 
>> Good point.
>> 
>> It would be useful for the remote site to see the Origin header, but just simply opening access with "Access-Control-Allow-Origin" isn't a good idea.
>> 
>> It's a shame there isn't a way of saying "Access-Control-Allow-Feature" to go along with Origin/Methods/Headers/Credentials... but I don't think that can be added now, as too many websites and browsers have implemented the current functionality.
>> 
>> Maybe a new header, or maybe CSP, or something else?
>> 
>> Or do we just simply allow the browser to set the height and not worry about it... personally I don't want to allow another vector for information leakage, but you are right, there are other ways of doing this already.
>> 
>> Craig
>> 
>> 
>> 
>> 
>> 
>>> On 28 Jan 2016, at 12:23, Simon Pieters <simonp@opera.com> wrote:
>>> 
>>> On Thu, 28 Jan 2016 12:57:09 +0100, Craig Francis <craig.francis@gmail.com> wrote:
>>> 
>>>> 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?
>>> 
>>> For instance, adding CORS means that the content is also readable with XHR.
>>> 
>>>> 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).
>>> 
>>> Yep. Though this is typically possible through other means already, e.g. trying to load some resource and see if you get a 'load' or 'error' event.
>>> 
>>> 
>>>> 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
>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> Simon Pieters
>>> Opera Software
>> 
> 
Received on Saturday, 6 February 2016 19:35:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC