Busy indicator API

Robin Berjon robin at w3.org
Mon Jul 6 09:24:35 UTC 2015

On 06/07/2015 03:22 , Mike Connor wrote:
> Does it need to be an API, or would dispatching an event be sufficient?
> Something like "busy" and "idle" events would be easy to send from JS, and
> UAs would be free to honour or ignore based on context.

On the face of it it's certainly useful: writing your own busy indicator 
is one of the first things you get to do when producing a Web 
application. If we can get this built-in, it's a win.

I'm slightly worried about the possibility of actually getting it right, 
though. It's not uncommon for Web app above a certain level of 
complexity to be doing more than one thing at once. If I'm conducting 
two operations, and have therefore dispatched two "busy" events (or 
whatever API equivalent) I would probably expect there to have to be two 
"idle" events before the UI state returns to idle (i.e. there's a busy 

This could possibly seem acceptable, but what happens when the app 
transitions to a different internal page? Today wiping the DOM is enough 
to remove the spinners, so no one bothers maintaining state for this, 
but with the API you'd have to. History.pushState() could wipe the busy 
flag, but that might be the wrong thing to do if a busy part of your UI 
stays there.

Also: what does the busy indicator do in fullscreen?

I'm not trying to shoot this down, just pointing at potential pitfalls 
to avoid adding a feature that will just largely get ignored except 
perhaps in the simplest cases.

Robin Berjon - http://berjon.com/ - @robinberjon

More information about the firefox-dev mailing list