Closed Bug 1168168 Opened 9 years ago Closed 9 years ago

Flame: zooming in in the gallery app sometimes disappears the image view momentarily

Categories

(Firefox OS Graveyard :: Gaia::Gallery, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.2 unaffected, b2g-master affected)

RESOLVED DUPLICATE of bug 1140619
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- affected

People

(Reporter: njpark, Assigned: djf)

References

Details

(Keywords: regression)

STR:
Open gallery app, open a picture
Pinch zoom in to maximum, zoom out, then zoom in again to maximum
combine with orientation change

Actual:
While zooming in, the screen turns black temporarily, then it displays the zoomed in image

Expected:
There is no screen blackout

Frequency: 2/5

Version Info:
Build ID               20150525010204
Gaia Revision          5bcc08a732163087999251b523e3643db397412c
Gaia Date              2015-05-24 14:44:40
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/b6623a27fa64
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150525.044252
Firmware Date          Mon May 25 04:43:03 EDT 2015
Bootloader             L1TC000118D0
:djf, do you think it could be a gecko issue?
Flags: needinfo?(dflanagan)
I cannot reproduce this bug. Tried ~50 times with images taken by Flame and no reproduction. Reporter, could you film a video of bug reproducing?

Tested on:
Device: Flame (319/512MB, full flashed, KK)
BuildID: 20150526010203
Gaia: 7cd4130d4f988562a77d126860408ada65bb95ef
Gecko: 43f2f0c506ea
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Leaving qawanted for others to attempt.

