Closed Bug 1448408 Opened 2 years ago Closed 10 months ago

Web Authentication - Don't listen to visibility events

Categories

(Core :: DOM: Web Authentication, enhancement, P1)

61 Branch
enhancement

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox60 --- wontfix
firefox61 --- wontfix
firefox68 --- fixed

People

(Reporter: jcj, Assigned: jcj)

References

(Depends on 1 open bug, Blocks 1 open bug, Regressed 2 open bugs)

Details

(Whiteboard: [webauthn][webauthn-ux])

Attachments

(1 file, 1 obsolete file)

The SoftU2F project [1] provides an authenticator in-software which works using system prompts instead of external interactions. Since Bug 1409202, WebAuthn aborts if Firefox goes into the background at all. Since going into the background is mandatory for SoftU2F, interacting with SoftU2F always causes an AbortError, rendering it unusuable.

More OS-integrated mechanisms, like Windows Hello, may or may not have the same problem.

We might want to be a little less strict about foreground-only?


[1] https://github.com/github/SoftU2F
Depends on: 1409202
Priority: -- → P3
(In reply to J.C. Jones [:jcj] from comment #0)
> We might want to be a little less strict about foreground-only?

I just check Chrome Canary and it looks like there are no checks at all. I can launch a WebAuthn request from a background tab or a minimized window. Active requests aren't aborted when switching tabs or windows.

We could possibly do something in between, i.e. allow requests to start only when the tab is selected in the active window, but don't cancel when switching tabs. Or don't cancel when switching windows?

Although that still wouldn't help with bug 1445242...
Chrome does have some requirements. I think if the response from the security key comes while the window doesn't have focus it is ignored. Soft U2F tries to give focus back very quickly to work with this behavior.
(In reply to Ben Toews from comment #2)
> Chrome does have some requirements. I think if the response from the
> security key comes while the window doesn't have focus it is ignored.

This doesn't reproduce with Canary at least. I can initiate and complete requests with Chrome in the background.
Is there anything that can be done to work around this? I was trying to switch to Firefox today from Chrome but SoftU2F does not work with it due to this bug and there has not been activity here for a very long time.
I'll be addressing this and most of the other webauthn bugs currently on-file in Q1 2019. Hopefully January, but TBD.
Component: DOM: Device Interfaces → DOM: Web Authentication
Duplicate of this bug: 1479500

The published recommendation of L1 for WebAuthn changed the visibility/focus listening behaviors to a SHOULD [1], and Chromium, for these sorts of reasons, opted to not interrupt on tabswitch/visibility change. Let's do the same thing.

[1] https://www.w3.org/TR/webauthn-1/#abortoperation

Assignee: nobody → jjones
Status: NEW → ASSIGNED
Priority: P3 → P1
Summary: Web Authentication - SoftU2F unusable due to context switch aborts → Web Authentication - Don't listen to visibility events

Great news! I hadn't realized that Soft U2F was working with Chrome now for WebAuthn. Great news also to hear that it will work with FF.

The published recommendation of L1 for WebAuthn changed the visibility/focus
listening behaviors to a SHOULD [1], and Chromium, for reasons like our SoftU2F
bug [0], opted to not interrupt on tabswitch/visibility change.

Let's do the same thing.

This removes the abort visibility mechanism entirely, test and all.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1448408#c0
[1] https://www.w3.org/TR/webauthn-1/#abortoperation

Attachment #9052444 - Attachment is obsolete: true

The published recommendation of L1 for WebAuthn changed the visibility/focus
listening behaviors to a SHOULD [1], and Chromium, for reasons like our SoftU2F
bug [0], opted to not interrupt on tabswitch/visibility change.

Let's do the same thing.

This changes the visibility mechanism to set a flag on an ongoing transaction,
and then, upon multiple calls to the FIDO/U2F functions, only aborts if
visibility had changed. Otherwise, subsequent callers return early.

This is harder to explain than it is really to use as a user. I think. At least,
my testing feels natural when I'm working within two windows, both potentially
prompting WebAuthn.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1448408#c0
[1] https://www.w3.org/TR/webauthn-1/#abortoperation

Update FIDO U2F API to also take the stance of visibility events being
not-bad.

Blocks: 1540309
Pushed by jjones@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f7937d3264db
Web Authentication - Don't immediately abort on visibility events r=keeler
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Blocks: 1540378
Blocks: 1540658
Blocks: 1540885
Regressions: 1541085
No longer blocks: 1540378
Regressions: 1540378
No longer blocks: 1540658
Regressions: 1540658
No longer blocks: 1540885
Regressions: 1540885
Regressions: 1585774
You need to log in before you can comment on or make changes to this bug.