Status of Seamless iframes

[Elliott Sprehn]

Do we have plans to ship seamless iframes? Is anyone working on it?

I've noticed some bugs recently, ex. http://crbug.com/337541 and have been wondering if I should attempt to fix the bugs or just remove the feature until it has an owner (then someone can revert the deletion, finish the feature, and we can ship it).

Note: Safari 7+ is shipping this feature, but no other browser is.

- E

[Ojan Vafai]

AFAIK, this is just blocked on fixing https://code.google.com/p/chromium/issues/detail?id=233906.

[Eric Seidel]

I'm fine either way. Its definitely a tricky feature. If it has no active maintainer (I'm not actively developing it anymore) it should be removed.

I think ad networks would be very interested in the safety features Iframe + sandbox + seamless offers. 

[Jochen Eisinger]

IIRC Mike hacked on it a while ago, maybe he's still interested?

best

-jochen

[Mike West]

Mike did hack on this a while back. It is indeed basically done. Send the bugs to me, please. If I can get the event delegation work done this quarter, brilliant. If not, removing it while we wait for someone to pick it up might be reasonable.

Also: I didn't think that Safari was shipping seamless; I think they're only shipping (accidentally) the `seamless` DOM attribute and the user agent stylesheet for `iframe[seamless]`. I don't see styles being pushed down to the inner frame, nor does it appear to shrink wrap it's contents. *shrug*

-mike

-Mike

[Adam Barth]

Given that we haven't seen much customer interest in seamless, I think we should remove the feature.  We can work on the feature again in the future, but if I had to choose between investing in seamless and investing CSP 1.1, I'd choose CSP 1.1 because we have a number of customers asking us to complete CSP 1.1 whereas I haven't seem the same amount of demand for seamless.

Adam

[Kenneth Rohde Christiansen]

But then again, people know what CSP is by now and I bet that only
very few people have ever heard about seamless.

If you remove the code now, how does that affect the chances of Mike
West actually completing the work?

Kenneth

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.



--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆

[Mike West]

I agree completely with the prioritization. I didn't mean to give the impression that I'd be hopping directly onto seamless, only that I'm the last person who touched it, and am therefore the right guy to assign bugs to.

For clarity: I don't plan to look at seamless again until after I get CSP 1.1 in line with the current spec. If there's time leftover, polishing and shipping seamless would make sense (if someone else would like to step up to push seamless over the line more quickly, that would of course be awesome).

All that said, if there are maintenance issues with the code right now, or it's making work on some other feature more difficult, then rip it out. We can always revert the deletion later.

-mike 

-Mike

On Fri, Jan 24, 2014 at 3:38 PM, Adam Barth <aba...@chromium.org> wrote:

[Adam Barth]

On Fri, Jan 24, 2014 at 6:51 AM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

But then again, people know what CSP is by now and I bet that only
very few people have ever heard about seamless.

Yes, despite seamless having been included in the HTML living standard for significantly longer than CSP.  That tells me that there isn't much interest in using seamless and that it's likely to remain a niche feature.

 

If you remove the code now, how does that affect the chances of Mike
West actually completing the work?

It's likely to decrease the chances that Mike (or anyone else) completes the feature, but I think that's ok.

[Kenneth Rohde Christiansen]

On Fri, Jan 24, 2014 at 4:01 PM, Adam Barth <aba...@chromium.org> wrote:
> On Fri, Jan 24, 2014 at 6:51 AM, Kenneth Rohde Christiansen
> <kenneth.ch...@gmail.com> wrote:
>>
>> But then again, people know what CSP is by now and I bet that only
>> very few people have ever heard about seamless.
>
>
> Yes, despite seamless having been included in the HTML living standard for
> significantly longer than CSP. That tells me that there isn't much interest
> in using seamless and that it's likely to remain a niche feature.

I was just wondering whether that might change when we get
out-of-process iframes at some point. But of course the feature could
be re-enabled then.

>> If you remove the code now, how does that affect the chances of Mike
>> West actually completing the work?
>
> It's likely to decrease the chances that Mike (or anyone else) completes the
> feature, but I think that's ok.

If you are considering removing it because it is invalidating the
layout too often, couldn't that be fixed by making a runtime check?

Kenneth

[Adam Barth]

On Fri, Jan 24, 2014 at 7:06 AM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

On Fri, Jan 24, 2014 at 4:01 PM, Adam Barth <aba...@chromium.org> wrote:
> On Fri, Jan 24, 2014 at 6:51 AM, Kenneth Rohde Christiansen
> <kenneth.ch...@gmail.com> wrote:
>> But then again, people know what CSP is by now and I bet that only
>> very few people have ever heard about seamless.
>
> Yes, despite seamless having been included in the HTML living standard for
> significantly longer than CSP.  That tells me that there isn't much interest
> in using seamless and that it's likely to remain a niche feature.