Taking off windowwanted tag for now until we can reproduce the bug and branch check. The reproduction rate will also have to be high enough to attempt a window.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(npark)
Flags: needinfo?(ktucker)
(In reply to Pi Wei Cheng [:piwei] from comment #2)
> I cannot reproduce this bug. Tried ~50 times with images taken by Flame and
> no reproduction. Reporter, could you film a video of bug reproducing?
> 
> Tested on:
> Device: Flame (319/512MB, full flashed, KK)
> BuildID: 20150526010203
> Gaia: 7cd4130d4f988562a77d126860408ada65bb95ef
> Gecko: 43f2f0c506ea
> Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
> Version: 41.0a1 (3.0 Master)
> Firmware Version: v18D-1
> User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
> 
> Leaving qawanted for others to attempt.
> 
> Taking off windowwanted tag for now until we can reproduce the bug and
> branch check. The reproduction rate will also have to be high enough to
> attempt a window.

So using the following method, I can better reproduce the issue:
- Take 5~6 pictures using flame
- Go to gallery, select the first picture
- slide to move to the next picture
- zoom in to max, then zoom out again
- slide to move to the next picture
- zoom in and zoom out.
I can repro about 50% of the time, and the video is here: https://youtu.be/C7JRPnV36cQ
Flags: needinfo?(npark) → needinfo?(pcheng)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
(In reply to No-Jun Park [:njpark] from comment #1)
> :djf, do you think it could be a gecko issue?

There have been a lot of gecko changes recently. But in response to those gecko changes, I've also make significant changes to the gaia code that is involved when you zoom in.

If this only occurs on a 319mb flame, then I think it is just a side effect of having too little image memory. The fact that it reproduces more easily if you swipe before zooming makes me suspect that it is memory-related. So if this is only something you see on low-memory devices, then I don't know if there is anything we can do about it. On the other hand, if it reproduces on devices with more memory, then it may mean that my gallery app changes in response to the new  gecko changes are not sufficient.  On master there are additional gaia changes I know I need to make (removing #moz-samplesize) in order to be as efficient as possible. If the gecko downsample-during-decode changes have landed in 3.0, then this bug is probably just that I haven't made the necessary gaia changes yet. (See bug 1166134: this may just be part of that)

If this reproduces on 2.2 and with higher memory, though, then that would be a bigger problem. Please let me know, if so.

The thing that concerns me more about your video is that around the 15 second mark it looks like when you're zooming back out on the image, the image becomes smaller than the screen and then gets big again. That seems very wrong, and it might be a completely different bug.
Flags: needinfo?(dflanagan)
Thanks for the video.

I flashed to the reported build and with the added information, I still cannot reproduce this bug. I noticed in the video that the user has the ability to make the picture go smaller than the display like shown in around 10 seconds into the video, but on my device I can't do that. Maybe there were something else that the reporter did as prerequisites in order for this bug to happen, but I can't figure that out.

Changing to steps wanted for steps.
Flags: needinfo?(pcheng)
Keywords: qawantedsteps-wanted
I just realized, this is MUCH easier to reproduce in 512 MB configuration. In 319MB config, the zoom in/out happens too slowly, and maybe that is the reason why this cannot be seen.

again, the steps are:
- After FTE
- Open camera app, take 5~6 pictures
- go to homescreen, start the gallery app
- select the first picture, swipe to next, and do pinch zoom.

djf, perhaps doing the associated gaia work for bug 1166134 might fix this I suppose?

For some reason I thought there was already a bug for image becoming smaller than screen, but I don't think there is one, I'll raise it.  This is so far only reproducible in 512MB configuration for me, and when I do it very rapidly.

Another thing I realized is that in 512MB configuration, it zooms much more than 319MB configuration.  In 512MB setting, the image zooms in about twice more than in 319MB setting. the image taken by flame is 1944x2592, but in 319MB config, it does not zoom in more than one pinch which in 512MB conifg it takes about 2 pinches to fully zoom in.  is this by design?
Flags: needinfo?(dflanagan)
See Also: → 1168873
This issue reproduces on the Flame 3.0, 

Environmental Variables:
Device: Flame 3.0 (Full Flash)(512mb)(KK)
Build ID: 20150601010203
Gaia: e6dc0f4c583407a4a52a66ce7cb11f058302a762
Gecko: f8d21278244b
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Environmental Variables:
Device: Flame 2.2
BuildID: 20150601002502
Gaia: b4582cc394e0919623263997c0cdb0b4751a1403
Gecko: 78d8b0a4303d
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Contact: ktucker
STR:

Prerequisite: Set the Flame memory to 512mb.

1. Open the gallery app.
2. Tap on a picture to view it.
3. Edge gesture to the next picture.
4. Zoom in on the picture.

Actual:
The picture will disappear as the user zooms in on it.

--------------------------

This issue reproduces on the Flame 3.0

The picture disappears as the user zooms in on it.

Environmental Variables:
Device: Flame 3.0 (Full Flash)(512mb)(KK)
Build ID: 20150601010203
Gaia: e6dc0f4c583407a4a52a66ce7cb11f058302a762
Gecko: f8d21278244b
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0


This issue does not occur on the Flame 2.2

The picture does not disappear when the user is using zoom.

Environmental Variables:
Device: Flame 2.2(Full Flash)(512mb)(KK)
BuildID: 20150601002502
Gaia: b4582cc394e0919623263997c0cdb0b4751a1403
Gecko: 78d8b0a4303d
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

I am going to find the regression window here.
Posting what I believe to be the central window. I will double check and finish this regression window tomorrow.

Mozilla Central

Last Working
Environmental Variables:
Device: Flame 2.2
BuildID: 20141031125656
Gaia: 5964f1339f37e7595aff7de7512b8529bc640b76
Gecko: a264cdd47217
Gonk: Could not pull gonk.  Did you shallow Flash?
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken
Environmental Variables:
Device: Flame 2.2
BuildID: 20141031131456
Gaia: 5964f1339f37e7595aff7de7512b8529bc640b76
Gecko: 12ac66e2c016
Gonk: Could not pull gonk.  Did you shallow Flash?
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Last Working Gaia First Broken Gecko: Issue does NOT reproduce 
Gaia: 5964f1339f37e7595aff7de7512b8529bc640b76
Gecko: a264cdd47217

First Broken Gaia Last Working Gecko: Issue DOES reproduce
Gaia: 5964f1339f37e7595aff7de7512b8529bc640b76
Gecko: 12ac66e2c016

Gecko pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a264cdd47217&tochange=12ac66e2c016
I am not 100% confident in this window since the repro rate drops significantly and there is a edge gesture bug that causes pictures to disappear if the user touches the edges. Need someone to do a gecko bisection here to be sure that this bug is indeed the cause.

Mozilla Inbound

Last Working
Device: Flame 2.2
BuildID: 20141031020755
Gaia: 8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko: 287ddaf9b9df
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken
Device: Flame 2.2
BuildID: 20141031021654
Gaia: 8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko: 52d9cbc1d78e
Version: 36.0a1 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce 
Gaia: 8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko: 52d9cbc1d78e

First Broken Gaia Last Working Gecko: Issue DOES NOT reproduce
Gaia: 8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko: 287ddaf9b9df

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=287ddaf9b9df&tochange=52d9cbc1d78e

This looks to be caused by bug 1073252

-----------------

Robert, can you take a look at this please? This might have been caused by the work done for bug 1073252.
Blocks: 1073252
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(roc)
Clearing the needinfo request for Roc since it is almost certainly an imagelib-related issue and Seth would be the right one to ask about that.

In any case, I suspect that this will go away when I've had the time to adapt the gaia code to the gecko downscale-on-decode changes. Right now, gaia is still using #-moz-samplesize, and I believe that that may be causing us to decode images twice instead of once.

No-Jun: the 512mb vs 319mb differences you are seeing are probably by design. On low-memory (< 512mb) devices we limit the maximum size that images are decoded at.

I suspect that this is a dupe of 1140619.  No-Jun: since you reported this would you decide whether to resolve it as a dupe? In the meantime, I'll take it in case this is a different bug.
Assignee: nobody → dflanagan
Flags: needinfo?(roc)
Flags: needinfo?(npark)
Flags: needinfo?(dflanagan)
I think it's very likely that this is the dup of Bug 1140619.  Was also wondering that there wasn't too much activity on 1140619 (now it's 3.0+) too.  

I'll mark this as a dupe. and add a verifyme flag on Bug 1140619 to check whether its fix resolves this issue as well.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(npark)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.