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)
Tracking
(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)
People
(Reporter: nhirata, Assigned: vingtetun)
References
Details
(Whiteboard: [systemsfe])
Attachments
(1 file)
(deleted),
patch
|
alive
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•10 years ago
|
Updated•10 years ago
|
Blocks: vertical-homescreen
QA Whiteboard: [VH] → [VH-FL-blocking-][VH-FC-blocking+]
Whiteboard: [systemsfe]
Updated•10 years ago
|
Component: Gaia::Homescreen → Gaia::System::Window Mgmt
Comment 1•10 years ago
|
||
I feel like this is probably some kind of race in the system app. Potentially related to setVisible and the select dialog.
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
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.
Comment 4•10 years ago
|
||
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.
Comment 5•10 years ago
|
||
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)
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Updated•10 years ago
|
Assignee: nobody → aus
Status: NEW → ASSIGNED
Target Milestone: --- → 2.0 S5 (4july)
Updated•10 years ago
|
Assignee | ||
Comment 6•10 years ago
|
||
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 7•10 years ago
|
||
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+
Assignee | ||
Updated•10 years ago
|
Assignee: aus → 21
Comment 8•10 years ago
|
||
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
Updated•10 years ago
|
status-b2g-v2.1:
--- → fixed
Assignee | ||
Comment 9•10 years ago
|
||
(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 :)
Comment 10•10 years ago
|
||
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)
Updated•10 years ago
|
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.
Description
•