1601446 - Several desktop devices newly signed in to Firefox (not Sync) not appearing in device list

Status: RESOLVED FIXED

(Firefox :: Sync, defect, P2)

Description

[Ryan Feeley [:rfeeley]]

STEPS TO REPRODUCE

1. Sign to to Firefox (Sync disabled) on two or more desktop Firefoxes
2. Go to any Send Tab to Device menu

EXPECTED RESULTS

• Other devices appear

ACTUAL RESULTS

• No devices appear
• If a mobile device (that can only authenticate Sync) signs in, it will appear, and once a tab is sent, the issuing desktop device then appears. It's as if they don't appear until the interact with a Sync device.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:markh, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[janet [:janet]]

Mark is PTO until 6-Jan. I'm going to mark this as a P2 and put it at the top of our work planned for the sprint that ends 17-Jan. If this timeline is concerning, please let me know.

Comment 3

[Ryan Kelly [:rfkelly]]

I want to cross-reference Bug 1604699 here for context, which is about avoiding a fetch of the FxA device list on every sync, since the "fetch on every sync" behaviour was introduced in attempts to fix other related bugs with the display of the "send tab" device menu.

While we're in here debugging and potentially re-jiggering the Send Tab UI, it may be a good opportunity to factor things in a way that makes Bug 1604699 actionable.

Comment 4

[Mark Hammond [:markh] [:mhammond]]

There are a couple of issues here, which can be best summarized as "we only register as a send-tab capable device when we know we can obtain the sync keys needed to decrypt". There's a bug here which can be fixed - however, I'm not sure a simple "fix" for this (ie, sometimes registering the device as being send-tab capable, and sometimes as not being send-tab capable) makes sense - in theory (ie, when the account is in a "good" state) we should always be able to obtain these keys. Cases when we can't include "user isn't yet verified" or "user changed their password on a different device" - but does it make sense to register the device as not send-tab capable in these cases?

ie, we have 2 fundamental choices here:

1. Detect when we transition between these states and update the device registration accordingly. For example, when a user creates an account, we will register the new device as not being send-tab capable. Then, when they verify, update the device registration accordingly. Similarly, when we notice we need to reauthenticate, we would re-register the device without send-tab, and then when they do reauthenticate re-register with send-tab being available.

2. Always register as being send-tab capable, accepting there might be edge-cases when the device can't actually receive the tab.

For (1), the case of a new, unverified user probably doesn't matter in practice. This is almost certainly their first device, so no other device will be looking for this as a device. Setting up a second device while still unverified seems like an edge-case - but even then, they aren't going to be able to send the tab anyway, so the list of send-tab devices is moot (our UI should be such that we never show a list of send-tab compatible devices while unverified, but I'm not sure if that's true)

For (1), a user which needs reauthentication is more problematic - eg, imagine the user has 3 devices, only 1 of which remains in a needs-reauth state. On one hand, this third device should not show as a send-tab target because it will fail to receive the tab. On the other hand, the user probably knows this device exists, and might be confused to find it missing from the send-tab target list. Worse - the 3rd device might not be aware it is in this state yet (eg, that 3rd device has not been started since the user changed their password on the other 2 devices), so that 3rd device will still be registered as being send-tab capable anyway.

So I'm leaning heavily towards saying we should just do (2) - unconditionally register desktop as being send-tab capable, but (a) take steps to ensure the send-tab UI isn't shown when this device can't send one, and (b) suck up the very-edgy edge-cases of when other devices aren't capable of accepting a tab, and justify this by acknowledging we can't always know when other devices are in this state anyway.

(2) reduces complexity and reduces device registration traffic.

(I've actually got a patch that's close to OK for (1) although it doesn't handle the "needs-reauth" case - but on reflection I think I should abandon it)

Ryan and/or Ed, is there something I'm missing here about why (2) isn't the best option here?

Comment 5

[Ryan Kelly [:rfkelly]]

So I'm leaning heavily towards saying we should just do (2) - unconditionally register desktop as being send-tab capable,

Hrm. What would you write into the send-tab command data in this case? It's supposed to be the send-tab public key encrypted with kSync, but you won't have kSync.

Cryptographically, I don't think you can get around having to update your device registration when kSync becomes available.

Comment 6

[Mark Hammond [:markh] [:mhammond]]

(In reply to Ryan Kelly [:rfkelly] from comment #5)

So I'm leaning heavily towards saying we should just do (2) - unconditionally register desktop as being send-tab capable,

Hrm. What would you write into the send-tab command data in this case? It's supposed to be the send-tab public key encrypted with kSync, but you won't have kSync.

sob - yes, I was somehow missing an elephant standing right in the middle of the room :(

Comment 7

[Mark Hammond [:markh] [:mhammond]]

Attachment: Bug 1601446 - re-register the FxA device after the user becomes verified. r?eoger

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8e31404a73e9
re-register the FxA device after the user becomes verified. r=eoger

Comment 9

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/8e31404a73e9