Bug 45950 – Implement HTML5's seamless attribute for iframes

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Frames

[Mirko Scavazzin]

We would like to see Webkit implement this attribute on Iframes.

[Alexey Proskuryakov]

Would you be willing to explain why you need it? Everything in HTML5 is certainly considered for implementation, but knowing that there is a specific reason for Web developers to want a particular feature helps prioritize development.

[Mirko Scavazzin]

Thank you for taking our request into account.

In our product we make an extensive use of iframes for DOM fragmentation purposes. 
All of them are loading the same local page and share several CSS stylesheets.
Having the possibility to inherit stylesheets from a single parent page, instead of loading them everytime an iframe is created, would greatly increase our product performances and simplify the loading process.

I agree Mirko, implementing this feature would definitely make it less painfull using iframes. Especially when the iframe you're loading is _not_ under your control and you still want it to integrate *seamlessly* into your page.

[Eric Seidel (no email)]

Created attachment 134694 [details]
first pass at some tests

[Eric Seidel (no email)]

Tests which I still need to add include:
- http-based seamless test (separate origin)
- normal navigation (navigates _top implicitly)
- target="_self" override

[Eric Seidel (no email)]

(In reply to comment #2)
> Thank you for taking our request into account.
> 
> In our product we make an extensive use of iframes for DOM fragmentation purposes. 
> All of them are loading the same local page and share several CSS stylesheets.
> Having the possibility to inherit stylesheets from a single parent page, instead of loading them everytime an iframe is created, would greatly increase our product performances and simplify the loading process.

Browsers should be caching your stylesheets (assuming you have your cache headers set correctly), thus making the loads effectively no-ops (direct from memory/disk).  So seamless will not change the specific issue you raise there. :)

[Eric Seidel (no email)]

Development can be tracked here:
https://github.com/eseidel/webkit/compare/master...seamless

Will post a patch (patches?) here once everything is working and ready to land on trunk.

[Eric Seidel (no email)]

Basic size negotiation works:
https://github.com/eseidel/webkit/compare/master...seamless
inline and floated seamless iframes still need fixes.

[Eric Seidel (no email)]

My branch works great, and passes all tests with the exception of the float/inline case where the calculated height is off by 4 pixels!?  Still tracking down that bug, but plan to start posting patches for landing on Monday. :)

[Eric Seidel (no email)]

OK.  My branch work is done.  I'll be uploading patches on dependent bugs.

I'll land the feature behind a flag which folks can disable on their release branches if for some reason they do not wish to ship seamless at this time (since based on webkit-dev comments it sounds like Apple is preparing an imminent release).

[Eric Seidel (no email)]

Per the original proposal, I've removed the feature flag from these patches, as this should be enabled on all ports, and with timely reviews could easily be fully landed as soon as end-of-day tomorrow.

[Lars Gunther]

As far as I can see, there is nothing in this implementation so far that affects screen readers. The spec says that seamless iframes should "not be announced as new browsing context" (or something like that). Am I wrong about this not being part of the current solution, or is a new bug needed?

[Eric Seidel (no email)]

There has been no work on <iframe seamless> accessibility.  I would encourage you to file bugs about such once the feature is landed (and this bug is closed).  If you CC me I'm happy to CC appropriate Accessibility engineers.

[Alexey Proskuryakov]

Eric, I'm surprised that you don't consider accessibility as part of "implement a feature" master bug. It seems more central than inheriting stylesheets featurette, for instance.

I'm wondering the following - the HTML5 spec says this about "seamless":

"The attribute can be set or removed dynamically, with the rendering updating in tandem."

Currently if I remove the "seamless" attribute through the inspector, the styles of the parent page are still applied inside the iframe. When I then disable certain styles from the main page, the iframe is *not* updated.

As I understand from this sentence of the spec, the iframe should lose its styles inherited from the parent page as soon as the attribute is removed.

Is this possibly a bug?

(I'm not sure if this is an appropriate comment here, my apologies if it is not.)

[Eric Seidel (no email)]

If you file a bug (and ideally attach a test case), I'm happy to look on monday.

[Eric Seidel (no email)]

I really appreciate the feedback pimvdb.  :)

[Lars Gunther]

(In reply to comment #13)
> There has been no work on <iframe seamless> accessibility.  I would encourage you to file bugs about such once the feature is landed (and this bug is closed).  If you CC me I'm happy to CC appropriate Accessibility engineers.

Filed bug 86317

[Eric Seidel (no email)]

We believe seamless works well enough to ship, so it may be time to close this and move all remaining open bugs over to a "polish seamless until it shines" metabug.

[Eric Seidel (no email)]

Seamless is unfortunately no longer near the top of my priority list.  It has a couple bugs remaining, but until we have someone signed up to own it, we may consider disabling it on stable builds, or trunk.

Although I think it highly likely that other browsers will implement seamless, they have not yet -- it's likely that our implementation will need to change when they do.

I think it's a small amount of work to make seamless truly "ship-able" and a small amount of future work to adjust it with the evolving HTML5 spec.  Unfortunately I can't sign up for either at this point.

[WebKit Review Bot]

Comment on attachment 134694 [details]
first pass at some tests

Attachment 134694 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://webkit-commit-queue.appspot.com/results/17117041

New failing tests:
fast/frames/seamless/seamless-basic.html
fast/frames/seamless/seamless-nested.html
fast/frames/seamless/seamless-sandbox-flag.html
fast/frames/seamless/seamless-css-cascade.html

[Build Bot]

Comment on attachment 134694 [details]
first pass at some tests

Attachment 134694 [details] did not pass mac-ews (mac):
Output: http://webkit-commit-queue.appspot.com/results/17167040

New failing tests:
fast/frames/seamless/seamless-basic.html
fast/frames/seamless/seamless-nested.html
fast/frames/seamless/seamless-sandbox-flag.html
fast/frames/seamless/seamless-css-cascade.html

[Build Bot]

Comment on attachment 134694 [details]
first pass at some tests

Attachment 134694 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-commit-queue.appspot.com/results/17113501

New failing tests:
fast/frames/seamless/seamless-nested.html
fast/frames/seamless/seamless-basic.html
fast/frames/seamless/seamless-sandbox-flag.html
fast/frames/seamless/seamless-css-cascade.html

[Ahmad Saleem]

seamless iframe support was removed in this commit:

https://github.com/WebKit/WebKit/commit/3e2010a853456a8ad1e097897ef35ff5b54b2877

I am going to mark this and dependent open bug as "RESOLVED WONTFIX"? Thanks!