I was just wondering whether that might change when we get
out-of-process iframes at some point. But of course the feature could
be re-enabled then.

Seamless is incompatible with out-of-process iframes, but that's not a big issue because seamless only works for same-origin iframes, which won't be out-of-process anyway.

 

>> If you remove the code now, how does that affect the chances of Mike
>> West actually completing the work?
>
> It's likely to decrease the chances that Mike (or anyone else) completes the
> feature, but I think that's ok.

If you are considering removing it because it is invalidating the
layout too often, couldn't that be fixed by making a runtime check?

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.

[Kenneth Rohde Christiansen]

OK thanks for the explanation. You are right, the styling of seamless
won't work with out of process iframes, but the auto-resizing could,
which is mostly what I though would be useful.

Kenneth

[Victor Costan]

I would guess that seamless iframes aren't used that much because
they're not supported by Firefox. That's the reason that stopped me
from investing too much time in them, anyway.

I thought seamless iframes will become an important tool in
modularizing a large app like Google+ or Gmail. It seems custom
elements + shadow DOM can offer the same benefits as iframes for
breaking apart CSS, but I don't know any construct for creating a
separate JS world for a part of the page. (workers don't count)

Is iframe@seamless causing difficulty because of the auto-resizing, or
because of parent CSS rules spilling into the child iframe? If it's
the latter, I'd venture to guess that an auto-resizing iframe without
CSS rules would still be useful, and ask to have the spec changed.

Is there another tool that Web developers are supposed to use to
modularize a page, JS-wise? Or are multiple JS worlds bad for perf, so
we don't want them? I'd expect that multiple worlds are good, because
they imply smaller object graphs for the GC.

Thank you,
Victor


On Fri, Jan 24, 2014 at 10:54 AM, Kenneth Rohde Christiansen

[Adam Barth]

On Sat, Jan 25, 2014 at 1:26 PM, Victor Costan <cos...@gmail.com> wrote:

I would guess that seamless iframes aren't used that much because
they're not supported by Firefox. That's the reason that stopped me
from investing too much time in them, anyway.

I thought seamless iframes will become an important tool in
modularizing a large app like Google+ or Gmail. It seems custom
elements + shadow DOM can offer the same benefits as iframes for
breaking apart CSS, but I don't know any construct for creating a
separate JS world for a part of the page. (workers don't count)

Yeah, that's the theory.  In practice, however, the folks building those products didn't seem interested in actually using the feature.

Is iframe@seamless causing difficulty because of the auto-resizing, or
because of parent CSS rules spilling into the child iframe? If it's
the latter, I'd venture to guess that an auto-resizing iframe without
CSS rules would still be useful, and ask to have the spec changed.

Is there another tool that Web developers are supposed to use to
modularize a page, JS-wise? Or are multiple JS worlds bad for perf, so
we don't want them? I'd expect that multiple worlds are good, because
they imply smaller object graphs for the GC.

There were two issues:

1) We had 3/4ths of an implementation of the feature for over a year, and we didn't see any demand from customers to finish the feature.  Compare that with CSP 1.1, where we get a steady stream of requests to finalize the spec and ship the feature, both from inside Google and from folks like Twitter.

2) The implementation of iframe@seamless involved adding code and complexity to central files, like Document and RenderView.  There's a limit to how many features we can support that add complexity to those files because so many developers need to read and understand how they work.

In summary, we removed support for iframe@seamless due to lack of customer interest and tight coupling with the rest of the engine.

[Erik Arvidsson]

On Sat, Jan 25, 2014 at 6:43 PM, Adam Barth <aba...@chromium.org> wrote:

On Sat, Jan 25, 2014 at 1:26 PM, Victor Costan <cos...@gmail.com> wrote:

I would guess that seamless iframes aren't used that much because
they're not supported by Firefox. That's the reason that stopped me
from investing too much time in them, anyway.

I thought seamless iframes will become an important tool in
modularizing a large app like Google+ or Gmail. It seems custom
elements + shadow DOM can offer the same benefits as iframes for
breaking apart CSS, but I don't know any construct for creating a
separate JS world for a part of the page. (workers don't count)

FYI

ES6 is introducing something called Realm which allows you to create a new context (think iframe without the dom).

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-realm-objects

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createrealm 

--
erik

[Victor Costan]

Thank you for pointing that out, Erik!

That's awesome. ES6 can't come soon enough. It seems like Custom
Elements + Shadow DOM + ES6 Realm can replace iframe@seamless. Do we
have any plan for getting seamless removed from the spec?

Victor

[sunil...@gmail.com]