1792040 - The "Nothing to see yet" message is displayed when connecting via QR code

Status: RESOLVED WONTFIX

(Firefox :: Firefox View, defect, P3)

Description

[Maria Berlinger [:mberlinger], Services QA]

Precondition

• The user is connected to sync on desktop;

Affected versions

• 107.0a1 (2022-09-22)
• 106.0b2

Tested platforms

• Affected platforms: windows 10, macOS 12.5.1, Ubuntu 22.04

Steps to reproduce

1. Be in the Firefox view tab;
2. Click the “get Firefox for mobile” button;
3. Finalize the device connection flow;
4. Click the “See tabs from synced devices” button;
5. Observe the “Tab pickup” section;

Expected result

• The tabs opened from the mobile device are displayed;

Actual result

• The "Nothing to see yet" message is displayed when connecting via QR code, even if the mobile device has tabs opened.;

Additional notes

• The tabs opened on the mobile device are displayed after reloading one of the opened pages and hitting multiple times the "Sync now" option on both mobile and desktop;
• When connecting via email, the opened tabs from the mobile device are displayed in ~1 min.

Comment 1

[Ray Fambro]

Let's confirm the frequency that this scenario occurs and troubleshoot based on that.

Comment 2

[Yasmin S]

Thank @Maria for reporting . Can we confirm if we can reliably reproduce this every time a user connects via QR code. Hoping to understand if this is a less frequent / intermittent issue and increase the severity / priority if that is not the case.

Comment 3

[Sam Foster [:sfoster] (he/him)]

:markh, can you share what information you have on this? Is this expected behavior from Sync's point of view - that Firefox View should workaround? If we confirm this is happening regularly with these STR, or even every time then this is likely to get upgraded to a blocking P1, so I'd like to start to understand what is going on and what our options might be to fix it.

Comment 4

[Sam Foster [:sfoster] (he/him)]

I've been able to reproduce this a couple of times, but not every time. Note that the FirefoxViewHandler does call SyncedTabs.syncTabs() when the firefox-view tab is selected, so viewing another tab then coming back to that one does have an impact, and in my case after staring at the "nothing to see" placeholder for a minute or so, that was what finally triggered the synced tabs to show up.

:markh, I'm sending sync logs via email, though it looks like the only PII in there is maybe my email.

Comment 5

[Sam Foster [:sfoster] (he/him)]

Looks like Mark is OOO, forwarding the need-info to Sammy, I also forwarded the sync-logs via email.

Comment 6

[Maria Berlinger [:mberlinger], Services QA]

