Closed
Bug 1062114
Opened 10 years ago
Closed 10 years ago
[dolphin][flame] Gallery directly exit when user launch gallery immediately after sending it to background when quickscan is in process
Categories
(Firefox OS Graveyard :: Gaia::Gallery, defect)
Tracking
(blocking-b2g:2.1+, b2g-v2.0 affected, b2g-v2.1 verified, b2g-v2.2 verified)
People
(Reporter: angelc04, Assigned: djf)
References
()
Details
(Whiteboard: [sprd347506])
Attachments
(3 files)
Steps to reproduce
-----------------------------------------------------------------------------
0. Insert a SD card with some pictures
1. Start device
2. Launch Gallery
gallery will start quickscan to scan file system. A scanning overlay will appear.
3. Tap on Home button to send Gallery to background before quickscan finish.
4. Immediately tap on Gallery icon again
--> You will see Gallery exit directly.
This is because: in the process of quickscan, the cpu is busy and the system was unable to execute setTimeout(function() { window.close(); }, 500); on time. So after tap on home button, Gallery was still in background for about 3~4s. And user will see gallery exit when user immediately launch Gallery after sending to background.
Reporter | ||
Updated•10 years ago
|
Whiteboard: [sprd347506]
Reporter | ||
Comment 1•10 years ago
|
||
This is reproducible on both dolphin and flame.
Reporter | ||
Comment 2•10 years ago
|
||
Attached is adb logcat, test starts: 09-03 16:52:24.256
Test build
-------------------------------------------------------------------------------
Gaia 2ee5b00bfbb8a67a967094804390b4afce8ecf54
Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/e489344cc279
BuildID 20140902160206
Version 30.0
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014
Comment 3•10 years ago
|
||
Lock screen when gallery is scanning,and light the screen again,gallery application will exit certainly.
From the behavior point(UI), it would be a problem, besides ,Android and IOS mobile phone will not lead applications to exit completely when lock secreen.
Comment 4•10 years ago
|
||
This issue REPROES on Flame 2.1 KK [b2g-34] and Flame 2.2 Master KK.
** may have empty gallery **
STR:
1. Open 'Camera' app.
2. Take 10+ images.
3. Restart phone.
4. Open 'Gallery'.
5. Observe Quickscan processing (UI across top border updating).
6. Tap home to return to homescreen while Quickscan is processing.
7. Quickly reopen Gallery.
Results: After closing gallery during Quickscan and quickly re-opening, observe Gallery force close shortly afterwards.
** Additional Notes **
This issue is not limited to SD card as was observed in comment 1; video and logcat added during this comment was performed with images contained within internal memory.
****************************************************************
Environmental Variables
------------------------
Device: Flame 2.1
BuildID: 20141015001201
Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3
Gecko: 4853208cb48a
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Device: Flame 2.2 Master
BuildID: 20141015040201
Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6
Gecko: 62f0b771583c
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 36.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
video- http://youtu.be/I934evDddeg
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 5•10 years ago
|
||
Updated•10 years ago
|
Comment 6•10 years ago
|
||
QAWanted to confirm 2.0 is affected (dolphin on 1.4 was already tested).
No-Jun can you weigh in here for blocking nomination decision?
Note that this issue will also occur on Flame 2.1 when the user holds the home button while the quick scan is in progress.
Comment 8•10 years ago
|
||
[Blocking Requested - why for this release]:
If a user has many images in the SD card (which is very likely), and presses the home button to interrupt this process, then this will make the user unable to use the app.
blocking-b2g: --- → 2.1?
Flags: needinfo?(npark)
Comment 9•10 years ago
|
||
Flame 2.0 KK IS affected as well. Gallery app promptly exits out if the STR is done.
2/3 attempts
Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141016063743
Gaia: c6c6116ca225c2c934220ae6867e5a3256d65e00
Gecko: e2ad5b580ebc
Version: 32.0 (2.0)
Firmware Version: L1TC10011800
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0:
--- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: croesch
Comment 10•10 years ago
|
||
David,
Can you look into this please?
Thanks
Hema
Assignee: nobody → dflanagan
Assignee | ||
Comment 11•10 years ago
|
||
Punam,
This bug is a result of the patch from bug 1039943. Since you reviewed that one, I'm asking you to review this one as well.
If I didn't want to be sure we had a nice 'exiting' message in the logcat, we could just skip the setTimeout() and exit immediately and we wouldn't have this bug. But because the intentional exit seems like a bug, I want to be sure we keep that message in the logcat so it is easy to identify this as intentional in future logcats.
Attachment #8506497 -
Flags: review?(pdahiya)
Assignee | ||
Comment 12•10 years ago
|
||
Peipei,
Thank you for the analysis you did when filing this bug. You identified the cause exactly which made it very easy to fix.
Assignee | ||
Comment 13•10 years ago
|
||
(In reply to jingchao.wang from comment #3)
> Lock screen when gallery is scanning,and light the screen again,gallery
> application will exit certainly.
>
> From the behavior point(UI), it would be a problem, besides ,Android and IOS
> mobile phone will not lead applications to exit completely when lock secreen.
Jingchao,
The attached patch fixes the originally reported bug which was about the homescreen. It does not fix what you describe: that scanning stops when the phone sleeps. I agree with you that it should probably not stop scanning when we sleep the phone. But I don't think that the Gallery app can tell the difference. So I think that the only way to keep the app scanning in the background while the phone is locked is to revert the patch from bug 1039943. Please file a different bug if you want to keep investigating this scanning while locked case.
Assignee | ||
Comment 14•10 years ago
|
||
Following up on the comment above, I've confirmed that the visibilitychangeevent we get does not have a detail field that tells us whether we've gone to the homescreen or to the lockscreen. Maybe with the right permissions we could listen to see if the screen has been turned off. But that is a pretty major change and deserves a bug of its own to discuss.
Comment 15•10 years ago
|
||
Comment on attachment 8506497 [details] [review]
link to patch on github
Patch looks good and has r+. Tested by launching gallery from home screen and via pick activity through messaging app and it works for both flows. Thanks!
Attachment #8506497 -
Flags: review?(pdahiya) → review+
Updated•10 years ago
|
blocking-b2g: 2.1? → 2.1+
Assignee | ||
Comment 16•10 years ago
|
||
Assignee | ||
Comment 17•10 years ago
|
||
Comment on attachment 8506497 [details] [review]
link to patch on github
[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): 1039943
[User impact] if declined: leaving gallery and going quickly back it will sometimes cause it to open and quickly exit, especially when the phone is under heavy load
[Testing completed]: yes, locally
[Risk to taking this patch] (and alternatives if risky): very low risk. The bug that caused the regression was a performance improvement to make the gallery exit instead of scanning in the background. This patch just makes it not exit in all cases. So the code only runs if the app is about to kill itself.
[String changes made]: none
Attachment #8506497 -
Flags: approval-gaia-v2.1?(fabrice)
Comment 18•10 years ago
|
||
Issue is verified fixed in Flame 2.2 (Full Flash, nightly).
Actual Results: Gallery app does not crash when user inserts a SD card preloaded with images into the device while it is on, then opening Gallery app while images are still loading.
Device: Flame Master
Build ID: 20141021040206
Gaia: 457a54fc3200b80e4f5e1cd3acaa062309230732
Gecko: 29fbfc1b31aa
Version: 36.0a1 (Master)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Adding 'verifyme' tag until 2.1 patch has landed.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Updated•10 years ago
|
Attachment #8506497 -
Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
Comment 19•10 years ago
|
||
Target Milestone: --- → 2.1 S7 (24Oct)
Comment 20•10 years ago
|
||
This issue is verified fixed on Flame 2.1.
Result: The Gallery app does not close when re-opened during loading status.
Flame 2.1
Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141024001204
Gaia: 0f76e0baac733cca56d0140e954c5f446ebc061f
Gecko: 7d78ff7d25b6
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
=====================================================
This bug still reproduces on 2.0. Leaving verifyme keyword.
Flame 2.0
Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141024000201
Gaia: 86d83f4b4111ca45ebc92ca779348cc966f43cff
Gecko: f8432250efb7
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Comment 21•10 years ago
|
||
Removing verifyme keyword since this bug does not block 2.0.
Keywords: verifyme
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•