Remove `<iframe seamless>` #331

Closed
annevk opened this Issue Nov 12, 2015 · 24 comments

Comments

@annevk
Member

annevk commented Nov 12, 2015

This seems like a good candidate for direct removal since per http://caniuse.com/#search=seamless nobody is doing this.

@foolip

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Nov 12, 2015

Member

Are the use cases for this simply left unsolved, or is it being done cooperatively with postMessage between the embedder and embedded frame?

Member

foolip commented Nov 12, 2015

Are the use cases for this simply left unsolved, or is it being done cooperatively with postMessage between the embedder and embedded frame?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Nov 13, 2015

Member

I don't think that solves all equally well, but it seems like shadow DOM solves most of them pretty well.

Member

annevk commented Nov 13, 2015

I don't think that solves all equally well, but it seems like shadow DOM solves most of them pretty well.

@foolip

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip Nov 14, 2015

Member

Support was removed from Blink in January 2014, and from the blink-dev discussion I take the sentiment to be more disinterest than disapproval.

It would be interesting to hear if there are fundamental problems with the feature, but it would take active implementor interest to save it.

Member

foolip commented Nov 14, 2015

Support was removed from Blink in January 2014, and from the blink-dev discussion I take the sentiment to be more disinterest than disapproval.

It would be interesting to hear if there are fundamental problems with the feature, but it would take active implementor interest to save it.

@sideshowbarker

This comment has been minimized.

Show comment
Hide comment
@sideshowbarker

sideshowbarker Dec 9, 2015

Member

It would be interesting to hear if there are fundamental problems with the feature, but it would take active implementor interest to save it.

I notice that in one of Adam Barth’s comments in the thread you cited, he says:

We're considering removing the feature because it's adding complexity to the style recalculation engine. Specifically, when working to improve style recalculation performance, we've often run into code and complexity that exists only to serve iframe@seamless. Removing that code and complexity will let us improve style recalculation performance faster.

As far as web-developer feedback on the feature, some comments from Ben Vinegar from last year are worth reading; among other things he says:

But while we’re not interested in the style component of the seamless
attribute, we – and probably all developers that hack on iframes – are
interested in the resizing behaviour it introduces. Right now we deploy
fairly complex code, both inside the iframed document, and on the parent
document, to resize the iframe element when the iframed content changes
size [2]. Every iframed application with dynamically-sized content does the
same.

To me, it’s crazy that it’s 2013 and there’s still no native way to have
the browser automatically resize an iframe. And yet we have seamless. But
it not only resizes: it adds all this other bundled behaviour, and strictly
serves a fringe use case where somebody is distributing iframes on the same
origin.

My suggestion is to split seamless into its three major parts: style
inheritance, iframe resizing, and browsing context.

So I think the gist of it all both from the implementor side and the web-dev side is that seamless as-specced doesn’t seem to be what anybody wanted to begin with. Or at least it’s more than anybody actually wanted. And anyway like @annevk says, it’s seems a lot of it’s since been “overcome by events” in light of Shadow DOM.

Member

sideshowbarker commented Dec 9, 2015

It would be interesting to hear if there are fundamental problems with the feature, but it would take active implementor interest to save it.

I notice that in one of Adam Barth’s comments in the thread you cited, he says:

We're considering removing the feature because it's adding complexity to the style recalculation engine. Specifically, when working to improve style recalculation performance, we've often run into code and complexity that exists only to serve iframe@seamless. Removing that code and complexity will let us improve style recalculation performance faster.

As far as web-developer feedback on the feature, some comments from Ben Vinegar from last year are worth reading; among other things he says:

But while we’re not interested in the style component of the seamless
attribute, we – and probably all developers that hack on iframes – are
interested in the resizing behaviour it introduces. Right now we deploy
fairly complex code, both inside the iframed document, and on the parent
document, to resize the iframe element when the iframed content changes
size [2]. Every iframed application with dynamically-sized content does the
same.

To me, it’s crazy that it’s 2013 and there’s still no native way to have
the browser automatically resize an iframe. And yet we have seamless. But
it not only resizes: it adds all this other bundled behaviour, and strictly
serves a fringe use case where somebody is distributing iframes on the same
origin.

My suggestion is to split seamless into its three major parts: style
inheritance, iframe resizing, and browsing context.

So I think the gist of it all both from the implementor side and the web-dev side is that seamless as-specced doesn’t seem to be what anybody wanted to begin with. Or at least it’s more than anybody actually wanted. And anyway like @annevk says, it’s seems a lot of it’s since been “overcome by events” in light of Shadow DOM.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Dec 14, 2015