(In reply to Yasmin S from comment #2)

Thank @Maria for reporting . Can we confirm if we can reliably reproduce this every time a user connects via QR code. Hoping to understand if this is a less frequent / intermittent issue and increase the severity / priority if that is not the case.

Hello,
I have just tried the following, using Firefox 106.0b3:

• connect to Sync via QR code 3 times, and each time the "Nothing to see yet" message was present.
• Connect to Sync via email 2 times, and each time the "Nothing to see yet" message was present. It seems that now this is reproducible for the email sign in too.

Comment 7

[Sammy Khamis [:skhamis]]

:sfoster, thanks for sending over the logs. From the looks of it, I cannot see anything obvious that is causing this issue. I do not believe this is expected behavior of sync.

I'm able to repro this but only when navigating to the firefox view page after confirming the pairing within the 30s. I believe it's due to the call in the FirefoxViewHandler this.SyncedTabs.syncTabs(); calling too frequently thus it getting kicked back without actually receiving the tabs.

While I was waiting for the "Nothing to see yet" message, I tried a manual sync (just pressed the FxA avatar button) and immediately my tabs showed up.

In terms of actual fix, either we'll need to send the "force" bool to syncTabs(force) when the tabs are foregrounded (not super ideal) or we can just check if we have anything in the recent tabs list SyncedTabs.getRecentTabs() which is populated even if the syncTabs() kicks back for syncing too frequently.

Another fix is potentially moving when we updated last fetch to be after our login checks https://searchfox.org/mozilla-central/source/services/sync/modules/SyncedTabs.jsm#141-149 so that we only set the 30s timer after a successful sync. But that's a little more risky as well.

Anyways, mainly doing a dump of info just to understand what is going on incase this is something we'd like to actually try to get a fix for!

Comment 8

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

The tail of the last sync log has:

1663904803625 Sync.Engine.Clients INFO Uploading 0 outgoing records
1663904803626 Sync.SyncScheduler DEBUG Client count: 4 -> 5

So we found the new device has written its tabs.

1663904803627 Sync.Synchronizer INFO Updating enabled engines: 5 clients.
1663904803627 Sync.Synchronizer INFO Syncing specified engines: ["tabs"]
1663904803743 Sync.Collection DEBUG GET success 200 https://sync-1-us-west1-g.sync.services.mozilla.com/1.5/181174658/storage/tabs?newer=1663904713.36&full=1&limit=1000
1663904803748 Sync.Engine.Tabs.Store DEBUG Adding remote tabs from 527a4092ec697b48a93dff9e969399a1
1663904803749 Sync.Engine.Tabs INFO Records: 1 applied, 1 successfully, 0 failed to apply, 0 newly failed to apply, 1 reconciled.
1663904803750 Sync.Engine.Tabs INFO Uploading 1 outgoing records
1663904803879 Sync.RemoteTabs DEBUG Processing client: {"id":"-se-UYEn7ODp","type":"client","name":"sfoster’s Nightly on sfoster-ThinkPad-P15","clientType":"desktop","lastModified":1663632339170,"tabs":[]}
1663904803879 Sync.RemoteTabs DEBUG Processing client: {"id":"6emiitQjTvCx","type":"client","name":"sfoster’s Nightly on DESKTOP-CTCQQVC","clientType":"desktop","lastModified":1662663889980,"tabs":[]}
1663904803879 Sync.RemoteTabs DEBUG Processing client: {"id":"iWBKs2ItsEuj","type":"client","name":"sam’s Nightly on LAPTOP-LICMS4AA","clientType":"desktop","lastModified":1663903593430,"tabs":[]}
1663904803879 Sync.RemoteTabs DEBUG Processing client: {"id":"527a4092ec697b48a93dff9e969399a1","type":"client","name":"Firefox for Android","clientType":"phone","lastModified":1663904742130,"tabs":[]}

But they are empty. ie, in this particular scenario, the tab syncing worked but found zero tabs. None of the other 4 connected devices have synced tabs.

In all the logs, there are 3 entries where SyncedTabs.jsm declined to sync because the last attempt was less than 30 seconds ago, but in this particular case there are simply no tabs.

There are a number of moving parts here which makes a single diagnosis impossible:

• It's expected that when desktop sees that a new device has connected via the push notification, that device may not yet have synced tabs - it will sync them very soon, but the push notification comes as the sync process is just starting.

• As Sammy mentions, that 30-second debounce is probably hurting us in this case, so passing force=true probably makes sense, but we'd need to be careful - passing that in all cases could have a detrimental effect on the server. Passing force=true in response to direct user action probably makes sense though.

• In Sam's specific case in the log files, there are simply no tabs. This seems somewhat likely for a brand new install of the mobile browser.

Comment 9

[Sam Foster [:sfoster] (he/him)]

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

• In Sam's specific case in the log files, there are simply no tabs. This seems somewhat likely for a brand new install of the mobile browser.

This was me re-signing in on a moble device, not a new install so there were 2 tabs that should have shown up there. But you're right that 0 tabs isn't an error as such and we need to be careful we support that case.

Thanks both for the input here. I'll see if there's a way to selectively add the force param just for this kind of scenario.

Comment 10

[Sam Foster [:sfoster] (he/him)]

It looks like fxaccounts:devicelist_updated is maybe a good moment to do a syncTabs(true) from TabsSetupFlowManager (provided the notification is us adding a device, not removing it.)

But I've tried addding a syncTabs(true) in there and I'm still able to reproduce the issue so I'm not quite sure what is going on. I'll keep looking next week.

Comment 11

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

(In reply to Sam Foster [:sfoster] (he/him) from comment #10)

It looks like fxaccounts:devicelist_updated is maybe a good moment to do a syncTabs(true) from TabsSetupFlowManager (provided the notification is us adding a device, not removing it.)

That's going to hit the problem I mentioned above: When you get that notification the device is just about to start syncing, but it's unlikely to have actually synced any tabs yet.

Comment 12

[Sam Foster [:sfoster] (he/him)]

Attachment: WIP: Bug 1792040 - Poll for synced tabs when a device was just added. r?Gijs!,markh

Comment 13

[Maria Berlinger [:mberlinger], Services QA]

Hello,
I was able to reproduce this using Nightly 108.0a1 (2022-11-02) build on desktop (macOS 10.14.6 & Windows 10) and iOS (iPhone 11, ios 15.5) device.
I've observed the following:

• Connecting the iOS device to Sync via the email address, the opened tabs from the iOS device are successfully displayed in the "Tab pickup" section
• Connecting the iOS device to Sync via the QR code the following were observed:
  • switching immediately to the Firefox view tab after connecting the iOs device, the tabs opened on the iOS device are not displayed in the "Tab pickup" section until another device is connected to Sync
  • if the Firefox view tab is not immediately opened after connecting the iOS device to Sync, the tabs opened tabs are displayed in the "Tab pickup" section

Comment 15

[Sam Foster [:sfoster] (he/him)]

Downgrading priority. I'm still actively working on this and but we're targeting 109.

Comment 16

[Sam Foster [:sfoster] (he/him)]

Attachment: WIP: Bug 1792040 - Some test cleanup and refactoring

Comment 17

[Sam Foster [:sfoster] (he/him)]

I have a WIP patch that I think addresses a lot of the questions and feedback I've had so far. But still leaves some unanswered - including the overall shape and moving parts here. As I say in https://phabricator.services.mozilla.com/D158073#5403741, there is some inherent complexity here that no amount of window dressing will remove, but perhaps the new patch frames the problem in a way that someone might spot a better pattern or solution for that I'm overlooking. Gijs, Markh, do you have time to take a look? I'm out on PTO soon, but expect to pick this back up when I'm back, so any feedback I can gather in the interim would be useful.

Comment 18

[:Gijs (he/him)]

I dropped some notes on the patch.

Comment 19

[Sam Foster [:sfoster] (he/him)]

I think it makes sense to reverse the dependency order here with bug 1809661. The patch on this bug has been difficult to get right and introduces a lot of complexity that may not be warranted. Since this bug was first filed, some smaller fixes have been split off and landed and while this is still reproduceable, its not possible to get stuck indefinitely as before - any tabs from the newly added device will eventually show up when the regularly scheduled background sync happens.

I'm going to put this back in the backlog with a lower priority for now. I suggest we monitor for more reports of issues here and - assuming we can land a patch for bug 1809661 - review the severity of the problem when there is some telemetry data to look at.

Comment 20

[Ray Fambro]

Thanks for all of your work on this one Sam! And agreed. This is now no longer a large user experience issue for us. Totally fine with placing into the Backlog.

Comment 21

[:Gijs (he/him)]

Does this bug still exist in Fxview .next?

Comment 22

[Sam Foster [:sfoster] (he/him)]

(In reply to :Gijs (he/him) from comment #21)

Does this bug still exist in Fxview .next?

I believe so, yes. We still have the same process of adding a device, being notified by FxA that a new device was added, but needing to wait for an indeterminate amount of time before tabs synced from the new device show up in FxView. I've heard anecdotally that this is more of a problem when the QR code is used, but I have no idea why that would be. The telemetry data we have shows a huge spread of values, from 0 seconds to - in a few rare cases - hours.

Comment 23

[Sarah Clements [:sclements]]

I'm going to close this bug out because after discussion with the sync team, its clear bug 1806531 is still the best solution (and when they add that support we can open a new bug to handle the notification).