Closed
Bug 821943
Opened 12 years ago
Closed 11 years ago
Occasional flash of white when showing default window screenshot
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
Tracking
(blocking-basecamp:-)
RESOLVED
INVALID
blocking-basecamp | - |
People
(Reporter: cjones, Assigned: timdream)
Details
(Keywords: polish, 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?
Assignee | ||
Comment 1•12 years ago
|
||
(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
Reporter | ||
Comment 2•12 years ago
|
||
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 ...
Assignee | ||
Comment 3•12 years ago
|
||
(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.)
Comment 4•12 years ago
|
||
> 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.
Updated•12 years ago
|
Whiteboard: UX-P? → UX-P3
Updated•12 years ago
|
blocking-basecamp: ? → -
Reporter | ||
Comment 5•11 years ago
|
||
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.
Assignee | ||
Comment 6•11 years ago
|
||
After v1.0 we have stop using screenshots or and opt for icons as the first cold launch screen.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•