Member

Note also that seamless requires changes to the event model that have never been specified.

Member

annevk commented Dec 14, 2015

Note also that seamless requires changes to the event model that have never been specified.

@annevk annevk removed the good first issue label Jan 1, 2016

@Ritsyy

This comment has been minimized.

Show comment
Hide comment
@Ritsyy

Ritsyy Jan 7, 2016

Collaborator

how should the removal of iframe seamless change for browsing context , as it would take a lot of changes for it's spec.

Collaborator

Ritsyy commented Jan 7, 2016

how should the removal of iframe seamless change for browsing context , as it would take a lot of changes for it's spec.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 7, 2016

Member

Yeah, things that look like they can be removed:

  • everything that says seamless
  • master concept in the "Browsing context names" section
  • the three columns about seamless in the big table
  • "explicit self-navigation override"

Basically everything that builds on top of the seamless feature can go.

Member

annevk commented Jan 7, 2016

Yeah, things that look like they can be removed:

  • everything that says seamless
  • master concept in the "Browsing context names" section
  • the three columns about seamless in the big table
  • "explicit self-navigation override"

Basically everything that builds on top of the seamless feature can go.

@Ritsyy

This comment has been minimized.

Show comment
Hide comment
@Ritsyy

Ritsyy Jan 7, 2016

Collaborator

okay @annevk , will remove the dependent spec on seamless feature.

Collaborator

Ritsyy commented Jan 7, 2016

okay @annevk , will remove the dependent spec on seamless feature.

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 22, 2016

Member

This was removed in 1490eba. My mistake for not linking it all together.

Member

annevk commented Jan 22, 2016

This was removed in 1490eba. My mistake for not linking it all together.

@annevk annevk closed this Jan 22, 2016

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jan 22, 2016

Member

Thank you @Ritsyy for making it happen! (And persisting despite my nitpicking. 😊)

Member

annevk commented Jan 22, 2016

Thank you @Ritsyy for making it happen! (And persisting despite my nitpicking. 😊)

@Ritsyy

This comment has been minimized.

Show comment
Hide comment
@Ritsyy

Ritsyy Jan 22, 2016

Collaborator

@annevk Learned a lot from this bug, thank you so much for all the reviews :)

Collaborator

Ritsyy commented Jan 22, 2016

@annevk Learned a lot from this bug, thank you so much for all the reviews :)

@annevk annevk referenced this issue in Fyrd/caniuse Jan 24, 2016

Closed

<iframe seamless> can be removed #2232

Ugoku pushed a commit to Recras/recras-wordpress-plugin that referenced this issue Jan 29, 2016

@AndySky21 AndySky21 referenced this issue in w3c/html Jan 29, 2016

Closed

Iframe seamless #35

@jhnns jhnns referenced this issue in craigfrancis/iframe-height Feb 9, 2016

Closed

+1 #1

@indolering

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering May 2, 2016

This is really disappointing as web components do not provide any security, you can't import a web component without it being able to manipulate the page it's in.

This is really disappointing as web components do not provide any security, you can't import a web component without it being able to manipulate the page it's in.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic May 2, 2016

Member

Yeah. It would have been cool if someone implemented, IMO, but a number of factors made it not a good tradeoff for implementers given other technologies that serve overlapping use cases (even if none of them serve the exact use case).

Member

domenic commented May 2, 2016

Yeah. It would have been cool if someone implemented, IMO, but a number of factors made it not a good tradeoff for implementers given other technologies that serve overlapping use cases (even if none of them serve the exact use case).

@jxn jxn referenced this issue in WebPlatformTest/HTML5test May 16, 2016

Closed

Remove Seamless from Security #440

@waldyrious waldyrious referenced this issue in waldyrious/waldyrious.github.io Jul 23, 2016

Open

[DRY] Use html imports for the common header #4

@thx1111

This comment has been minimized.

Show comment
Hide comment
@thx1111

thx1111 Aug 27, 2016

Well, here it is, now 2016 as I add this comment, and I am still using a terminal emulator to display my notes. I'd rather use a web browser for display, because, with things like html, latex, mathjax, and chemdoodle, my notes could draw from a rather rich expressive palette. But then, I also prefer a "modular" approach to writing, cutting and pasting together smaller documents, and then also, assembling those smaller sections to form a larger document. And it's nice to have the smaller bits both able to display on their own, and also contribute to that larger document. But, as it is, in 2016, there is still no simple native html markup to allow this sort of thing. https://stackoverflow.com/questions/8988855/include-another-html-file-in-a-html-file

