Occasional flash of white when showing default window screenshot

RESOLVED INVALID

Status

Firefox OS
Gaia::System
RESOLVED INVALID
6 years ago
5 years ago

People

(Reporter: cjones, Assigned: timdream)

Tracking

({polish})

unspecified
ARM
Gonk (Firefox OS)
polish

Firefox Tracking Flags

(blocking-basecamp:-)

Details

(Whiteboard: UX-P3)

This is testing with a build that includes nextpaint.

STR
 (1) Flash phone
 (2) Open app for the first time

Often there's a flash of white before the default screenshot shows.  Maybe we don't ensure that's preloaded?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #0)
> This is testing with a build that includes nextpaint.
> 
> STR
>  (1) Flash phone
>  (2) Open app for the first time
> 
> Often there's a flash of white before the default screenshot shows.  Maybe
> we don't ensure that's preloaded?

Is there a way to preload a |background-image| and not taking extra memory? If so, I would be more than happy to fix this bug.
Assignee: nobody → timdream+bugs
So the current code is basically doing

 function onAppOpen() {
   sprite.style.backgroundImage = 'default-screenshot.png'
 }

?  Hm.  If so I don't know of a way to change that to ensure the image is loaded before we change the CSS rule.  CC'ing some folks who might.

Setting backgroundImage to a blob URI might work ...
(In reply to Chris Jones [:cjones] [:warhammer] from comment #2)
> So the current code is basically doing
> 
>  function onAppOpen() {
>    sprite.style.backgroundImage = 'default-screenshot.png'
>  }
> 
> ? 

Almost, we assign to a className to the iframe where the class comes with the background-image style.

> Hm.  If so I don't know of a way to change that to ensure the image is
> loaded before we change the CSS rule.  CC'ing some folks who might.
> 
> Setting backgroundImage to a blob URI might work ...

That would require getting the blob through xhr'ing an |app://| url. If this works, yeah, we could do that (we are already getting blob from indexedDB for the non-default loading images, most of the code can be reused.)
> Setting backgroundImage to a blob URI might work ...

I don't think that would make a difference.  It might, but I don't think so.

A better bet would be to have an offscreen (not display:none) <img> tag with the screenshot as its src.  That may cause it to be decoded.  I don't know how much memory it will waste, though, and our memory reporters in this area are not good.  If you strictly limit the lifetime of this <img>, it might be OK.

Make sure that the <img> is inside a mozbrowser that's setVisible(true).  If you're doing this in the system app, I think you're OK in that respect.
Whiteboard: UX-P? → UX-P3
blocking-basecamp: ? → -
We did such a great job knocking out UX bugs in Berlin that this is now pretty close to #1 on my list of UX papercuts.  Would love to see someone who doesn't own any blockers sneak in a fix for this.
After v1.0 we have stop using screenshots or and opt for icons as the first cold launch screen.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.