New issue
Advanced search Search tips

Issue 807738 link

Starred by 1 user
Status: Assigned
Owner:
vasi...@chromium.org
Cc:
jochen@chromium.org
battre@chromium.org
mustaq@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocked on:
issue 404161

Show other hotlists

Hotlists containing this issue:
Hotlist-2


Sign in to add a comment

Credential Manager promise resolution doesn't set a user intent flag for the pop-up blocker

Reported by hillb...@gmail.com, Jan 31 2018 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
1. navigator.credentials.get(...).then(function() { // open popup to IdP });
2. popup blocker triggers

What is the expected behavior?
For a FederatedCredential, an IdP needs to be able to open a popup to refresh consent, re-login the user at the IdP, etc. in response to collecting a user gesture in the credential management browser chrome from credentials.get(). (or if the user has previously opted in to providing stored credentials without mediation)  

If the user does anything but "cancel", the promise settlement functions for get() should behave as if in response to a direct user gesture.

What went wrong?
Because get() returns a promise, and so inherently settles asynchronously, the user gesture flag used by the pop up blocker is lost, and the pop-up is blocked.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 63.0.3239.132  Channel: n/a
OS Version: OS X 10.13.3
Flash Version:

Comment 1 by mkwst@chromium.org, Feb 1 2018

Cc: jochen@chromium.org
Components: -Blink>SecurityFeature Blink>SecurityFeature>CredentialManagement
Labels: OS-Android OS-Chrome OS-Linux OS-Windows
Owner: battre@chromium.org
Status: Assigned (was: Unconfirmed)
It seems reasonable to me that if the user clicks through the credential management UI in Chrome that we should grant a user gesture to the `get()` handler. It seems equally reasonable that if `get()` is called in response to a user gesture that we'd persist that through to the handler.

I feel like we've talked about this before, but I can't find the bug. +jochen@, who might remember the context.

battre@: Would you mind triaging this in your team?

Comment 2 by jochen@chromium.org, Feb 1 2018 

i believe this is issue 404161

Comment 3 by battre@chromium.org, Feb 2 2018

Cc: battre@chromium.org
Owner: vasi...@chromium.org

Comment 4 by battre@chromium.org, Feb 2 2018 

Vasilii will investigate. It might be fixed on Canary channel already.

Comment 5 by vasi...@chromium.org, Feb 2 2018

Cc: mustaq@chromium.org
There is a design doc about User Activation v2  https://docs.google.com/document/d/1erpl1yqJlc1pH0QvVVmi1s3WzqQLsEXTLLh6VuYp228/edit#heading=h.hy5wkxbrpq6o

Its tracking bug is https://crbug.com/696617. Basically the user gesture stays active until the page consumes it. In that model it's active until "open popup to IdP" step that should succeed. One can already test it in Chrome with --enable-features=UserActivationV2.

mustaq@, what is a timeline for the feature? I'm sorry that you are mostly blocked on the password manager behavior :) We'll overcome it ;)

Comment 6 by mustaq@chromium.org, Feb 5 2018 

The original post seems to suggest to me that Promises not propagating user gestures (or "user activation" in a modern term) is the core issue here: see the 3+-year-old Issue 404161.

I was about to block it on that old issue but not sure about #c5.

Vasilii: I don't know much about password manager to parse your last comment.  Did you mean the behavior changes with UserActivationV2?

Comment 7 by vasi...@chromium.org, Feb 5 2018 

Yes. Issue 404161 is fixed automatically with UserActivationV2, isn't it?

Comment 8 by vasi...@chromium.org, Mar 12 2018

Blockedon: 404161
►

Sign in to add a comment