23508 2013-10-14 20:44:23 +0000 Browsers want to know when a page's scripts have finished 'loading', even if the scripts aren't delaying the 'load' event any more (e.g. they do computation on startup) 2017-07-21 11:00:27 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED WONTFIX P3 enhancement Needs Impl Interest 1 ian ian annevk ian mike contributor oldest_to_newest 94704 0 ian 2013-10-14 20:44:23 +0000 On Wed, 24 Apr 2013, Robert O'Callahan wrote: > > Context: https://bugzilla.mozilla.org/show_bug.cgi?id=863499 > > Use-cases: > > 1) User-agents provide thumbnails of Web pages (e.g. desktop Firefox, > FirefoxOS and Safari do this). We want to avoid taking a thumbnail while > the application is incompletely loaded. The firing of the document load > event is not currently a reliable indicator since the application might > have ongoing load activities (e.g. IndexedDB transactions, Websocket > activity) that do not block the document load event. > > 2) User-agent has UI to distinguish pages that are in the process of > loading from pages that are fully loaded. As in use-case #1, relying on the > document load event as currently defined to transition the UI to the "fully > loaded" state may be inaccurate. > > Proposal: > > Give Web applications APIs to explicitly delay the document load event. In > particular, add a method "document.delayLoadEvent()" that causes the > document load event to be delayed until a corresponding > "document.stopDelayingLoadEvent()" method is called. Allow these to nest so > that the document load event is delayed until at least as many calls to > stopDelayingLoadEvent() have been made as there were calls to > delayLoadEvent(). > > Alternatives: > > Applications can fake this already by triggering an invisible subresource > load of a URI that never returns any data and never ends, and cancelling > the load when they want to stop delaying the load event. That seems fragile > and ugly. On Wed, 24 Apr 2013, Glenn Maynard wrote: > > This seems a bit heavy-handed. For these use cases, it doesn't seem like > you need to delay the whole onload event, which would have tons of > side-effects on the page. You could just tell the browser that you're > still doing things, without it having other script-visible effects. > > The particular API above makes it easy for calls to be mismatched in subtle > ways, which would be hard to debug. I'd recommend doing this with an > interface: > > delay = document.delayCompletion(); > ... > delay.finished(); > > That way, you can simply call finished() anywhere your process can finish, > without having to worry about calling it too many times. > > (Failing to call finished() would probably have to result in the delay > being permanent, as if you missed a call to stopDelayingLoadEvent, so it > doesn't expose GC behavior. I suppose that relying on GC here isn't as bad > as it usually is, if the effects of this are never exposed to script, but > it's still not great since it would require that GC always happen in finite > time.) > > Both of these APIs are effectively manual resource collection, though, > which makes me nervous. It's not something the platform is designed for > (hence all the difficulty with blob URLs). Something like > document.delayUntil(indexedDbTransaction) would be nicer... On Mon, 29 Apr 2013, Robert O'Callahan wrote: > > It needs to support being signalled by script. The application might, for > example, be waiting for some app-specific setup protocol over a WebSocket > to complete. On Sun, 28 Apr 2013, David Bruant wrote: > > In the Firefox bug, roc suggested: > > > let the app specify <html loading>, and remove the attribute when done. > > [...] use a mutation listener to detect its removal. > > This is delightful; my new favorite idea on the topic. We don't need anything > more. On Mon, 29 Apr 2013, Aaron Boodman wrote: > > I think that there would be many uses for a mechanism that allows > developers to take part in letting the UA known when it is "ready". For > example, we would use then when analyzing extension code server-side. > Another example would be systems that take screenshots of web pages for use > in browser start pages, or search results. On Mon, 6 May 2013, James Burke wrote: > > Not using document load as the API target means also adding a > mechanism for a script that does want to wait for this new state to > detect if that state is in play. For the paired JS API, it implies > providing something like a document.appReadyState if the new event is > tied to some name like "appload". For the html attribute approach, > detecting the attribute is probably enough. This was a big thread, I've only quoted a tiny subset of comments above. The full thread is at: http://goo.gl/zjYcqh#msg110 http://goo.gl/ra5sXV#msg55 94705 1 ian 2013-10-14 20:46:48 +0000 On Mon, 13 May 2013, Kyle Simpson wrote: > > Increasingly, sites are doing client-side rendering at page load time, > which is breaking the (useful) functionality of being able to have a > #hash on a URL that auto-scrolls the page to make some element visible > after page-load. > > A perfect example of this problem is that most #hash URLs (as far as > scrolling) are broken on gist.github and github when viewed in recent > Firefox. > > https://gist.github.com/getify/5558974 > > I am proposing that the browser throw a JS event right before it's about > to try an auto-scroll to an element with the #id of the #hash in the URL > (during a page's initial loading), called for instance "autoscroll". The > purpose of this event is to simplify how a web app can detect and > respond to a URL having a #hash on it that would normally create a > scrolling behavior, even if the element isn't yet rendered for the > window to scroll to. That gist shows how you could listen for the event, > and store for later use which target-ID was going to be scrolled to, and > manually scroll to it at a later time. > > If you have an app that does client-side rendering where it can break > auto-scrolling, but you want it to work properly, you can of course > manually inspect the URL for a #hash at any point, but it's a bit > awkward, especially if you are already relying entirely on event-driven > architecture in the app, and you want to just detect and respond to > events. This "autoscroll" event will normalize that handling. > > Notice the polyfill code in the above gist shows that you can obviously > detect it yourself, but it's awkward, and would be nice if it were just > built-in. > > Additionally, having it be a built-in event would allow an app to > prevent the browser from doing unwanted auto-scrolling in a very simple > and natural way, by just trapping the event and calling > `preventDefault()`. Currently, there's not really a clean way to > accomplish that, if you needed to. 94708 2 ian 2013-10-14 21:11:25 +0000 Further feedback from the thread that started with the e-mail in comment 1: http://goo.gl/rhjEI8#msg87 Note that that thread actually requested a different feature, but the behaviour requested in the first quote in comment 0 of this bug would also solve it. 109144 3 ian 2014-07-21 20:51:27 +0000 This could also be addressed by hooking into a dependency system, just have the browser expose the "page is ready" state as something you can block... 128754 4 annevk 2017-07-21 11:00:27 +0000 If this is still desired, please file a new issue at https://github.com/whatwg/html/issues/new.