New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users
Status: WontFix
Owner:
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 233906



Sign in to add a comment
Implement HTML5's seamless attribute for iframes
Project Member Reported by mkwst@chromium.org, Aug 8 2013 Back to list
Migrated from WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=45950
Originally reported 2010-09-17 01:20 PST by Mirko Scavazzin (mscavazzin@gmail.com).


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


Blocks:
[http://wkb.ug/40829] NEW - Get a perfect score on html5test.com
Depends On:
[http://wkb.ug/82795] RESOLVED LATER - Add tests for iframe seamless and support for parsing webkitseamless attribute
[http://wkb.ug/82807] RESOLVED FIXED - styleForElement() should use enums instead of bools so we can all understand what it's doing
[http://wkb.ug/82808] RESOLVED LATER - Clean up MediaQueryEvaluator construction in CSSStyleSelector (and remove out of date comments)
[http://wkb.ug/82826] RESOLVED LATER - Add security checks for iframe seamless
[http://wkb.ug/85251] RESOLVED FIXED - Add seamless test cases (all of these will pass as we land the implementation patches)
[http://wkb.ug/85302] RESOLVED FIXED - Add support for seamless attribute as well as seamless sandbox flag and default CSS styling
[http://wkb.ug/85325] RESOLVED FIXED - Remove uneeded min/max pref width assignment from RenderView
[http://wkb.ug/85340] RESOLVED FIXED - Add <iframe seamless> navigation code (and pass all the navigation tests)
[http://wkb.ug/85914] RESOLVED FIXED - Add stylesheet inheritance support to IFRAME_SEAMLESS
[http://wkb.ug/85940] RESOLVED FIXED - Make IFRAME_SEAMLESS child documents inherit styles from their parent iframe element
[http://wkb.ug/86182] NEW - [Qt] fast/frames/seamless/seamless-inherited-document-style.html fails
[http://wkb.ug/86315] RESOLVED FIXED - Styles are not recalculated when the seamless attribute is dynamically added/removed
[http://wkb.ug/86317] RESOLVED FIXED - Seamless iframe should not announce a new browsing context
[http://wkb.ug/86608] RESOLVED FIXED - Add seamless layout code (and pass all the remaining seamless tests)
[http://wkb.ug/87398] NEW - Heap-use-after-free in WebCore::RenderLayer::updateCompositingLayersAfterScroll
[http://wkb.ug/87543] RESOLVED FIXED - [Win] ~1/2 of all the iframe seamless tests fail
[http://wkb.ug/87646] RESOLVED FIXED - Fix ENABLE_IFRAME_SEAMLESS to actually fully disable <iframe seamless>
[http://wkb.ug/87707] RESOLVED FIXED - <iframe seamless> using display: inline or float, (shrink-wrapping) are too tall
[http://wkb.ug/87708] RESOLVED FIXED - Add HTMLIFrameElement.seamless property accessor now that seamless is enabled and works
[http://wkb.ug/89482] RESOLVED DUPLICATE
[http://wkb.ug/90478] RESOLVED DUPLICATE
[http://wkb.ug/90827] RESOLVED FIXED - seamless iframes don't take border into account properly and make the iframe too small.
[http://wkb.ug/90834] RESOLVED FIXED - the body of seamless iframes should default to margin:0
[http://wkb.ug/90836] RESOLVED DUPLICATE - shrinkwrapped seamless iframes have scrollbars when they shouldn't
[http://wkb.ug/91149] RESOLVED WONTFIX
[http://wkb.ug/91151] RESOLVED WORKSFORME
[http://wkb.ug/91290] NEW - Support an event propagation across seamless iframes.
[http://wkb.ug/93640] RESOLVED FIXED
[http://wkb.ug/95890] RESOLVED FIXED - seamless iframes should not inherit editability
[http://wkb.ug/99289] RESOLVED FIXED - Iframe seamless not applying styles with dynamic iframe content
[http://wkb.ug/103539] RESOLVED FIXED - seamless iframes don't inherit styles when srcdoc is used
[http://wkb.ug/106167] RESOLVED FIXED - Seamless: IFrame's padding isn't taken into account when calculating its height.

Attachments:
2012-03-29 16:57 PST: first pass at some tests [https://bugs.webkit.org/attachment.cgi?id=134694&action=prettypatch]



Comments:
================================

Comment #1
Posted on 2010-09-17 15:29:17 PST by Alexey Proskuryakov (ap@webkit.org)

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.

================================

Comment #2
Posted on 2010-09-20 04:13:12 PST by Mirko Scavazzin (mscavazzin@gmail.com)

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.

================================

Comment #3
Posted on 2011-01-01 07:21:30 PST by bugmenot@mailinator.com (bugmenot@mailinator.com)

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.

================================

Comment #4
Posted on 2012-03-29 16:57:56 PST by Eric Seidel (eric@webkit.org)

Created an attachment (id=134694) [https://bugs.webkit.org/attachment.cgi?id=134694] [details] [https://bugs.webkit.org/attachment.cgi?id=134694&action=edit]
first pass at some tests

================================

Comment #5
Posted on 2012-03-29 16:58:58 PST by Eric Seidel (eric@webkit.org)

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

================================

Comment #6
Posted on 2012-03-31 01:29:26 PST by Eric Seidel (eric@webkit.org)

(In reply to comment #2 [https://bugs.webkit.org/show_bug.cgi?id=45950#c2])
> 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. :)

================================

Comment #7
Posted on 2012-04-01 17:47:27 PST by Eric Seidel (eric@webkit.org)

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.

================================

Comment #8
Posted on 2012-04-04 18:59:15 PST by Eric Seidel (eric@webkit.org)

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

================================

Comment #9
Posted on 2012-04-27 23:06:55 PST by Eric Seidel (eric@webkit.org)

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. :)

================================

Comment #10
Posted on 2012-04-30 17:53:39 PST by Eric Seidel (eric@webkit.org)

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

================================

Comment #11
Posted on 2012-05-01 13:19:31 PST by Eric Seidel (eric@webkit.org)

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.

================================

Comment #12
Posted on 2012-05-09 01:47:49 PST by Lars Gunther (webmaster@keryx.se)

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?

================================

Comment #13
Posted on 2012-05-09 01:57:00 PST by Eric Seidel (eric@webkit.org)

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.

================================

Comment #14
Posted on 2012-05-09 08:59:52 PST by Alexey Proskuryakov (ap@webkit.org)

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.

================================

Comment #15
Posted on 2012-05-12 13:30:44 PST by pimvdb@live.nl (pimvdb@live.nl)

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

================================

Comment #16
Posted on 2012-05-12 15:58:37 PST by Eric Seidel (eric@webkit.org)

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

================================

Comment #17
Posted on 2012-05-12 18:56:58 PST by Eric Seidel (eric@webkit.org)

I really appreciate the feedback pimvdb.  :)

================================

Comment #18
Posted on 2012-05-13 07:00:32 PST by Lars Gunther (webmaster@keryx.se)

(In reply to comment #13 [https://bugs.webkit.org/show_bug.cgi?id=45950#c13])
> 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  [https://bugs.webkit.org/show_bug.cgi?id=86317]

================================

Comment #19
Posted on 2012-09-13 16:02:05 PST by Eric Seidel (eric@webkit.org)

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.

================================

Comment #20
Posted on 2012-12-29 08:20:44 PST by Eric Seidel (eric@webkit.org)

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.

================================

Comment #21
Posted on 2013-03-10 13:42:13 PST by WebKit Review Bot (webkit.review.bot@gmail.com)

(From update of attachment 134694 [https://bugs.webkit.org/attachment.cgi?id=134694] [details] [https://bugs.webkit.org/attachment.cgi?id=134694&action=edit])
Attachment 134694 [https://bugs.webkit.org/attachment.cgi?id=134694] [details] [https://bugs.webkit.org/attachment.cgi?id=134694&action=edit] 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

================================

Comment #22
Posted on 2013-03-10 15:19:56 PST by Build Bot (buildbot@hotmail.com)

(From update of attachment 134694 [https://bugs.webkit.org/attachment.cgi?id=134694] [details] [https://bugs.webkit.org/attachment.cgi?id=134694&action=edit])
Attachment 134694 [https://bugs.webkit.org/attachment.cgi?id=134694] [details] [https://bugs.webkit.org/attachment.cgi?id=134694&action=edit] 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

================================

Comment #23
Posted on 2013-03-11 03:20:22 PST by Build Bot (buildbot@hotmail.com)

(From update of attachment 134694 [https://bugs.webkit.org/attachment.cgi?id=134694] [details] [https://bugs.webkit.org/attachment.cgi?id=134694&action=edit])
Attachment 134694 [https://bugs.webkit.org/attachment.cgi?id=134694] [details] [https://bugs.webkit.org/attachment.cgi?id=134694&action=edit] 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
 
Comment 1 by mkwst@chromium.org, Aug 8 2013
Blockedon: chromium:233906
Comment 4 by ojan@chromium.org, Oct 16 2014
Cc: -ojan@chromium.org
Sign in to add a comment