1738898 - Devices with primary password set will register themselves as unable to receive a tab.

Status: VERIFIED FIXED

(Firefox :: Sync, defect, P2)

Description

[Ronan Jouchet [:ronjouch]]

Attachment: screenshot-ronan-firefox-sync-contextmenu-sendtodevice-with-device-missing.png

About once or twice a week, on my atwork machine, my athome device is missing from the context menu's Send Page to Device list. See attached screenshot.

I did follow your Support page / Managing devices using Firefox Accounts / I do not see my device in the Connected Services list, with no success:

1. I ran Sync Now and it synced successfully.
2. I restarted the browser.
3. I open the Firefox Accounts page (as visible in screenshot).

But none of these things make the athome device come back in the menu.

This happens about once or twice a week, and when it's broken, I think it's broken until I use my athome machine. Said differently, nothing I attempt on my atwork machine ever fixed the issue; the only thing that fixes it is coming back athome, then the day after on my atwork machine, the athome machine is visible again.

However, as you see from the screenshot, the atwork machine is acknowledged by the Connected Devices page as active a mere an hour ago.

Am I missing something?

Debug info

• Nightly 96.0a1 - 20211102094141, official Mozilla build
  • But the issue is not new, it has been happening for weeks
• Feel free to ask for more debug info

Comment 1

[Ronan Jouchet [:ronjouch]]

Attachment: screenshot-ronan-device-again-missing.png

Bug reproduced again today.
Running Sync Now or restarting the browser doesn't help.
Can someone confirm / reproduce / ask for info?

Comment 2

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

Attachment: image.png

That's a bit odd. I suspect there might be something strange syncing that "athome" device. We typically don't show devices that have duplicate names (which doesn't seem to be the case here) or that haven't synced for 7 days. How we determine that "hasn't synced" is different from the "last seen" shown there, so something might be going wrong.

There's an about:sync addon described at https://wiki.mozilla.org/CloudServices/Sync/File_a_desktop_bug - if you install this on the "athome" device a couple of things will happen:

• You should find a "clients" collection listed - that has a "response" tab, which buried away you can find the modified time - see the screenshot for an example of my phone. Can you please let me know what that value is for your specific device?

• Installing about:sync will automatically increase the log level for sync. If you can force a sync of that device, then visit about:sync-log and upload any new logs that were created. about:sync also allows you to zip up all log files which might be helpful. This should tell us if there's anything going wrong syncing that device.

Comment 3

[Ronan Jouchet [:ronjouch]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #2)

We typically don't show devices that have duplicate names (which doesn't seem to be the case here) or that haven't synced for 7 days.

Yup, confirming I don't have dup names, and confirming that both athome and atwork sync basically every weekday.

Can you please let me know what [your modified] value is for your specific device?

Sure. My clients.response.records array is of length 2,

1. Element 0 is atwork, with a data.modified = 1636117504.58
2. Element 1 is athome, with a data.modified = 1636210306.06

Comment 4

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

Thanks for that data and the logs you sent via email! And hrm - it turns out the problem is that a primary password is enabled! If we check our device registration while locked, we hit this check so re-register the device without the send-tab command.

I'm quite surprised we haven't seen this reported before. The fix is probably to just avoid checking/updating the device registration while the primary password is locked - it's not quite clear how easy that will be though.

Comment 5

[Ronan Jouchet [:ronjouch]]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #4)

Thanks for that data and the logs you sent via email! And hrm - it turns out the problem is that a primary password is enabled! If we check our device registration while locked, we hit this check so re-register the device without the send-tab command.

That makes total sense with my usage. I do use a Primary Password, and sometimes in the morning I will pop Firefox open, check the weather, and dismiss the sign-in prompt.

I'm quite surprised we haven't seen this reported before. The fix is probably to just avoid checking/updating the device registration while the primary password is locked - it's not quite clear how easy that will be though.

Great. Am available to test fixed builds if/when they emerge.

Comment 6

[Tarik Eshaq [:teshaq]]

Attachment: Bug 1738898 - Don't register devices if primary passoword is locked. r=markh

Comment 7

[Tarik Eshaq [:teshaq]]

Attachment: Bug 1738898: Persist encrypted sendtab keys. r=markh

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/39545ad07bc6
Persist encrypted sendtab keys. r=markh

Comment 9

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/39545ad07bc6

Comment 10

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! Reproduced the issue while logged into sync with Firefox 96.0a1 (2021-11-02) and set a Primary password. On the same machine, I logged in to sync with Firefox 96.0b4 (20211212185725) and also set a primary password. When the Primary password prompt was displayed I clicked cancel and logged into sync with the same account on other Windows 10x64, macOS 10.15, and Ubuntu 21.1 machines with Firefox 96.0b4. When selecting to send a tab/link from other machines to the initial machine only the fixed build (Firefox 96.0b4) is displayed in the context menu and the other one not. Also sending tabs/links works as it should. Closing the issue as verified.