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?

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.

(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

(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.

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.

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?

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

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.

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.

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.