Allow custom "loading" image in manifest

NEW
Unassigned

Status

Core Graveyard
DOM: Apps
6 years ago
6 months ago

People

(Reporter: ianbicking, Unassigned)

Tracking

18 Branch

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
When an app is starting up, during initialization the app's icon is displayed.  Later the app is opened, but may not be fully initialized (e.g., ready to use).  This can lead to two apparent initialization states.  Also the app icon is not necessarily the prettiest or most appropriate indicator during the first stage of initialization.

I would like to propose a new (optional) manifest key: "initialization_images" – like icons, multiple resolutions would be allowed.  This would point to an image to use during the load process.  This would allow the app to use the identical image during its second phase of initialization, or to create an image that simulates the ultimate functional screen.

This would look like:

{...
 "initialization_images": {
   "1024x768": "/init-1024.png",
   "300x200": "init-300.png"
 },
 "initialization_background_color": "#999"
}

The user agent would attempt to select the best resolution for the screen, and would preserve the aspect ratio.  The image would be letterboxed, if necessary, with "initialization_background_color" (if not given, background would be at the user agent's discretion).  A developer could also give initialization_background_color alone, and the icon would be used with that background.

Questions:
- Should we allow for a background tiling image in addition to/instead of a flat initialization_background_color?
- Presumably we'd still have some kind of throbber to indicate the app is loading, but it would be displayed in a fairly arbitrary location over the image, and may not be easy to replicate in the second initialization screen.
- I believe we need to keep this fairly simple so that the image can be shown as soon as the app is started, which is why we'd stick to a simple image.  Is something like SVG possible?  Images aren't very adaptive (besides resolution selection), meaning that it will be hard to create a realistic image, or one that fits well.  I don't believe we can offer the application any runtime until after this initialization is completed, so the application can't do anything adaptive on its own.
- Should we allow the image to be stretched, or the aspect ratio to be specified?
- Will it be possible for the application developer to create a seamless transition from the image to their own loading screen?  If not, do we want to allow the developer to keep that image up until the application is fully loaded and initialized?
- We should consider how the image should be oriented.

See also:
https://groups.google.com/d/topic/mozilla.dev.webapps/dKAqWAuJ90c/discussion
https://groups.google.com/d/topic/mozilla.dev.webapps/ZxRI7E34Dw4/discussion

Comment 1

6 years ago
I don't like this approach as it depends on images which have fixed
aspect-ratio and fixed resolution. The apps that I develop, however, are
ideally resolution and aspect-ratio agnostic. Also, this would lead
to inconsistent load screens: One app does it this way, the other way
that way.

Alternative proposal:

https://bugzilla.mozilla.org/show_bug.cgi?id=805889
Component: Web Apps → DOM: Apps
Product: Firefox → Core
This isn't a core dom apps issue - this is a bug with a client using the DOM: Apps API. For example, if this was B2G, this would be a bug in Gaia, not DOM: Apps, as Gaia does the work to determine a custom splashscreen, not gecko. Back over to Firefox --> Webapp Runtime.
Component: DOM: Apps → Webapp Runtime
Product: Core → Firefox
(In reply to Jason Smith [:jsmith] from comment #2)
> This isn't a core dom apps issue - this is a bug with a client using the
> DOM: Apps API. For example, if this was B2G, this would be a bug in Gaia,
> not DOM: Apps, as Gaia does the work to determine a custom splashscreen, not
> gecko. Back over to Firefox --> Webapp Runtime.

Jason: Ian specifically proposed "a new (optional) manifest key", and manifest changes are API changes, not runtime-specific changes.

We might decide to address the underlying issue with a runtime-specific change instead of a manifest change (just as B2G and Android do), but in that case I would wontfix this bug and file a new one to track that runtime-specific change.

Thus this is properly a DOM: Apps bug, and I have cc:ed tchoma, who can help figure out whether or not we want to do this.
Component: Webapp Runtime → DOM: Apps
Product: Firefox → Core
(In reply to Myk Melez [:myk] [@mykmelez] from comment #3)
> (In reply to Jason Smith [:jsmith] from comment #2)
> > This isn't a core dom apps issue - this is a bug with a client using the
> > DOM: Apps API. For example, if this was B2G, this would be a bug in Gaia,
> > not DOM: Apps, as Gaia does the work to determine a custom splashscreen, not
> > gecko. Back over to Firefox --> Webapp Runtime.
> 
> Jason: Ian specifically proposed "a new (optional) manifest key", and
> manifest changes are API changes, not runtime-specific changes.

That's incorrect. We have specific implementation decisions that are controlled at the runtime level via the manifest. Please see the many pieces of manifest parsing that happens in Gaia that demonstrates this in multiple fashions, such as bug 895826.

> 
> We might decide to address the underlying issue with a runtime-specific
> change instead of a manifest change (just as B2G and Android do), but in
> that case I would wontfix this bug and file a new one to track that
> runtime-specific change.

There is a runtime-specific change for Gaia similar to this (I need to dig the bug up though), so this bug would target desktop then.

> 
> Thus this is properly a DOM: Apps bug, and I have cc:ed tchoma, who can help
> figure out whether or not we want to do this.

That decision would be up to Mounir, not tchoma, as he owns the W3C spec.

Back over to desktop web apps again - this is a runtime bug.

Updated

5 years ago
Component: DOM: Apps → Webapp Runtime
Product: Core → Firefox

Comment 5

5 years ago
Would be interested in hearing Mounir's opinion. Also I think whether we decide to do this has some dependancy on whether we sort out Bug 886484 which would allow for user controllable splash screens, rather than just showing the icon with a spinner initially. I know marcosc did some experimenting with splash screens, cc'ing him as well for further discussion.
(In reply to Travis Choma from comment #5)
> Would be interested in hearing Mounir's opinion. Also I think whether we
> decide to do this has some dependancy on whether we sort out Bug 886484
> which would allow for user controllable splash screens, rather than just
> showing the icon with a spinner initially. I know marcosc did some
> experimenting with splash screens, cc'ing him as well for further discussion.

Ah, you found the bug I was looking for. That's why I was arguing this is a runtime bug - bug 886484 is the Gaia equivalent of this bug.
In my opinion we should proceed with standards and not adding runtime specific manifest fields. I see we can't wait w3c standardization because Firefox OS needs to grow as fast as possible, but at least we should have a consistent behavior between our runtimes.
(In reply to Marco Castelluccio [:marco] from comment #7)
> In my opinion we should proceed with standards and not adding runtime
> specific manifest fields. I see we can't wait w3c standardization because
> Firefox OS needs to grow as fast as possible, but at least we should have a
> consistent behavior between our runtimes.

We should do that, but that's not the direction we're going right now. Gaia has loads of runtime-specific manifest properties, as does FxAndroid. There are cases where that might make sense, such as the orientation property, which makes sense only in a mobile environment.
Jason and I discussed this further over IRC and ended up agreeing that the Core :: DOM : Apps component is the best one for a bug like this, which proposes a generic change to the manifest specification that would enable the various runtimes to implement splash screens (but which isn't about implementing the screens on any particular runtime).

We also agreed that a bug doesn't seem like the best way to propose manifest specification changes, and it would be better to discuss such changes in a forum before filing mozApps API and/or runtime-specific bugs to implement them.

But we'll let Travis, Mounir, and other API drivers decide how best to respond to the proposal.
Component: Webapp Runtime → DOM: Apps
Product: Firefox → Core
AFAIK, we have decided to move the splash screen responsibilities to the app fully. This feature should not be needed if we happen to apply this scenario.
(Reporter)

Comment 11

5 years ago
On Android (and maybe desktop?) the runtime can take a noticeable amount of time to initialize, during which the app isn't loaded and wouldn't be able to display any splash screen.  I think this feature might still be useful there.
Can the runtime have a neutral way to show to the user that the application is loading?
For example, on MacOS, the application icon is bouncing and when the app is actually loaded, whatever the app does as a splash screen, it will not look overly weird.

Comment 13

5 years ago
The bouncing icon would work for desktop, but the real challenge is what to do about Android if it really is that slow. The advantage of having a static splash that the user can specify to display while the app loads is that you need not worry about slow load times. On the other hand if Android is improving perhaps it's not a problem. Does anyone have current timings for typical load times on Android?
(In reply to Travis Choma from comment #13)
> The bouncing icon would work for desktop, but the real challenge is what to
> do about Android if it really is that slow. The advantage of having a static
> splash that the user can specify to display while the app loads is that you
> need not worry about slow load times. On the other hand if Android is
> improving perhaps it's not a problem. Does anyone have current timings for
> typical load times on Android?

I think we could try to solve that we a good generic loading screen/animation before showing the application splash screen but this is a question for UX I believe.

Updated

6 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.