Some people had hoped that some combination of "iframe", "seamless", and 'target="_parent"' would address this issue - but no. Instead, whatever the technical issues might be, there seems to be a kind of "stupid white men" paternalism that favors complex script-based source material intended to obfuscate rather than simplify. The implication being that end-users must not be content producers. And browser developers set-out to enforce this dictum. It's political, not technical.

Is that too harsh? Where is the simple html construct that assembles a single larger web page from a group of smaller pages, and adopts the styles from its hosting page, without resorting to a lot of javascript?

thx1111 commented Aug 27, 2016

Well, here it is, now 2016 as I add this comment, and I am still using a terminal emulator to display my notes. I'd rather use a web browser for display, because, with things like html, latex, mathjax, and chemdoodle, my notes could draw from a rather rich expressive palette. But then, I also prefer a "modular" approach to writing, cutting and pasting together smaller documents, and then also, assembling those smaller sections to form a larger document. And it's nice to have the smaller bits both able to display on their own, and also contribute to that larger document. But, as it is, in 2016, there is still no simple native html markup to allow this sort of thing. https://stackoverflow.com/questions/8988855/include-another-html-file-in-a-html-file

Some people had hoped that some combination of "iframe", "seamless", and 'target="_parent"' would address this issue - but no. Instead, whatever the technical issues might be, there seems to be a kind of "stupid white men" paternalism that favors complex script-based source material intended to obfuscate rather than simplify. The implication being that end-users must not be content producers. And browser developers set-out to enforce this dictum. It's political, not technical.

Is that too harsh? Where is the simple html construct that assembles a single larger web page from a group of smaller pages, and adopts the styles from its hosting page, without resorting to a lot of javascript?

@thx1111

This comment has been minimized.

Show comment
Hide comment
@thx1111

thx1111 Aug 27, 2016

BTW, "seamless" was back in again in the HTML 5.1 draft in 2016 Mar 10:
https://www.w3.org/TR/2016/WD-html51-20160310/semantics-embedded-content.html#seamless-iframe

but out again in the HTML 5.1 draft in 2016 Jun 02:
https://www.w3.org/TR/2016/WD-html51-20160602/semantics-embedded-content.html#the-iframe-element

Iframe "seamless" has not returned in the HTML 5.1 draft, 2016 Jun 21:
https://www.w3.org/TR/html51/semantics-embedded-content.html#the-iframe-element

or in the HTML 5.2 draft, 2016 Aug 18:
https://www.w3.org/TR/html52/semantics-embedded-content.html#the-iframe-element

If you are concerned, file an Issue:
https://github.com/w3c/html/issues/new

thx1111 commented Aug 27, 2016

BTW, "seamless" was back in again in the HTML 5.1 draft in 2016 Mar 10:
https://www.w3.org/TR/2016/WD-html51-20160310/semantics-embedded-content.html#seamless-iframe

but out again in the HTML 5.1 draft in 2016 Jun 02:
https://www.w3.org/TR/2016/WD-html51-20160602/semantics-embedded-content.html#the-iframe-element

Iframe "seamless" has not returned in the HTML 5.1 draft, 2016 Jun 21:
https://www.w3.org/TR/html51/semantics-embedded-content.html#the-iframe-element

or in the HTML 5.2 draft, 2016 Aug 18:
https://www.w3.org/TR/html52/semantics-embedded-content.html#the-iframe-element

If you are concerned, file an Issue:
https://github.com/w3c/html/issues/new

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 29, 2016

Member

Hello @thx1111 and welcome to WHATWG.

Please read the following:

https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F (3rd bullet point in this case)

Also please read: https://wiki.whatwg.org/wiki/Code_of_Conduct - try to be respectful, ranting and blaming is not very helpful. Thanks!

Member

zcorpan commented Aug 29, 2016

Hello @thx1111 and welcome to WHATWG.

Please read the following:

https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_a_specification.3F (3rd bullet point in this case)

Also please read: https://wiki.whatwg.org/wiki/Code_of_Conduct - try to be respectful, ranting and blaming is not very helpful. Thanks!

zcorpan added a commit to web-platform-tests/wpt that referenced this issue Sep 9, 2016

@zcorpan zcorpan referenced this issue in web-platform-tests/wpt Sep 9, 2016

Merged

Test that <iframe seamless> is not supported #3683

Ms2ger added a commit to web-platform-tests/wpt that referenced this issue Sep 9, 2016

@Florob Florob referenced this issue in voc/streaming-website Dec 10, 2016

Open

Embed-Tab: iframe contains invalid attributes #31

@smy315 smy315 referenced this issue in willfarrell/alfred-caniuse-workflow Dec 11, 2016

