I unfortunately don't have STR; but I just noticed that the Firefox View page in all of my Firefox windows on my linux laptop are currently showing:
Sit tight while your tabs sync. It’ll be just a moment.
...and have been showing it for about 10 minutes. (I noticed it 10 minutes ago and it's still like that.)

Meanwhile about:sync-log shows that I had a successful sync 11 minutes ago (from 1 minute before I thought to check Firefox View and noticed this issue).

Also, History | Synced Tabs shows me a nice list of up-to-date synced tabs.

Nothing particularly interesting shows up in browser console or in web console for my Firefox View tabs. New windows & new about:firefoxview tabs show this issue as well.

So it looks like there's some sort of mismatch where Firefox View mistakenly thinks that we're syncing but in fact we're not. (?)

I'm on Ubuntu 22.04, with Firefox Nightly 106.0a1 (2022-09-08) (64-bit)

....and of course, right as I filed this bug, the issue went away (and about:sync-log shows me a new "success-sync" entry with last-modified-date about 10 minutes after the previous one.

So: it seems like it's somehow possible for Firefox Sync to perform a sync, and then the next visit to Firefox View to show "Sit tight" until the next sync happens, which it might not for 10min or so.

Nonetheless I'm continuing to run into this throughout the day. Seems like most of the time when I view Firefox View today, it's stuck in this "Sit tight" view for minutes at a time.

Not sure if there was a recent regression with populating this section, vs. something else.

Let me know if there's anything I can do to help diagnose/investigate here.

I think this is basically a dupe of bug 1787975? The additional detail and esp if you could provide more of the sync log details could be useful though...

Seems related at least, yeah. Though that bug seems to be about this issue happening "after adding a new device", though in my case I haven't added a new device recently. (The last time I signed in to Sync in a new browser-profile was a week or more ago, I think.)

FWIW my pretty-reliable STR are:
(1) Restart Firefox
(2) do not look at Firefox View at all (I'm not sure if this is important but I suspect it might be important)
(3) Open about:sync-log, click the right column header to sort by date, and make sure a "success-sync" log appears with a last-modified-time from just now (after you started Firefox in step 1)
(4) Now, switch over to your Firefox View.

For me, the Tab Pickup section remains in "Sit Tight" for quite a while at this point. The last few times I've tried, it's only been on the order of a minute or so, but earlier today it was longer. In any case, it stays "Sit Tight" until my next sync; it seems not to use any tabs-from-other-devices info from my just-completed sync. So we're entirely at the mercy of when-my-next-sync occurs.

Looking at my sync logs from earlier today, it looks like those were scheduled 10 minutes (600000ms) apart. For the sync that finally helped me get out of this situation in comment 2 here, the log starts with Next sync in 600000 ms. (why=schedule) (I think that's describing the scheduling that kicked off that sync itself, though I'm not entirely sure?)

vs. my sync logs from just now from following my STR from the top of this comment, I see Next sync in 90000 ms. (why=schedule). So it seems like sometimes we get a 90-second scheduled sync (sometime after the initial startup-triggered sync).

90 seconds still seems like a longish time to wait to populate this UI, though.

(I do have about:sync installed and will gladly pull logs/info from there, though I'll tend to avoid posting it publicly.)

markh, do you know what's going on here & do you have any suggestions for things I might check? Does my described behavior in comment 6 make sense? (In particular, are we expecting Firefox View to more proactively use synced tabs from "quite recent" syncs when it's first loaded? That doesn't seem to happen for me right now... And is it expected that Firefox View just stays in this "Sit Tight" state until the next scheduled sync happens which is potentially 90s or 10min away?)

Kind of guessing, but based on my experience & the timestamps on my sync logs, it looks like:
(1) when I start Firefox, I get a synchonous sync
[after this one, Tab Pickup pretty much always says "Sit Tight"]

(2) 90 seconds later, I seem to always get a scheduled sync
[after this one, Tab Pickup works for me, but only for a few minutes; then it returns to "Sit tight"]

(3) 10 minutes later, I get another scheduled sync. This repeats every 10 min from this point on, I think.
[again, Tab pickup works for a short period of time after this, but then returns to "Sit Tight" until the next sync 10min later]

Looking in about:config, I see that I have about:config pref services.sync.syncInterval set to 600000 (10min) -- I don't know if I set that at some point in the past or if that was set for me. But presumably that's related to the 10min scheduled sync interval that I've noted above here.

I also see that I have services.sync.syncThreshold set to 300 (not as sure what that does or if it might be relevant).

(In reply to Daniel Holbert [:dholbert] from comment #9)

Looking in about:config, I see that I have about:config pref services.sync.syncInterval set to 600000 (10min) -- I don't know if I set that at some point in the past or if that was set for me. But presumably that's related to the 10min scheduled sync interval that I've noted above here.

IIRC this gets updated by sync depending on whether the machine/Firefox is in active use etc. - it's not actually "user set".

Are you using a self-built nightly? What is the value of services.sync.syncedTabs.syncDelayAfterTabChange, and is there any interesting browser console output from setting services.sync.log.logger.engine.tabs to "All"?

Most of the discussion above sounds normal - unless asked otherwise, we sync every 10 minutes (that syncInterval pref) or when certain local chings change enough to warrant a sync (the syncThreshold) - but none of that should be relevant for synced tabs in either the hamurger menu or in Firefox View - they ask to sync now and we do (apart from debouncing to ensure we don't sync more often than once ever 30 seconds). In short, your prefs should not be able to impact the behavior in the context of this bug.

This is a "lock" though, so if a sync is in progress (for anything, eg, history) then we can't sync tabs. In thus bug and bug 1787975, it sounds like sync itself might be getting "stuck" somehow. If you can zip up your sync logs (the about:sync addon can do this, or you can find them in your profile directory) I can probably get some idea if what might be going on. We do tend to be privacy conscious in the logs - things like URLs of bookmarks and history are likely to appear if your logs are at "trace" level (which about:sync does set for you), but by default they should not appear.

(The most recent comments in bug 1789876 imply that there's a possibility that there's simply a bug in Firefox View - the tabs have appeared, but Firefox View isn't seeing them. I suspect these bugs are all related though)

(oops, meant to say - feel free to email me the logs)

I hit this again today. Things were fine for the first couple times I checked Firefox View (various points in the morning), but at around 12:58pm, which happened to be right after a scheduled "every 10 minutes" sync, I happened to check Firefox View right and I noticed it stuck on "Sit Tight" for at least a few minutes. My next (successful) sync log was from 10 minutes later (based on its final last-modified datestamp), and I happened to check Firefox View again just after that time, and the Tab Pickup section was populated by that point.

I emailed logs from before/during this period to markh in case he can glean any useful info from them.

• dispatch an event from TabPickupList when we get recent tabs data from SyncedTabs.jsm
• and forward that along to TabsSetupFlowManager, where we can use it in the 'synced-tabs-not-ready' exitConditions to pass through the loading/waiting state as soon as we have something to show

FTR, I got the logs and emailed this to Daniel:

All those logs look quite normal. Unfortunately, I think you were bitten by https://bugzilla.mozilla.org/show_bug.cgi?id=1789876 - which despite the bug title, was impacting you - the logs show lots of:

2022-09-10 06:01:26.363000 (15:04:16.465) Sync.RemoteTabs INFO Can't sync tabs due to the login status: success.login

Which was a regression introduced by me about a week ago 🙁 The fix landed in Nightly over the weekend, so hopefully you will see it magically go away.

https://hg.mozilla.org/mozilla-central/rev/6af5e9e9d203

Hello,

Managed to reproduce this issue on 106.0a1(20220908213354) with an Ubuntu 22 using the repro steps from comment 6.

Confirming this issue as verified fixed on 106.0b2(20220920185943) using macOS 12, WIndows 11 and Ubuntu 22.

I was also unable to reproduce this issue anymore on Nightly 107.0a1(20220920092542).