Busy indicator API

Jonas Sicking jonas at sicking.cc
Mon Jul 6 17:35:11 UTC 2015

I think an API like:


would be great. The API can be called any time and any number of
times. The API would run the spinner until all provided promises are
resolved. So if it's called twice with different promises, the spinner
doesn't stop when one of the promises are resolved, but rather when
the last promise is resolved.

/ Jonas

On Mon, Jul 6, 2015 at 2:24 AM, Robin Berjon <robin at w3.org> wrote:
> 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 counter).
> 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
> _______________________________________________
> dev-platform mailing list
> dev-platform at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

More information about the firefox-dev mailing list