Closed Bug 826620 Opened 11 years ago Closed 11 years ago

blank gray thumbnails in gallery

Categories

(Firefox OS Graveyard :: General, defect, P3)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:-, b2g18+)

RESOLVED WORKSFORME
B2G C4 (2jan on)
blocking-basecamp -
Tracking Status
b2g18 + ---

People

(Reporter: djf, Unassigned)

Details

(Keywords: regression)

Attachments

(1 file)

If I edit an image in the Gallery app and include a border or cropping, then when I save the image, I'll see a blank gray thumbnail until I scroll.  (This is a symptom of a problem with shared/js/visibility_monitor.js). If I just apply an effect (bw, sepia, etc.) then the edited thumbnail appears normally.

I don't know what the difference is.  Is there a timing issue? Could the thumbnail blob not be ready yet when the mutation event tells visibility_monitor that something has changed?
I can't reproduce this, but recently, after rebooting and starting gallery, I saw two blank gray thumbnails. Both of them were for edited images and both were in the first line at the top.  Is there a timing issue here? Do edited images not get a thumbnail saved? Are they taking longer because the app has to read the entire image into memory the first time?
Assignee: nobody → dflanagan
I can see gray thumbnails more relably when using activities to switch from camera to an already-running gallery.
Now I see these when I'm in fullscreen mode, sleep the phone and then wake an unlock it.

Something has changed with Gaia and it is causing a gallery regression in my thumbnail visibility monitor utility.  I'm going to nominate this so I can get it fixed.
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
Priority: -- → P3
Target Milestone: --- → B2G C4 (2jan on)
Retriaged.
We would take a patch on this but it's not a blocker for V1.
blocking-basecamp: + → -
tracking-b2g18: --- → +
Earlier, I was finding this very easy to reproduce. Now it is hard to reproduce: I've only seen gray squares twice in 10 minutes or more of trying.  (By sleeping and reawakening the phone).
I can occasionally reproduce by bringing up the task switcher and selecting the gallery.  I'm doing this with lots of apps running, but don't know if that actually makes a difference.

This is beginning to feel like a gecko bug.
Using the membuster app doesn't seem to increase the occurance of this bug. But I think maybe I see it more often when I've recently launched other apps.  So maybe it is a timing issue that occurs more frequently when the CPU is busy.  Maybe I can try duplicating it by firing off a worker thread in gallery to artificially add load.
Okay, STR that are working for me now:

1) reboot phone
2) launch gallery
3) tap on a thumbnail to display a photo fullscreen
4) tap power button to sleep the phone
5) tap power button to wake the phone
6) unlock phone
7) see gray thumbnails

If I can still use those STR in the morning, I'll try tracking this bug down.  Turning the screen off has recently caused the app to exit fullscreen mode and go back to the list of thumbnails. I'm guessing that has something to do with this bug.

I've written a CPU loader app to artificially add load, but it doesn't seem to make this any easier to reproduce.
I wonder if this has anything to do with the throttle animation stuff (in bug 822721, for example) If this goes away tomorrow in a build that incorporates fix to 822721, I'll be happy.
On further investigation this isn't a gaia bug.  With the STR in comment 8, I can usually see gray thumbnails.  Touching the screen and doing a minute scroll (or apparently even a tap with no scroll) makes the thumbnails reappear instantly.  But I've instrumented my shared/js/visibility_monitor.js code, and it isn't doing anything to those thumbnails. They're reappearing on their own.

So this is some kind of gecko graphics layer issue where certain elements aren't being repainted sort of at random.  

Although the STR involve fullscreen, I have also seen these gray squares in other circumstances, like transitioning from camera to an already-running gallery.  Easier to reproduce once the gray squares are already appearing.

I'm going to cc cjones on this to get it on his radar, and then flash a newer gecko to see if it has gone away with recent fixes.
I can still reproduce this with the latest nightly build: 20130109070203
I've attached a screenshot of what I mean about "gray squares"  Each square is supposed to display a gallery thumbnail via a CSS background-image property.

Touching the screen will make the images appear again.
I'll try building my own gecko with the latest b2g18 bits. The fix for 822721 looks like it was backed out when this nightly build was made.
Setting the qawanted flag. Can anyone else reproduce this using the steps in comment 8?  And if you can do that, can you confirm that you can also see the bug if you switch back and forth between the gallery and the camera?
Keywords: qawanted
Adding the regression keyword and nominating this again.  A gecko bug that randomly causes parts of the screen not to be redrawn seems pretty scary to me.
blocking-basecamp: - → ?
Keywords: regression
Moving this to the BootToGecko/General component and unassigning myself, since it is a gecko bug that I'm unqualified to work on.
Assignee: dflanagan → nobody
Component: Gaia::Gallery → General
OS: Mac OS X → Gonk (Firefox OS)
QA Contact: jhammink
Hardware: x86 → ARM
I've rebuilt gecko from the latest b2g18 and can still reproduce this.

