This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23508 - 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)
Summary: Browsers want to know when a page's scripts have finished 'loading', even if ...
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other All
: P3 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-14 20:44 UTC by Ian 'Hixie' Hickson
Modified: 2017-07-21 11:00 UTC (History)
3 users (show)

See Also:

Attachments

Description Ian 'Hixie' Hickson 2013-10-14 20:44:23 UTC 
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
Comment 1 Ian 'Hixie' Hickson 2013-10-14 20:46:48 UTC 
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.
Comment 2 Ian 'Hixie' Hickson 2013-10-14 21:11:25 UTC 
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.
Comment 3 Ian 'Hixie' Hickson 2014-07-21 20:51:27 UTC 
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...
Comment 4 Anne 2017-07-21 11:00:27 UTC 
If this is still desired, please file a new issue at https://github.com/whatwg/html/issues/new.