- From: Martin Thomson <mt@mozilla.com>
- Date: Wed, 17 Aug 2016 23:26:37 +1000
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Raymes Khoury <raymes@google.com>, Jeffrey Yasskin <jyasskin@google.com>, WebAppSec WG <public-webappsec@w3.org>, Marcos Caceres <marcos@marcosc.com>, Mounir Lamouri <mlamouri@google.com>, Ben Wells <benwells@google.com>
On Wed, Aug 17, 2016 at 6:29 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> Is the fact that there has been a click observable from script in any
>> reliable way? I guess that you can show popups and check if they were
>> displayed, but that's massively annoying.
>
> Well, you get a click event...
In practice, browsers have a window after the click event in which
they will accept a popup. Microtasks in the same crank of the event
loop are definitely ok, and I believe that setTimeout(..., 0) is too,
even though that takes a non-zero amount of time.
>> Where I'm going is that this implies a new entry to the key:
>> recent-click. Well, if any browser wants to gate showing a prompt on
>> having clicks.
>>
>> That makes .query() less reliable unless we make the recent-click
>> state explicit. I guess the same goes for any top-level flag.
>
> Presumably Chrome would return "granted" for the permission but still
> require the gesture. Which I guess arguably doesn't make it part of
> the key, but something else? I'm not sure to what extent that has been
> thought through.
I believe that the intent is to require a click only when showing the
permissions prompt, not on the acquisition of the resource. So:
state==prompt: call api => denied
state==prompt: click then call api => prompt shown
state==granted: call api => success
you could model this as:
.request({name: "foo", click: true }) => "prompt"
.request({name: "foo", click: false }) => "denied"
Somehow, I don't think that was the intent though.
Received on Wednesday, 17 August 2016 13:27:08 UTC