Closed Bug 1027414 Opened 10 years ago Closed 10 years ago

[Smart Collection] getting the lockscreen on the geolocation notification for vertical homescreen can return to a black screen

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S5 (4july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: nhirata, Assigned: vingtetun)

References

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

1. long tap on homescreen 2. tap add smart collections 3. uncheck the checkbox for the geolocation app permission 4. at the app permission hit the power button 5. tap the power button again 6. unlock the screen Expected: geolocation overlay Actual: black screen Gaia 83844c7679b3b9f6e7f1116c1eeec2d1e7a64eec Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/55679dc2e72b BuildID 20140618000202 Version 32.0a2 ro.build.version.incremental=108 ro.build.date=Tue Jun 10 19:40:40 CST 2014 Flame video: http://www.youtube.com/watch?v=I0FIP-AShdY&feature=youtube_gdata_player note : 1. hitting home will continue to the smart collection overlay
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH]
QA Whiteboard: [VH] → [VH-FL-blocking-][VH-FC-blocking+]
Whiteboard: [systemsfe]
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
I feel like this is probably some kind of race in the system app. Potentially related to setVisible and the select dialog.
So, unfortunately, when the lockscreen is activated and there's an attentionscreen present that is asking for permission we effectively close the attentionscreen and report back that the permission was denied. I don't think this is the wrong behavior personally but we should simply unlock to the homescreen and it should be visible as expected. UX?
Flags: needinfo?(firefoxos-ux-bugzilla)
Just proposed an idea to Aus. We cannot kill the activity just because the permission dialog is deny-ed. So the best to me is to trigger the request again when page visibility is true by visibilitychange event handler because system app cannot trigger it. Another possible solution is keep the permission request even when screen is off. But I don't see how to do that for now in gaia. And I suspect if this meets security requirement.
I don't think this is really a problem with the permission dialog, I am fairly certain this is a race condition when focusing on a <select> box inside of an activity. We can patch the collection app for now, but I'm not sure if that would really solve the problem.
Responding to ni? to verify that Naoki's expected behavior (the geolocation overlay) is correct, because unchecking the box does not remove the overlay. So, if possible, the user should see the overlay, picking up where they left off. Ni? us further as needed.
Flags: needinfo?(firefoxos-ux-bugzilla)
blocking-b2g: 2.0? → 2.0+
Assignee: nobody → aus
Status: NEW → ASSIGNED
Target Milestone: --- → 2.0 S5 (4july)
Blocks: 1027990
Blocks: 1015336
No longer blocks: vertical-homescreen
Attached patch bug1027414.patch (deleted) — Splinter Review
This is weird that the window stays opened anyway. Other OS clean up the state of the homescreen (windows, edit mode) when the phone is locked, which is likely because people expect to arrives on their homescreen when the screen is turned on and then the phone unlocked. This patch, close the collection window when it's visibility change to false. No more black collection window. We would not spend time on making the permission dialog lives on top of the window, when the screen is turned off for inline activities as it will change some behaviors and may results into other side effects. We are already late on the homescreen, so let's go with simple consistencies all around the place. Unlocking the phone brings you back to your homescreen on a clean state. That's more consistent generally and will not create followups where we have to know which window has implemented the permission dialog, in order to keep it alive, but remove it if the app is killed, etc... This is basically implementing moving permission into the AppWindow, and this bug is out of scope for 2.0. We can revisit it for 2.1 if this is really needed.
Attachment #8444334 - Flags: review?(alive)
Comment on attachment 8444334 [details] [diff] [review] bug1027414.patch Review of attachment 8444334 [details] [diff] [review]: ----------------------------------------------------------------- That is nice to reduce system work.
Attachment #8444334 - Flags: review?(alive) → review+
Commit (master): https://github.com/mozilla-b2g/gaia/commit/217b6fac31a8eaa1f74dfff95239fbc29eae4dd4 Commit (v2.0): https://github.com/mozilla-b2g/gaia/commit/de77f794db22a45f9d575de2c6e266a30a50de3b Since it was originally assigned to me, I figured I might as well help a little where I can. :) Merci Vivien!
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Ghislain Aus Lacroix [:aus] from comment #8) > Commit (master): > https://github.com/mozilla-b2g/gaia/commit/ > 217b6fac31a8eaa1f74dfff95239fbc29eae4dd4 > > Commit (v2.0): > https://github.com/mozilla-b2g/gaia/commit/ > de77f794db22a45f9d575de2c6e266a30a50de3b > > Since it was originally assigned to me, I figured I might as well help a > little where I can. :) Merci Vivien! Backouted and relanded on master with the right information (https://github.com/mozilla-b2g/gaia/commit/d39e345d2902b873ac425546b8f3ce08a15b6190). It's very easy to fix the git author of the patch directly instead of putting it into the comment :)
Verified the issue is fixed on 2.1 and 2.0 Unlocking the phone doesn't show the black screen Device: Flame 2.1 KK BuildID: 20141103001220 Gaia: 027a7de0c95320cea0579bfd1a4ceef3e9038f34 Gecko: ffecb2be228b Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 34.0 (2.1) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.0 KK BuildID: 20141103000201 Gaia: 7b8df9941700c1f6d6d51ff464f0c8ae32008cd2 Gecko: 82a6ed695964 Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 32.0 (2.0) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] → [VH-FL-blocking-][VH-FC-blocking+], [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+], [QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking+], [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: