1099499 - [Homescreen]Permission dialog occurs twice

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Everything.me, defect)

Description

[ankit93040]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36

Steps to reproduce:

Tester`s Action : Social - popup occur - Remember my choice uncheck -  Don`t Share 


Actual results:

Detailed Symptom (ENG.) : Two pop-up occurs


Expected results:

Should occur only once

Comment 1

[ankit93040]

Attachment: Final.patch

The same issue also happens with search. so modified the same

Thank you

Comment 2

[Kevin Grandon :kgrandon]

Ankit - I was unable to reproduce this issue. Could you by chance attach a video of this occurring? Also could you provide gecko and gaia revisions where you are seeing this?

Comment 3

[Kevin Grandon :kgrandon]

Also seems like it could be related to bug 1099503. I don't see this on trunk though - do you have any custom patches applied to gecko by chance?

Comment 4

[ankit93040]

STR:
1. Go to collection app - Music.
2. App-permission window comes.
3. uncheck the checkbox.
4. click on Don't share.

We need to click twice on Don't share.

I tested it on Flame reproducible on V2.0. Sorry couldn't test it on V2.1 or Master.
Uploading video for the same.

Thank you

Comment 5

[ankit93040]

Attachment: CAM00136.3gp

Comment 6

[Kevin Grandon :kgrandon]

Adding qawanted for branch checks here.

Comment 7

[Cody Roesch [:croesch]]

Tested with Shallow Flash on 319mb using Engineering builds

This bug repro's on Flame KK builds: Flame 2.2 kk, Flame 2.1 KK, Flame 2.0 KK, Flame 2.0 Base

Actual Results: User must tap on Don't Share button twice or sometimes even 3 times to get the app permissions screen for collections to disappear.

Repro Rate: 5/5

Environmental Variables:
Device: Flame 2.2 KK
BuildID: 20141114042015
Gaia: 1e300eac2e56d98ad51d414766d031db7d33221f
Gecko: 64206634959a
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141117031129
Gaia: 10b84fae70cfab428030cc086b433f89ac440c14
Gecko: bc3751255fd1
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141115041711
Gaia: 086a668942292168f312b3bb53e275fa0886fab1
Gecko: a57b299c5cf2
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 Base
BuildID: 20141021162107
Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 8

[ankit93040]

The attached patch resolves the issue.

I tested it on V2.0.

Comment 9

[Kevin Grandon :kgrandon]

Comment on attachment 8523378 [details] [diff] [review]
Final.patch

Review of attachment 8523378 [details] [diff] [review]:
-----------------------------------------------------------------

::: apps/search/js/search.js
@@ +91,4 @@
>  
>        // Fire off a dummy geolocation request so the prompt can be responded
>        // to before the user starts typing
> +      /*if ('geolocation' in navigator) {

I don't think commenting this out is the proper thing to do here.

Comment 10

[Kevin Grandon :kgrandon]

Hey Kan-Ru - I'm trying to find some information about how the geolocation permission works. E.g., do we show the dialog as soon as we access navigator.geolocation? If we do this, the user says no, and the code accesses navigator.geolocation again, are we supposed to immediately prompt? It seems like there should be some kind of timeout before asking for the location again. Any thoughts?

Comment 11

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Kevin Grandon :kgrandon (In Europe/Conf until 11/24) from comment #10)
> Hey Kan-Ru - I'm trying to find some information about how the geolocation
> permission works. E.g., do we show the dialog as soon as we access
> navigator.geolocation? If we do this, the user says no, and the code
> accesses navigator.geolocation again, are we supposed to immediately prompt?
> It seems like there should be some kind of timeout before asking for the
> location again. Any thoughts?

We prompt every time when getCurrentPosition or watchPotision is used. Use a timeout might improve this situation a bit, but I don't think that could fix poorly written software. How would you decide the timeout?

Currently users have the choice to block a site permanently, how about we let them choose "Allow/Block for XX minutes" or "Allow/Block for this session"?

Comment 12

[Kevin Grandon :kgrandon]

(In reply to Kan-Ru Chen [:kanru] from comment #11)
> We prompt every time when getCurrentPosition or watchPotision is used. Use a
> timeout might improve this situation a bit, but I don't think that could fix
> poorly written software.

We're not trying to fix bad software, we're trying to give the user an ideal user experience, one which we don't currently have. It seems to me that we should also empower third party apps to also create nice experiences where possible.

> Currently users have the choice to block a site permanently, how about we
> let them choose "Allow/Block for XX minutes" or "Allow/Block for this
> session"?

Conflating the UI with additional controls doesn't really seem like a good approach to me. We should take an opinionated view of what would provide the best UX to the user IMO.

Comment 13

[Kevin Grandon :kgrandon]

Kan-Ru - it seems in order to build a proper UI around this, we would need to be able to differentiate between a denial of permission, and a genuine error getting geolocation. Is this possible today?

Comment 14

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Kevin Grandon :kgrandon (In Europe/Conf until 11/24) from comment #12)
> (In reply to Kan-Ru Chen [:kanru] from comment #11)
> > We prompt every time when getCurrentPosition or watchPotision is used. Use a
> > timeout might improve this situation a bit, but I don't think that could fix
> > poorly written software.
> 
> We're not trying to fix bad software, we're trying to give the user an ideal
> user experience, one which we don't currently have. It seems to me that we
> should also empower third party apps to also create nice experiences where
> possible.

So I'm not against the idea of using a timeout; just that I think the heuristic is not very good. For example as a user I often accidentally block the permission request and instructs the app to try again immediately in order to grant the permission. If a too long timeout is installed I would be blocked by myself. If the timeout is too short it wouldn't prevent the app to repetitively requesting permission.

Comment 15

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to Kevin Grandon :kgrandon (In Europe/Conf until 11/24) from comment #13)
> Kan-Ru - it seems in order to build a proper UI around this, we would need
> to be able to differentiate between a denial of permission, and a genuine
> error getting geolocation. Is this possible today?

Yes. The error code is different.

https://developer.mozilla.org/en-US/docs/Web/API/PositionError.code

Comment 16

[Kevin Grandon :kgrandon]

Thanks Kan-Ru.

Ankit - I think you'll want to update your patch to leverage the result of PositionError.code. I suppose in the case of PERMISSION_DENIED, I suppose we will want to avoid making subsequent geolocation requests.

Comment 17

[Kevin Grandon :kgrandon]

Mass update: Resolve/Wontfix all existing collections bugs as this feature is now removed.

Please re-open or file a new bug if you feel that this bug still exists in master.