Closed

No longer working... #16

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Feb 18, 2017

It seems like the issue is that "seamless" inherited styles, which seemed foolish to begin with. I think "seamless" would be fine if it simply "autofit" it's content, such that embedding an iframe could effect the document flow of the document its embedded in. It's too bad this wasn't just added back in with just auto-resizing.

It seems like the issue is that "seamless" inherited styles, which seemed foolish to begin with. I think "seamless" would be fine if it simply "autofit" it's content, such that embedding an iframe could effect the document flow of the document its embedded in. It's too bad this wasn't just added back in with just auto-resizing.

@rniwa

This comment has been minimized.

Show comment
Hide comment
@rniwa

rniwa Feb 18, 2017

Collaborator

Note that auto-fitting the height turned out be a serious timing attack vector unless we restricted with CORS.

Collaborator

rniwa commented Feb 18, 2017

Note that auto-fitting the height turned out be a serious timing attack vector unless we restricted with CORS.

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Feb 18, 2017

@rniwa Oh? How did that make a site vulnerable?

@rniwa Oh? How did that make a site vulnerable?

@rniwa

This comment has been minimized.

Show comment
Hide comment
@rniwa

rniwa Feb 18, 2017

Collaborator

@matthew-dean : You can detect what kind of content was shown inside the frame based on how long it look to layout / style / paint.

Collaborator

rniwa commented Feb 18, 2017

@matthew-dean : You can detect what kind of content was shown inside the frame based on how long it look to layout / style / paint.

@ssokolow

This comment has been minimized.

Show comment
Hide comment
@ssokolow

ssokolow Feb 18, 2017

I'd still find it useful if a CORS check allowed me to combine sandbox (or a second domain) and seamless to load pages I control which then contain <script> embeds for things like Disqus.

Having variable-length resources in a scrollable iframe really isn't the best user experience most of the time but, at the very least, I'd really like to be able to keep all remotely loaded content from running in the same origin as my pages.

ssokolow commented Feb 18, 2017

I'd still find it useful if a CORS check allowed me to combine sandbox (or a second domain) and seamless to load pages I control which then contain <script> embeds for things like Disqus.

Having variable-length resources in a scrollable iframe really isn't the best user experience most of the time but, at the very least, I'd really like to be able to keep all remotely loaded content from running in the same origin as my pages.

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Feb 20, 2017

@rniwa I don't see how that would be possible; there are too many variables on load time, and detailed eventing would be presumably sandboxed. There are how many billions or trillions of web pages? How could you reliably profile page loads for pages that may change, and over connections that vary in latency throughout the day/week?

@rniwa I don't see how that would be possible; there are too many variables on load time, and detailed eventing would be presumably sandboxed. There are how many billions or trillions of web pages? How could you reliably profile page loads for pages that may change, and over connections that vary in latency throughout the day/week?

@rniwa

This comment has been minimized.

Show comment
Hide comment
@rniwa

rniwa Feb 20, 2017

Collaborator

Well, timing attack is typically done on a very specific website, which the attacker knows. A typical timing attack is robust against websites changing its content. You can read various research paper on this matter. e.g. https://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf

Collaborator

rniwa commented Feb 20, 2017

Well, timing attack is typically done on a very specific website, which the attacker knows. A typical timing attack is robust against websites changing its content. You can read various research paper on this matter. e.g. https://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf

@matthew-dean

This comment has been minimized.

Show comment
Hide comment
@matthew-dean

matthew-dean Feb 20, 2017

Hmm, still.... a theoretical successful detection doesn't equate to real-world exploits, as one of the requirements of such an exploit would be injection into the page hosting the iframe, or a user unwittingly installing a malicious script into their webpage. Even the calculate style vulnerability of the past relied on malicious scripts being allowed access in the first place.

Instead of limiting the utility of useful features of the web, maybe we should focus on the root cause, which is un-sandboxed third-party scripts having full access to the host environment instead of a limited or white-listed API. It just seems unfortunate if a very useful feature of the web becomes a casualty of poor design elsewhere.

Hmm, still.... a theoretical successful detection doesn't equate to real-world exploits, as one of the requirements of such an exploit would be injection into the page hosting the iframe, or a user unwittingly installing a malicious script into their webpage. Even the calculate style vulnerability of the past relied on malicious scripts being allowed access in the first place.

Instead of limiting the utility of useful features of the web, maybe we should focus on the root cause, which is un-sandboxed third-party scripts having full access to the host environment instead of a limited or white-listed API. It just seems unfortunate if a very useful feature of the web becomes a casualty of poor design elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment