# Remove <iframe seamless> #331

Closed
opened this Issue Nov 12, 2015 · 24 comments

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.

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?
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.
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.
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.
Member

### annevk commented Dec 14, 2015

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

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.
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.
Collaborator

### Ritsyy commented Jan 7, 2016

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

Closed

Member

### annevk commented Jan 22, 2016

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

Member

### annevk commented Jan 22, 2016

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

### Ritsyy commented Jan 22, 2016

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

Closed

Open

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

 Seamless attribute is removed from spec 
Ref: whatwg/html#331
 f2176de 

Closed

Closed

### indolering commented 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.
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).

Closed

Open

### 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 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
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 referenced this issue Sep 9, 2016

 Remove <iframe seamless> 
This reverts edits made in the following set of commits:

dfa3f22
8edfe6d
9e4f095
b0b5d7b
e5a041e
cc33290
c4d6396
f6490f1
77e24cd
0eab1dd
1782006
2898fa9
3a6cfaf
5ae9881
748113c
4814a86
9dd420c
 1490eba 

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

 Test that <iframe seamless> is not supported 
See whatwg/html#331
 475bb6b 

Merged

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

 Test that <iframe seamless> is not supported (#3683); r=Ms2ger 
See whatwg/html#331
 1281c2f 

Open

Closed

### matthew-dean commented 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.
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 commented Feb 18, 2017

 @rniwa Oh? How did that make a site vulnerable?
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 commented Feb 18, 2017 • edited Edited 1 time ssokolow edited Feb 18, 2017 (most recent)

 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 `

### matthew-dean commented 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?
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 commented 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.