Chris, could this be a throttled animations thing?
Restoring jhammink as contact (after talking with him) for repro per comment 14
QA Contact: jhammink
Tried STR on comment 8 on 1/4 nightly and could not repro.

Tried same on 1/9 nightly with different reboot methods (does this make a difference?) and <drumroll, please...> 

1.) with reboot using reboot menu: 

on initial load of gallery - saw the grey thumbnails only briefly (< 2 seconds) while photos were loading.

when switching back from camera to gallery - saw grey thumbnails only briefly (< 2 seconds) while photos were loading.

2.) with reboot using adb: 

on initial load of gallery - saw the grey thumbnails only briefly (< 2 seconds) while photos were loading.

but...

after cropping the photo and switching back to gallery view  - the grey thumbnails stay until I try to pan - when they disappear.  

So, looks like I am seeing the issue.  Do you need any more information, David?
John,

Thanks for confirming.  I doubt that reboot methods make any difference. I just added that to show that I was reproducing from a clean slate, without other stuff running.

From your description it sounds like you saw the gray squares after cropping an image.  Did the steps in comment 8 (go to fullscreen image, then sleep the phone) not cause the issue for you?

If you only see the gray squares briefly, that's just the images loading, and is expected.  Its only when the gray squares just sit there until you touch or pan that we've got a problem.
Hi David,

Steps in Comment 8 in every case only showed gray squares briefly.   

I am only able to get the gray squares to sit there until I touch or pan - after editing (in my case, cropping) an image.
Milan, can the graphics team help here?

Triage decision:  while this is unfortunate, panning to work around is not too bad and editing images on the phone is probably not common enough of a case to justify blocking.  We'd love to see a fix, though.
Assignee: nobody → milan
blocking-basecamp: ? → -
Andrew,

Note that for me, this isn't just about editing anymore. See the steps to reproduce in comment 8. For me, this occurs every time I view a photo and then sleep the phone, and seems like a symptom of a serious gecko bug.  John couldn't reproduce with those steps in comment 8, but I still can.

I'm thinking about abandoning fullscreen mode for the gallery, and that might avoid this problem.
I can still reproduce just by sleeping and waking the phone, with the most recent OTA update.  

Mike: that bug doesn't seem related to me...

I'll see if I can work around it by getting rid of fullscreen mode.
djf: I don't know if it's related, only that I was seeing very-grey images as well, and jst mentioned this bug, so I thought I'd cross-ref them in case there was a common cause.
This is harder to reproduce now, but I do still see it sometimes.  If I launch the gallery, play a video, then switch to the camera and back, then sleep the phone, wake it up and unlock the lockscreen, I will sometimes see gray squares.

I was really worried about this bug a few days ago, and really thought it should block, but it is significantly harder to reproduce now, so I'm not as concerned.

I'm going to edit the title to remove "after editing image" because that's not how I reproduce this bug anymore.
Summary: blank gray thumbnail after editing image → blank gray thumbnails in gallery
I still see this in : 13-Dec-2012 build.
I also have other issues when looking at that build beyond the grey squares.

Would it prove useful to go before that?  I'm not sure if this is truly a regression?  Was there a fix for this at some point?
Keywords: qawanted
Naoki,

One possible cause of gray squares is a bug in my gaia shared/js/visibilty_monitor.js code.  When I first saw that, I assumed it was a regression in that code. But on further testing it turned out that this is not a gaia bug at all, but a gecko bug.

I've assumed that it is a regression in gecko, but I don't know that for sure.

My hypothesis was that it was somehow related to bug 826620, but that landed on 14-Dec, so if you're seeing the same bug, then that isn't it.

Were you reproducing it using the steps in comment 8, or the steps in the initial bug description?  If you're seeing a gaia bug, then you'll have to scroll the thumbnails to get the gray to go away.  If you're seeing a gecko bug, then just touching the screen (like the camera button) will make them go away.
Wait, that's this bug. I meant bug 780692 above.
Is this still reproducible?  (my unagi is out of commission ATM so I can't try myself)
David, please reopen if you still see this.
Assignee: milan → nobody
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: