Document merging get() calls for multiple IDP usage - #351
Conversation
npm1
left a comment
There was a problem hiding this comment.
Could we integrate the changes into the existing processing logic in the spec?
| even with IDP SDKs that do not cooperate with each other. To make this | ||
| possible, the UA has to merge get() calls as follows: | ||
|
|
||
| 1. If `navigator.credentials.get()` is called before or during onload the |
There was a problem hiding this comment.
Need to clarify this is window onload
|
|
||
| 1. If `navigator.credentials.get()` is called before or during onload the | ||
| UA saves the provided options and delays further processing until | ||
| immediately after onload. |
There was a problem hiding this comment.
Unclear what immediately after means. Microtask/task/something else?
| processing until that microtask. | ||
| 1. When resuming processing, the saved options from all calls to get are | ||
| combined as follows: | ||
| 1. The provider arrays are concatenated |
There was a problem hiding this comment.
What happens if there are repeated configURLs?
cb0e7de to
edd7af8
Compare
| 1. <a for=Promise>Resolve</a> |promise| with [undefined] and return |promise|. | ||
| </div> | ||
|
|
||
| <!-- ======================================================= --> |
There was a problem hiding this comment.
I was expecting to see this PR being intermingled with the [[DiscoverFromExternalSource]] algorithm, rather than as a separate section.
Should we merge this with that?
There was a problem hiding this comment.
This should be done, please take another look
| Note: the purpose of having a timer here is to avoid leaking the reason causing this | ||
| method to return null. If there was no such timer, the developer could easily infer | ||
| whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=]. | ||
| 1. If the load event on the window object has not fired yet, or is |
| Note: the purpose of having a timer here is to avoid leaking the reason causing this | ||
| method to return null. If there was no such timer, the developer could easily infer | ||
| whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=]. | ||
| 1. If the load event on the window object has not fired yet, or is |
There was a problem hiding this comment.
Is there a link for fired? Also not entirely clear what 'currently being fired' means?
| method to return null. If there was no such timer, the developer could easily infer | ||
| whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=]. | ||
| 1. If the load event on the window object has not fired yet, or is | ||
| currently being fired, save the provided options and delay further |
There was a problem hiding this comment.
You should use the variable name. "|options|". Also save it where?
| IDP. It is desirable to be able to show multiple IDPs together in the | ||
| account chooser even with IDP SDKs that do not cooperate with each | ||
| other. This and the next step make this possible. | ||
| 1. Otherwise, enqueue a microtask and delay further processing until that |
| other. This and the next step make this possible. | ||
| 1. Otherwise, enqueue a microtask and delay further processing until that | ||
| microtask. | ||
| 1. When resuming processing, the saved options from all calls to get are |
There was a problem hiding this comment.
The scope of the saving here is unclear since it's not clear where this is being saved...
| other. This and the next step make this possible. | ||
| 1. Otherwise, enqueue a microtask and delay further processing until that | ||
| microtask. | ||
| 1. When resuming processing, the saved options from all calls to get are |
There was a problem hiding this comment.
Should probably be a new function
cbiesinger
left a comment
There was a problem hiding this comment.
Please take another look!
| Note: the purpose of having a timer here is to avoid leaking the reason causing this | ||
| method to return null. If there was no such timer, the developer could easily infer | ||
| whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=]. | ||
| 1. If the load event on the window object has not fired yet, or is |
| Note: the purpose of having a timer here is to avoid leaking the reason causing this | ||
| method to return null. If there was no such timer, the developer could easily infer | ||
| whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=]. | ||
| 1. If the load event on the window object has not fired yet, or is |
| method to return null. If there was no such timer, the developer could easily infer | ||
| whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without providing consent to share the [=IDP=] account information with the [=RP=]. | ||
| 1. If the load event on the window object has not fired yet, or is | ||
| currently being fired, save the provided options and delay further |
| IDP. It is desirable to be able to show multiple IDPs together in the | ||
| account chooser even with IDP SDKs that do not cooperate with each | ||
| other. This and the next step make this possible. | ||
| 1. Otherwise, enqueue a microtask and delay further processing until that |
| other. This and the next step make this possible. | ||
| 1. Otherwise, enqueue a microtask and delay further processing until that | ||
| microtask. | ||
| 1. When resuming processing, the saved options from all calls to get are |
| other. This and the next step make this possible. | ||
| 1. Otherwise, enqueue a microtask and delay further processing until that | ||
| microtask. | ||
| 1. When resuming processing, the saved options from all calls to get are |
| 1. All AbortSignals are saved and if any is aborted, all further | ||
| processing is aborted and the account chooser, if any, is closed. | ||
| (TODO: What is the desirable behavior here?) | ||
| 1. Let |provider| be |options|["{{CredentialRequestOptions/identity}}"]["{{IdentityCredentialRequestOptions/providers}}"][0]. |
There was a problem hiding this comment.
So, this PR is combining the provider options but then throwing all-but-the-first away in this line?
There was a problem hiding this comment.
Yes... I wanted to decouple this specific behavior of merging get calls from general multi-IDP support. Do you think I should change this PR to cover both?
| IDP. It is desirable to be able to show multiple IDPs together in the | ||
| account chooser even with IDP SDKs that do not cooperate with each | ||
| other. This and the next step make this possible. | ||
| 1. [=Queue a global task=] where the global object is the current window |
There was a problem hiding this comment.
A couple of things are unclear to me in this PR:
(a) what happens to all of the promises that are in the |all_options| array that aren't picked? Do they get resolved? Failed? I think that, as specified, they never resolve? Is that deliberate?
(b) what happens to the AbortSignals that were passed? If one of the AbortSignals that was passed in the |all_options| gets aborted, does that get ignored?
There was a problem hiding this comment.
For a): See the paragraph starting at line 1119
For b): See the paragraph starting at line 1124.
cbiesinger
left a comment
There was a problem hiding this comment.
Sam, please see my responses below.
| 1. All AbortSignals are saved and if any is aborted, all further | ||
| processing is aborted and the account chooser, if any, is closed. | ||
| (TODO: What is the desirable behavior here?) | ||
| 1. Let |provider| be |options|["{{CredentialRequestOptions/identity}}"]["{{IdentityCredentialRequestOptions/providers}}"][0]. |
There was a problem hiding this comment.
Yes... I wanted to decouple this specific behavior of merging get calls from general multi-IDP support. Do you think I should change this PR to cover both?
| IDP. It is desirable to be able to show multiple IDPs together in the | ||
| account chooser even with IDP SDKs that do not cooperate with each | ||
| other. This and the next step make this possible. | ||
| 1. [=Queue a global task=] where the global object is the current window |
There was a problem hiding this comment.
For a): See the paragraph starting at line 1119
For b): See the paragraph starting at line 1124.
npm1
left a comment
There was a problem hiding this comment.
Hmm thinking about this more, it might actually be better to have a section for multiIDP that monkey patches the main sections because we are not fully confident on the design here yet and because Mozilla may want to implement the single IDP case like us for now, so having this in the main algorithm might cause some confusion.
| whether the user has an account with the [=IDP=] or not, or whether the user closed the UI without granting permission to share the [=IDP=] account information with the [=RP=]. | ||
| 1. Let |all_options| be a list of pairs of {{CredentialRequestOptions}} | ||
| and {{Promise}} objects. | ||
| This list is reused for all {{Credential/[[DiscoverFromExternalSource]]}} |
There was a problem hiding this comment.
Generally how this is handled is that we add associated members to the relevant object. So here it would probably be "Each Window has an associated allOptions which is initially bla"
| and {{Promise}} objects. | ||
| This list is reused for all {{Credential/[[DiscoverFromExternalSource]]}} | ||
| calls within the same global object. | ||
| 1. Create a new promise and append (|options|, new promise) to |all_options|. |
There was a problem hiding this comment.
Might be clearer to name the new promise some var.
| a task has already been posted (step after next), return the promise. | ||
| 1. If the document is not <a spec=HTML>completely loaded</a>, register | ||
| an [=event handler=] on the {{Window}} object for the | ||
| {{Window/load}} event. When the listener is called, proceed to the |
There was a problem hiding this comment.
It is just better to add new algorithm as the listener, and that algorithm is actually the 'next steps'
| This list is reused for all {{Credential/[[DiscoverFromExternalSource]]}} | ||
| calls within the same global object. | ||
| 1. Create a new promise and append (|options|, new promise) to |all_options|. | ||
| 1. If a load event listener (next step) has already been registered or |
There was a problem hiding this comment.
Could use a boolean to track this more formally.
| task source</dfn> and steps is "go to the next step". | ||
| 1. Let |options| be the result of running the [=combine CredentialRequestOptions=] | ||
| algorithm with |all_options|. | ||
| 1. Let |provider| be |options|["{{CredentialRequestOptions/identity}}"]["{{IdentityCredentialRequestOptions/providers}}"][0]. |
There was a problem hiding this comment.
This would need to not limit to the first one, and the "potentially create IdentityCredential" would need to allow an array of providers instead of a single one.
|
I made #368 to support multi IDP in general, as a prerequisite for this PR. |
|
Two high level comments:
I don't know if we should submit this PR right now. |
|
This seems outdated and I am trying to clean up open pull requests so I'm closing. If you still wanted to work on this feel free to reopen. |
Preview | Diff