I think an API like: window.navigator.addBusyTask(promise);
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 <ro...@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@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
