search

w3c / webappsec-credential-management

WebAppSec Credential Management
https://w3c.github.io/webappsec-credential-management/
Other
49 stars 37 forks source link

Specify that Promises reject if their global's document is destroyed. #83

Open jyasskin opened 7 years ago

jyasskin commented 7 years ago

@kpaulh pointed out that it's possible to call get() or create(), pass the resulting Promise to another document (probably another tab via window.opener, but maybe up from a nested iframe), and then have the user close or navigate the originating document before the Promise resolves. Should the browser be required to keep processing the dead document's operations, or can it abort them?

fetch() aborts in the https://html.spec.whatwg.org/multipage/browsers.html#abort-a-document algorithm, called from https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents and https://html.spec.whatwg.org/multipage/browsers.html#discard-a-document.

The Chrome Web Bluetooth implementation aborts, with some discussion in https://github.com/WebBluetoothCG/web-bluetooth/issues/57#issuecomment-208632357, although I didn't push that through into the spec. 😳

WebAuthn is in a similar situation to Web Bluetooth: they have an active connection to an authenticator device, and it'd be nice to be able to scope its lifetime to the document. However, password credentials are lighter-weight, and could in theory finish their processing. I'm inclined to just uniformly say that Credential Manager promises should abort if their originating document is closed, probably by adding a hook to the abort-a-document algorithm.

mikewest commented 7 years ago

Aborting in-progress operations upon the document's death makes sense to me.

I'm not sure it's a good idea for every relevant spec to be listed out in HTML, though. Perhaps there's some more generic mechanism? This seems like another instance where spec-only events would be a nice thing to have, @annevk.

annevk commented 7 years ago

@mikewest no, because with events the registration order matters and we don't have that. We've been through this before. Order matters and therefore you need centralized ordered lists.

I'm not sure what the best solution is though. What Fetch does is rather handwavy. Navigation needs to be a lot more refactored before it's extremely clear what we should do here I think.

jyasskin commented 7 years ago

The order is detectable, but I suspect the particular order isn't important, so maybe we could register spec-event handlers with a unique string name, and just fire them in alphabetical order, like we do with partial dictionaries.

annevk commented 7 years ago

That might work for this case, but then you'd have to define a specification-level event model just for this case.