Re: [whatwg] iframe async
On 2/27/15 9:54 AM, David Bruant wrote: I jumped a bit to conclusions quickly, but I think the point remains. If the iframe is loaded in parallel (different thread, different process, anything that isn't blocking the parent), then its loading doesn't block the parent loading. Sure it does, to the extent that there is congestion on the TCP level, contention over processor timeslices, etc. I mean, it's not blocking in the sense that the parent can't finish until the iframe does, but it _can_ slow down the parent in various ways. I don't understand the concern with the shared net connection. Does the spec mandates the order of resource loading between parent and iframe? No, it does not. UAs use various heuristics for it right now. What's being proposed, afaict, is a way of providing a hint to those heuristics to deprioritize the iframe in question. If not, then browsers have enough liberty today to prioritize parent's resource loading over iframe without the need of an opt-in from devs, maybe? They have the liberty, but they don't always have enough information to know when to prioritize what. Please define async loading in the context of your question? What I meant was loading that doesn't block parent's loading. Loading iframes never blocks the parent's loading in the sense that you seem to be thinking of it. -Boris
Re: [whatwg] iframe async
Le 27/02/2015 15:54, David Bruant a écrit : Does the spec mandates the order of resource loading between parent and iframe? If so, is it also the case for sandboxed iframes? If not, then browsers have enough liberty today to prioritize parent's resource loading over iframe without the need of an opt-in from devs, maybe? Ok. I think I misread the original message. The request is to being able to provide different priority orders to different iframes (some containing not important content like ads, others containing important content) while what I'm suggesting treats all iframes the same way. David
Re: [whatwg] iframe async
On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote: You said that you got feedback from someone asking for this. What is the behavior they currently implement? Since I'm one of the people Anne talked to, I can expand a bit on what he said. Right now, we insert iframes containing ads on DOMContentLoaded (but this is not significant). We want these to have normal priority (otherwise we could insert them on load), but we don't want want them to delay load, mainly because *our* site is perceived as slow when the progress bar is shown. I don't think it's too uncommon for people to wait for the progress bar to disappear before they start interacting with the page. I do that sometimes, e.g. to make sure I don't misclick because an image loads and the page jumps. The bfcache problem is another thing that would be really nice to solve, yes. -- David Håsäther
Re: [whatwg] iframe async
Le 27/02/2015 17:27, David Håsäther a écrit : On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote: You said that you got feedback from someone asking for this. What is the behavior they currently implement? Since I'm one of the people Anne talked to, I can expand a bit on what he said. Right now, we insert iframes containing ads on DOMContentLoaded (but this is not significant). Perhaps it is. As someone else said on the thread, this delays the load event. We want these to have normal priority (otherwise we could insert them on load), but we don't want want them to delay load, mainly because *our* site is perceived as slow when the progress bar is shown. Which progress bar are you referring to? The browser load UI indicator? I don't think it's too uncommon for people to wait for the progress bar to disappear before they start interacting with the page. I do that sometimes, e.g. to make sure I don't misclick because an image loads and the page jumps. The progress bar problem and the load event problems seem distinct (but they're not because of how browsers implement the load UI indicator). The bfcache problem is another thing that would be really nice to solve, yes. From the problem statement, maybe the attribute that should be added is does-not-delay-load (which could be used on images or any element which loads something that delays the load event). IIRC some time ago, there was discussion on how an web page could tell the browser it's loaded (so the browser can take a screenshot for thumbnalil purposes). Usually, the load event is used, but it's unreliable (for JS-dependent SPA for instance), so it's be interesting if the webpage could tell I'm ready. Does someone know where we're at on this topic? It seems like it would solve the problem at hand. David
Re: [whatwg] iframe async
On Fri, Feb 27, 2015 at 5:51 PM, David Bruant bruan...@gmail.com wrote: We want these to have normal priority (otherwise we could insert them on load), but we don't want want them to delay load, mainly because *our* site is perceived as slow when the progress bar is shown. Which progress bar are you referring to? The browser load UI indicator? Yes. I don't think it's too uncommon for people to wait for the progress bar to disappear before they start interacting with the page. I do that sometimes, e.g. to make sure I don't misclick because an image loads and the page jumps. The progress bar problem and the load event problems seem distinct (but they're not because of how browsers implement the load UI indicator). I'm mainly talking about the load indicator for my use case, I'm not listening to the load event. The bfcache problem is another thing that would be really nice to solve, yes. From the problem statement, maybe the attribute that should be added is does-not-delay-load (which could be used on images or any element which loads something that delays the load event). Yes, good point, there are probably use cases outside of iframes, e.g. third-party images (like avatars, that could be considered unimportant). -- David Håsäther
Re: [whatwg] iframe async
On 2/27/15 4:43 AM, David Bruant wrote: It is my belief that providing the sandbox attribute should be a strong enough indicator that the iframe could be fully run in parallel (not just loaded async'ly). Iframes are already loaded async, obviously. It sounds like what's wanted here is more of a load this at lowest priority, which has nothing to do with whether it's running in the same thread (what I assume you mean by parallel) or not: either way the net connection is shared, right? Can async loading be retroffited into sandboxed iframes? Please define async loading in the context of your question? -Boris
Re: [whatwg] iframe async
Le 27/02/2015 15:23, Boris Zbarsky a écrit : On 2/27/15 4:43 AM, David Bruant wrote: It is my belief that providing the sandbox attribute should be a strong enough indicator that the iframe could be fully run in parallel (not just loaded async'ly). Iframes are already loaded async, obviously. It sounds like what's wanted here is more of a load this at lowest priority, which has nothing to do with whether it's running in the same thread (what I assume you mean by parallel) or not: either way the net connection is shared, right? I jumped a bit to conclusions quickly, but I think the point remains. If the iframe is loaded in parallel (different thread, different process, anything that isn't blocking the parent), then its loading doesn't block the parent loading. That's how things were implemented in Servo last I looked (admittedly some time ago and iframes were far from standard-compliant, but I think the demo was relevant anyway). I don't understand the concern with the shared net connection. Does the spec mandates the order of resource loading between parent and iframe? If so, is it also the case for sandboxed iframes? If not, then browsers have enough liberty today to prioritize parent's resource loading over iframe without the need of an opt-in from devs, maybe? Can async loading be retroffited into sandboxed iframes? Please define async loading in the context of your question? What I meant was loading that doesn't block parent's loading. David
Re: [whatwg] iframe async
Perhaps independent is a better name than async, indicating the iframe content is independent of the main page. Browser loading UI, load events, fast back and possibly performance tools would not take in to account independent iframes, since they are explicitly marked as not important to the working of the main page. I think there are widespread use cases for this: ads and those social icons (facebook, tweet etc) are all iframed, and I've seen pages look like they're really slow because they're waiting for a Tweet button to load when the main page was ready long ago. Performance tools is another case I bring up because I've seen some tools say the page took say 2 seconds to load, when the main page was really ready after 300ms and then it spent 1.7 seconds waiting for the Tweet button to finish its thing. It would be nice if performance tools could identify the independent iframe and not include it in such calculations. Ashley On 27 February 2015 at 17:28, David Håsäther hasat...@gmail.com wrote: On Fri, Feb 27, 2015 at 5:51 PM, David Bruant bruan...@gmail.com wrote: We want these to have normal priority (otherwise we could insert them on load), but we don't want want them to delay load, mainly because *our* site is perceived as slow when the progress bar is shown. Which progress bar are you referring to? The browser load UI indicator? Yes. I don't think it's too uncommon for people to wait for the progress bar to disappear before they start interacting with the page. I do that sometimes, e.g. to make sure I don't misclick because an image loads and the page jumps. The progress bar problem and the load event problems seem distinct (but they're not because of how browsers implement the load UI indicator). I'm mainly talking about the load indicator for my use case, I'm not listening to the load event. The bfcache problem is another thing that would be really nice to solve, yes. From the problem statement, maybe the attribute that should be added is does-not-delay-load (which could be used on images or any element which loads something that delays the load event). Yes, good point, there are probably use cases outside of iframes, e.g. third-party images (like avatars, that could be considered unimportant). -- David Håsäther
Re: [whatwg] iframe async
This is obviously larger than the particular set of use cases mentioned here, but another set of iframe discussions I've seen lately have centered around going off thread or out of process. I wonder if there is a more basic primitive here that can apply to all these use cases [and perhaps even allow for new behaviors we haven't thought of]? Perhaps a new email thread would be appropriate for such a discussion? In all these use cases we want to defer content within an iframe or render content off the main thread. Perhaps there is a fundamental API whereby we can decouple content from container (for non-seamless iframes)? Perhaps lifetime management, and the question of what context the content is loaded, and rendered in can be decoupled from the lifetime and layout of the container iframe? We've toyed with this idea internally in the Chrome webview tag https://developer.chrome.com/apps/tags/webview , but I am less experienced with the intricacies of iframes, so I don't want suggest any specifics for an API for iframes, but rather simply discuss the implications of decoupling content from container. If there is interest in that conversation, I can move that to a new email thread. Thanks, Fady Samuel Chrome Apps webview Tech Lead On Fri, Feb 27, 2015 at 1:31 PM, Ashley Gullen ash...@scirra.com wrote: Perhaps independent is a better name than async, indicating the iframe content is independent of the main page. Browser loading UI, load events, fast back and possibly performance tools would not take in to account independent iframes, since they are explicitly marked as not important to the working of the main page. I think there are widespread use cases for this: ads and those social icons (facebook, tweet etc) are all iframed, and I've seen pages look like they're really slow because they're waiting for a Tweet button to load when the main page was ready long ago. Performance tools is another case I bring up because I've seen some tools say the page took say 2 seconds to load, when the main page was really ready after 300ms and then it spent 1.7 seconds waiting for the Tweet button to finish its thing. It would be nice if performance tools could identify the independent iframe and not include it in such calculations. Ashley On 27 February 2015 at 17:28, David Håsäther hasat...@gmail.com wrote: On Fri, Feb 27, 2015 at 5:51 PM, David Bruant bruan...@gmail.com wrote: We want these to have normal priority (otherwise we could insert them on load), but we don't want want them to delay load, mainly because *our* site is perceived as slow when the progress bar is shown. Which progress bar are you referring to? The browser load UI indicator? Yes. I don't think it's too uncommon for people to wait for the progress bar to disappear before they start interacting with the page. I do that sometimes, e.g. to make sure I don't misclick because an image loads and the page jumps. The progress bar problem and the load event problems seem distinct (but they're not because of how browsers implement the load UI indicator). I'm mainly talking about the load indicator for my use case, I'm not listening to the load event. The bfcache problem is another thing that would be really nice to solve, yes. From the problem statement, maybe the attribute that should be added is does-not-delay-load (which could be used on images or any element which loads something that delays the load event). Yes, good point, there are probably use cases outside of iframes, e.g. third-party images (like avatars, that could be considered unimportant). -- David Håsäther
Re: [whatwg] iframe async
On Fri, Feb 27, 2015 at 3:59 PM, David Bruant bruan...@gmail.com wrote: The request is to being able to provide different priority orders to different iframes (some containing not important content like ads, others containing important content) while what I'm suggesting treats all iframes the same way. Yes, less important and therefore should not block the load event or any UA notion of complete. Fast back is a feature that some browsers implement where pressing the back button revives some object structures rather than loading the page again from disk or network. -- https://annevankesteren.nl/
Re: [whatwg] iframe async
On 2/27/15 10:24 AM, Anne van Kesteren wrote: On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@gmail.com wrote: To achieve this priorization, currently, authors would use a bit of JS to delay adding the iframe to the document. It seems like it solves all the issues listed in the original message (load UI, load event, fast back). Delay until what point? onload, if you don't want it to block onload. -Boris
Re: [whatwg] iframe async
I've started thinking about better iframes lately and I've been thinking along the lines of async iframes as well. If you start adding iframes onload, are you not forcing relayout? In an iframe async world, you can compute the layout of the top level frame before beginning to load the content of the iframe. This seems less jarring (not to mention faster), because you're not affecting layout of the main page by deferring loading iframe content? Fady Samuel On Fri, Feb 27, 2015 at 10:28 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/27/15 10:24 AM, Anne van Kesteren wrote: On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@gmail.com wrote: To achieve this priorization, currently, authors would use a bit of JS to delay adding the iframe to the document. It seems like it solves all the issues listed in the original message (load UI, load event, fast back). Delay until what point? onload, if you don't want it to block onload. -Boris
Re: [whatwg] iframe async
On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote: The exact same question stands for implementors of the current proposal. Until what point should a browser delay loading the iframe? The difference being that the author knows the relative importance of the various iframes among themselves and with the parent (at least better than the browser) and can make the choice between (non-exhaustive list): * a delay in ms after the delaying script starts executing * after DOMContentLoaded or load * or any amount of time after one of the two events. Maybe choose to load after twice the time it took for DOMContentLoaded (which one can know via performance API) * after first paint (there is a way to know when that happens, right? or with an upcoming spec?) * after some other resource has loaded (maybe to chain iframe loading) I'm sure there can be other reasonable options. I don't think it's reasonable for browsers to implement all these options. All of those delay the load event per earlier emails... You said that you got feedback from someone asking for this. What is the behavior they currently implement? Today they stamp out the template and users suffer (somewhat). -- https://annevankesteren.nl/
Re: [whatwg] iframe async
On 2/27/15 10:15 AM, David Bruant wrote: But for processor timeslices, the amount of blocking seems insignificant compared to the current situation as long as you have the hardware to run 2 threads in parallel, no? Until the subframe spins up a dozen workers, yes. To achieve this priorization, currently, authors would use a bit of JS to delay adding the iframe to the document. ... What is the significant benefit to adding an HTML attribute to solve this problem? This is a good question, yes. -Boris
Re: [whatwg] iframe async
On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@gmail.com wrote: To achieve this priorization, currently, authors would use a bit of JS to delay adding the iframe to the document. It seems like it solves all the issues listed in the original message (load UI, load event, fast back). Delay until what point? They could navigate I suppose, but it seems rather clumsy. What is the significant benefit to adding an HTML attribute to solve this problem? Not having to change infrastructure. -- https://annevankesteren.nl/
Re: [whatwg] iframe async
On 2/27/15 10:35 AM, Fady Samuel wrote: I've started thinking about better iframes lately and I've been thinking along the lines of async iframes as well. If you start adding iframes onload, are you not forcing relayout? You can add whenever and set src onload. Of course the more complicated the setup gets, the more desirable it is to have sugar for it. ;) In an iframe async world, you can compute the layout of the top level frame before beginning to load the content of the iframe. Modulo seamless iframes we have so many moving parts. -Boris
Re: [whatwg] iframe async
On Fri, Feb 27, 2015 at 4:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: onload, if you don't want it to block onload. Yeah that seems like a pretty bad alternative. That would be quite a significant delay. -- https://annevankesteren.nl/
Re: [whatwg] iframe async
Le 27/02/2015 15:58, Boris Zbarsky a écrit : On 2/27/15 9:54 AM, David Bruant wrote: I jumped a bit to conclusions quickly, but I think the point remains. If the iframe is loaded in parallel (different thread, different process, anything that isn't blocking the parent), then its loading doesn't block the parent loading. Sure it does, to the extent that there is congestion on the TCP level, contention over processor timeslices, etc. Sure. The TCP situation is probably about the same if parent and iframe are in same thread. But for processor timeslices, the amount of blocking seems insignificant compared to the current situation as long as you have the hardware to run 2 threads in parallel, no? I don't understand the concern with the shared net connection. Does the spec mandates the order of resource loading between parent and iframe? No, it does not. UAs use various heuristics for it right now. What's being proposed, afaict, is a way of providing a hint to those heuristics to deprioritize the iframe in question. If not, then browsers have enough liberty today to prioritize parent's resource loading over iframe without the need of an opt-in from devs, maybe? They have the liberty, but they don't always have enough information to know when to prioritize what. To achieve this priorization, currently, authors would use a bit of JS to delay adding the iframe to the document. It seems like it solves all the issues listed in the original message (load UI, load event, fast back). What is the significant benefit to adding an HTML attribute to solve this problem? David
Re: [whatwg] iframe async
On 2/27/15 10:06 AM, Anne van Kesteren wrote: Yes, less important and therefore should not block the load event or any UA notion of complete. Hmm. Not blocking the load event is interesting. Right now, even defer scripts and whatnot block the load event. Experimenting with an opt-in way to not block it for iframes could be exciting. yes. -Boris
Re: [whatwg] iframe async
Le 27/02/2015 16:24, Anne van Kesteren a écrit : On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@gmail.com wrote: To achieve this priorization, currently, authors would use a bit of JS to delay adding the iframe to the document. It seems like it solves all the issues listed in the original message (load UI, load event, fast back). Delay until what point? The exact same question stands for implementors of the current proposal. Until what point should a browser delay loading the iframe? The difference being that the author knows the relative importance of the various iframes among themselves and with the parent (at least better than the browser) and can make the choice between (non-exhaustive list): * a delay in ms after the delaying script starts executing * after DOMContentLoaded or load * or any amount of time after one of the two events. Maybe choose to load after twice the time it took for DOMContentLoaded (which one can know via performance API) * after first paint (there is a way to know when that happens, right? or with an upcoming spec?) * after some other resource has loaded (maybe to chain iframe loading) I'm sure there can be other reasonable options. I don't think it's reasonable for browsers to implement all these options. You said that you got feedback from someone asking for this. What is the behavior they currently implement? What are people doing today to work around this iframe loading issue? David
Re: [whatwg] iframe async
On 2/27/15 2:18 PM, Tim Streater wrote: One thing I'd like would be to be able to put content into an iframe (and thus have it parsed), but defer any rendering or speculative download of resources referred to in the content. Depending on whether you care about the href of your iframe and whether you want it sandboxed and so forth: var parsedThing = new DOMParser().parseFromString(myString, text/html); // Process parsedThing however you want. myIframe.contentDocument.replaceChild( parsedThing.documentElement, myIframe.contentDocument.documentElement ); -Boris
Re: [whatwg] iframe async
On 27 Feb 2015 at 18:52, Fady Samuel fsam...@chromium.org wrote: This is obviously larger than the particular set of use cases mentioned here, but another set of iframe discussions I've seen lately have centered around going off thread or out of process. I wonder if there is a more basic primitive here that can apply to all these use cases [and perhaps even allow for new behaviors we haven't thought of]? Perhaps a new email thread would be appropriate for such a discussion? In all these use cases we want to defer content within an iframe or render content off the main thread. Perhaps there is a fundamental API whereby we can decouple content from container (for non-seamless iframes)? Perhaps lifetime management, and the question of what context the content is loaded, and rendered in can be decoupled from the lifetime and layout of the container iframe? One thing I'd like would be to be able to put content into an iframe (and thus have it parsed), but defer any rendering or speculative download of resources referred to in the content. This will allow me to modify it. What happens is that I am given a text string, which is untrusted HTML and which may be badly formed, and which I want to modify to remove or disable certain elements before the browser proceeds with it. The content *may* be spam and I want to prevent it from phoning home. In principle I could parse the string myself but the browser will do a much better job than I can, which is why I want to modify the content *after* parsing, rather than before. -- Cheers -- Tim
Re: [whatwg] iframe async
Hi Anne, Le 27/02/2015 08:57, Anne van Kesteren a écrit : I got feedback that isolating ads from your page through iframe is desirable, but that the impact on browser load UI, the load event, and fast back, are very much not desirable. It's the first time I read the term fast back? What does it refer to? It seems there should be some way to indicate that the iframe should function, but is not a critical part of the page. Perhaps this could be tied to sandboxing in some way. It is my belief that providing the sandbox attribute should be a strong enough indicator that the iframe could be fully run in parallel (not just loaded async'ly). A bit of context https://groups.google.com/forum/#!topic/mozilla.dev.platform/lwzsJtZVf7Q https://bugzilla.mozilla.org/show_bug.cgi?id=961689 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23040 (to guarantee isolated iframes to remain so). Among the benefits of stuffing perf benefits with the sandbox attribute is that more people will use it for perf and get the security benefits along the way. This is somewhat similar tohttps://w3c.github.io/resource-hints/ but that seems rather indirect and does not include UI or fast back considerations. Can async loading be retroffited into sandboxed iframes? David
Re: [whatwg] iframe async
On 27 Feb 2015 at 19:38, Boris Zbarsky bzbar...@mit.edu wrote: On 2/27/15 2:18 PM, Tim Streater wrote: One thing I'd like would be to be able to put content into an iframe (and thus have it parsed), but defer any rendering or speculative download of resources referred to in the content. Depending on whether you care about the href of your iframe and whether you want it sandboxed and so forth: var parsedThing = new DOMParser().parseFromString(myString, text/html); Yes, already doing this. // Process parsedThing however you want. myIframe.contentDocument.replaceChild( parsedThing.documentElement, myIframe.contentDocument.documentElement ); Thanks, I'll try this instead of: myIframe.write (new XMLSerializer().serializeToString (parsedThing)); which I'm doing at present :-) -- Cheers -- Tim
Re: [whatwg] HTTP/2 push detection and control in JavaScript
On Tue, Feb 24, 2015 at 9:32 AM, Brendan Long s...@brendanlong.com wrote: HTTP/2 associates priority information with HEADERS http://http2.github.io/http2-spec/#HEADERS (but as a flag, not as a normal header), so maybe it would make sense to add this to Fetch's Headers https://fetch.spec.whatwg.org/#headers-class. I'm not sure if it makes sense to put it on Request https://fetch.spec.whatwg.org/#request-class, since it seems to only expose readonly attributes. HTTP/2 allows reprioritization via PRIORITY frame [1], so this is something we should account for in the API. E.g. application starts fetching an image (high priority fetch) but the user advances to the next image in the gallery, at which point the applications want to reprioritize the initial fetch such that it still completes and gets cached, but doesn't compete with new+other fetches that are of higher priority. [1] http://http2.github.io/http2-spec/#PRIORITY
[whatwg] referrer attribute
This group may be interested in a recent change[1] to the referrer policy which allows overriding the global document referrer policy for specific elements (namely a, area, img, iframe). Any comments?--[1] http://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-delivery-referrer-attribute
