[Bug]: Synced tabs showed previous page from current desktop tab instead of current page

[athomasmoz]

Steps to reproduce

1. Login to sync on Firefox Nightly on your desktop and on your Android phone
2. Open a tab on Firefox Nightly on desktop and search for "strawberry cake"
3. Open a recipe from the results
4. Open the hamburger menu on Firefox Nightly desktop and click on your username. Confirm that it shows "Syncing" and wait for it to complete
5. Open the homepage on Firefox Nightly on your Android phone

Expected behaviour

The tab with the recipe open on Firefox Nightly desktop should be displayed in the Jump Back In section

Actual behaviour

• The tab with search results for "strawberry cake" from Firefox Nightly desktop is displayed in the Jump Back In section
• If you open the full list of synced tabs, you see the same. If you click "Sync Now" from that screen, it does not resolve the issue

Notes

This same behaviour exists when looking at synced tabs from one desktop Firefox to another desktop Firefox

Device name

Samsung Galaxy

Android version

Android 11

Firefox release type

Firefox Nightly

Firefox version

105.0a1

Device logs

No response

Additional information

No response

┆Issue is synchronized with this Jira Task

[rocketsroger]

I can reproduce this issue with two desktop browser as well:

1. Have two desktop browser (on different devices) opened and signed into same Firefox account.
2. Open tab with URL1 through awesomebar on Device A and manually trigger a sync (through Firefox account menu)
3. Check on Device B to see if what tabs are opened on Device A.

Expected:

4. Device B list the newly open tab with URL1 under device A. (under Firefox account menu)

Actual:

4. Device B does not list the newly open tab under device A.

Note: I've noticed that if I navigate to a new url in the new tab(say URL2) in Device A then I will see URL1 as synced tab under Device A.

[jdragojevic]

@athomasmoz @rocketsroger can you please open about:sync in your browser and look at the records for tabs. They should include what has been synced - and then you can compare to what Fenix is getting.

Sammy is on PTO this week, but @mhammond can also provide some advices

[rocketsroger]

@athomasmoz @rocketsroger can you please open about:sync in your browser and look at the records for tabs. They should include what has been synced - and then you can compare to what Fenix is getting.

Do I need to have a debug build? I am using the Nightly Firefox and about:sync shows invalid URL. Note: I don't see about:sync in the about:about page.

[MatthewTighe]

@rocketsroger about:sync requires the About Sync addon I believe

[rocketsroger]

@rocketsroger about:sync requires the About Sync addon I believe

Thanks, I'll try it.

[rocketsroger]

@jdragojevic Yes, I can confirm with the about:sync addon that if I just open a tab without navigating in that tab then that tab is not synced. Once I navigate in that tab (to any link) then the tab is synced right away but with the previous URL.

[mhammond]

I can reproduce this and created a patch in bug 1783991

[rocketsroger]

From the bug 1783991 it looks like the issue should be fixed with Firefox Nightly on desktop.

[rocketsroger]

@mhammond I noticed that the issue is still reproducible. However, I found if I just swap to a different tab and back then I get the latest open tabs immediately.

[jdragojevic]

to clarify @rocketsroger:

