Closed Bug 889728 Opened 7 years ago Closed 6 years ago
[Gallery] Grey screen observed for a while , When an image is opened in fullscreen and zoomed in
1. Title: Grey screen observed when user tries to zoom an image 2. Precondition: 3. Tester's Action: 1. Capture a couple of images from camera 2. Close camera. 3. Open Gallery , open any one image in fullscreen 4. When image is in image screen , press the power button to lock 5. unlock the device using power button 6. Fullscreen image is shown, now try to Zoom IN the image 7. The screen becomes Grey before the zoomed image is shown. 4. Detailed Symptom (ENG.): Grey screen is shown fro a while in gallery , when user tries to zoom an image 5. Expected : When user zooms an image, gallery should show the zoomed image (No grey screen should be displayed) 6. Reproducibility: Y 1)Frequency Rate : 100% 7.Gaia Master/v1-train : Reproduced 8.Gaia Revision: 0a8b1d7c70c5ec2b48e52c2cd7e463f47fa0b9cb
Please find the analysis for this issue below: In Leo the width*height of the image from camera is 1920*2560 and in Master/v1train the width*height is 1200*1600. This issue is reproduciable in mater/v1train/Leo with larger images. Same issue will not occur if the image width*height is 1200*1600 in mater/v1train/Leo. Similar issue related to width*height found in BUG-888882
Just for memo. Mark found a simple STR to have the same symptom. Please help to check if this is the same issue: 1. use anyway to push a big picture 2. open gallery. 3. just zoom in/out multiple times without releasing your fingers The gray screen is observed. There is a bug related to above STR: bug 844245.
Yes this is the same issue.
Hi Leo, As John mentioned the ideal fix is dependent on 844245. After an image onload event occurs it still takes Gecko some time to decode and that is the cause of the grey background showing through. As for a temporary fix, perhaps a simple algorithm that updates the setTimeout timer based on image size, but again is a poor alternative. Going to mark this as dependent on 844245. Thanks, Mark
Depends on: 844245
Hi Mark, can you follow up with 844245? It seems to be a non-trivial fix for this somewhat cosmetic bug here. Leo has agreed to not block on this bug but it would help if we can provide some insights on fix estimates.
blocking-b2g: leo+ → ---
Target Milestone: 1.1 QE4 (15jul) → ---
Followed up with 844245 will update status when I receive feedback. @Wayne Not sure how feasible it is to get the following bug 841579 changes into b2g-18 as mentioned by David Flanagan. I've tested with mc and it does fix this issue.
Whiteboard: [TD-55413],[mozilla-triage] → [TD-55413],[leo-triage]
Assignee: mshiao → nobody
Severity: critical → major
Since this bug is not leo+ anymore, it is already fixed by bug 841579 at master. I mark this bug WONTFIX because it is already fixed by another bug.
You need to log in before you can comment on or make changes to this bug.