|Summary:||Implement HTML5's seamless attribute for iframes|
|Product:||WebKit||Reporter:||Mirko Scavazzin <mscavazzin>|
|Severity:||Enhancement||CC:||ap, bronislav.klucka, bugmenot, buildbot, dglazkov, donggwan.kim, dstorey, eae, eric, julian.reschke, kennyluck, kihong.kwon, mike, morrita, pimvdb, rakeshchaitan, renatao.garcia, rniwa, s.choi, skyul, syoichi, webkit.review.bot, webmaster, zalan|
|Version:||528+ (Nightly build)|
|Bug Depends on:||91290, 82795, 82807, 82808, 82826, 85251, 85302, 85325, 85340, 85914, 85940, 86182, 86315, 86317, 86608, 87398, 87543, 87646, 87707, 87708, 89482, 90478, 90827, 90834, 90836, 91149, 91151, 93640, 95890, 99289, 103539, 106167|
Description Mirko Scavazzin 2010-09-17 01:20:44 PDT
We would like to see Webkit implement this attribute on Iframes.
Comment 1 Alexey Proskuryakov 2010-09-17 15:29:17 PDT
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 Mirko Scavazzin 2010-09-20 04:13:12 PDT
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 bugmenot 2011-01-01 07:21:30 PST
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 Eric Seidel (no email) 2012-03-29 16:57:56 PDT
Created attachment 134694 [details] first pass at some tests
Comment 5 Eric Seidel (no email) 2012-03-29 16:58:58 PDT
Tests which I still need to add include: - http-based seamless test (separate origin) - normal navigation (navigates _top implicitly) - target="_self" override
Comment 6 Eric Seidel (no email) 2012-03-31 01:29:26 PDT
(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. :)
Comment 7 Eric Seidel (no email) 2012-04-01 17:47:27 PDT
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 Eric Seidel (no email) 2012-04-04 18:59:15 PDT
Basic size negotiation works: https://github.com/eseidel/webkit/compare/master...seamless inline and floated seamless iframes still need fixes.
Comment 9 Eric Seidel (no email) 2012-04-27 23:06:55 PDT
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 Eric Seidel (no email) 2012-04-30 17:53:39 PDT
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 Eric Seidel (no email) 2012-05-01 13:19:31 PDT
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 Lars Gunther 2012-05-09 01:47:49 PDT
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 Eric Seidel (no email) 2012-05-09 01:57:00 PDT
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 Alexey Proskuryakov 2012-05-09 08:59:52 PDT
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 pimvdb 2012-05-12 13:30:44 PDT
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 Eric Seidel (no email) 2012-05-12 15:58:37 PDT
If you file a bug (and ideally attach a test case), I'm happy to look on monday.
Comment 17 Eric Seidel (no email) 2012-05-12 18:56:58 PDT
I really appreciate the feedback pimvdb. :)
Comment 18 Lars Gunther 2012-05-13 07:00:32 PDT
(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
Comment 19 Eric Seidel (no email) 2012-09-13 16:02:05 PDT
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 Eric Seidel (no email) 2012-12-29 08:20:44 PST
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 WebKit Review Bot 2013-03-10 13:42:13 PDT
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
Comment 22 Build Bot 2013-03-10 15:19:56 PDT
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
Comment 23 Build Bot 2013-03-11 03:20:22 PDT
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