1. you have a tab (fx view?) open on desktop
2. you switch to your mobile device and open some tabs
3. you switch back to desktop (but don't open, close or navigate to other tabs)
4. Synced tabs list in Fx View is not updated.

[rocketsroger]

@jdragojevic I didn't use a mobile device. Here is how I reproduce the issue:

1. freshly open two Firefox Nightly on two desktops. (let's say A and B)
2. open a youtube tab and a google tab on A, force a sync.
3. click on an youtube video on A, force a sync.
4. go to B (force sync), confirm that the new video url is not synced.

Steps below to work around the problem:

1. go to A, swap to google tab, force sync.
2. go to B (force sync), and confirm the new youtube url is still not updated.
3. go to A (force sync), swap back to the youtube tab.
4. go to B (force sync), confirm that the new youtube url is updated.

[mhammond]

5. go to A, swap to google tab, force sync.

What might be happening here is that when switching tabs, we have scheduled a "quick write" timer that will sync tabs in 5 seconds. However, if you do a "sync now" in that period, the tab list is not synced. IOW, after a tab switch there is no need to force a "sync now" but you do need to wait 5 seconds before the new tab list will be updated on the server.

I think we can fix this, but beyond that, I can't reproduce this. Can you please verify if the above explains what you saw?

[rocketsroger]

What might be happening here is that when switching tabs, we have scheduled a "quick write" timer that will sync tabs in 5 seconds.

One thing to clarify is to reproduce the problem, you don't need steps 5 or above. Step 4 is where I see the problem. Unfortunately, I thought it's better to add step 5-8 to show how I work around the problem. I'll update the comment.

[mhammond]

I can't reproduce this with just desktop. If you follow the instructions in https://github.com/mozilla-mobile/fenix/issues/26406#issuecomment-1218564743, you can probably work out whether the problem you see if that desktop is not writing the new tab list, or whether Fenix is not picking it up.

[LaurentiuApahideanSV]

I tested the issue on Nightly 105.0a1 (2022-08-17) (mobile and desktop) and can confirm that when performing the steps from comment https://github.com/mozilla-mobile/fenix/issues/26392#issuecomment-1218466317 the issue still occurs. The issue does not occur when performing these steps between 2 mobile devices.

Devices used:

• Google Pixel 6 (Android 13)
• Samsung Galaxy S22 Ultra (Android 12)
• ASUS TUF A17 FA706QR (Windows 10)
• HP G5 (Windows 10)

[rocketsroger]

@mhammond Testing with about:sync I can see how it's hard to reproduce this issue. Switching to the about:sync tab triggers a sync most of the time (about 1 out of 10 times it doesn't). It is much harder to reproduce. When I can reproduce it, I see that in tab's Records (table) the record associated with the browser I'm testing is not showing the right URL.

How do I tell if the problem is because of browser not sending it or because of the server not receiving/storing the update?

[mhammond]

@mhammond Testing with about:sync I can see how it's hard to reproduce this issue. Switching to the about:sync tab triggers a sync most of the time (about 1 out of 10 times it doesn't).

Note that switching any tab will cause a 5 second timer to start, after which we sync. So I suspect that's what you are seeing when you say about:sync sometimes triggers a sync. Given the above, maybe this is the problem - it sounds like you are saying you can't reproduce the problem when the sync happens - is it possible you aren't waiting that 5 seconds?

When I can reproduce it, I see that in tab's Records (table) the record associated with the browser I'm testing is not showing the right URL.

How do I tell if the problem is because of browser not sending it or because of the server not receiving/storing the update?

The problem will never be the server - it will be either one client hasn't written the tabs, or the other client hasn't read the tabs. From what you said above, the problem here is that the client with the tab has yet to write it (ie, has yet to perform a sync), which again makes me think the problem is that the 5 second timer hasn't yet fired.

eg, it could be the following scenario: 1) you switch tabs, or open tabs etc on device 1. 2) device 1 starts a 5 second timer. 3) before that timer fires, you go to device 2, and it syncs (but doesn't see the tab change yet, as device 1 is yet to sync) 4) device 1's timer fires, it syncs tabs 5) device 2 hasn't synced again, so that newly written tab state doesn't appear.

As mentioned above, it's important to note that forcing a "sync now" on device 1 will not mitigate the problem - you must wait for that 5 seconds. We can probably fix that, but I think that's low priority - it's very rare, except in QA situations, where the user will be doing this within that 5 second window. But we can have that discussion once we are clear on what the issue is here.

[rocketsroger]

As mentioned above, it's important to note that forcing a "sync now" on device 1 will not mitigate the problem - you must wait for that 5 seconds. We can probably fix that, but I think that's low priority - it's very rare, except in QA situations, where the user will be doing this within that 5 second window. But we can have that discussion once we are clear on what the issue is here.

I see, thanks for the clarification. You're right, it's probably the 5 seconds of delay I am seeing. One question, is there a debounce period (where we don't start any timers) right after the 5 second timer expires and the sync happens?

[mhammond]

One question, is there a debounce period (where we don't start any timers) right after the 5 second timer expires and the sync happens?

Nope, the 5 seconds is the debounce.

[rocketsroger]

Confirmed when I see issue it's usually because I am navigating multiple sites within the 5 seconds timer. If this is expected limitation then this issue can be marked as fixed. I'll close. Thanks