If we have cached recent synced tabs data, we should be able to show that almost instantaneously if firefox-view is opened shortly after startup. But the "Sit tight while your tabs sync" loading message is visible for several seconds instead.

I'm now not able to reproduce. There is the potential in tab-pickup-container.mjs to toggle the loading class on when we mean off if the isLoading variable is undefined rather than false. I had seen exactly that while testing earlier - but that was possibly an artifact of a locally applied WIP patch.

I'll leave this open for a little bit in case I or anyone else can repro. Note this is a distinct case from bug 1792040, where the bug is that we show 0 tabs instead of a) existing cached tabs or b) a waiting message while we get synced-tabs from the newly connected device.

[I fixed typos in the summary and comment #0 where I'd confusingly typed 'nothing to see yet' instead of the loading message.]

I have lately sometimes seen the "Nothing to show yet" message when running the local build and doing a hard refresh/rebuild. It'll do that, then if I hit refresh, I see the sync message and loading spinner, and then I see the same tabs as before.

On currently nightly, if I update and restart I have also seen the loading spinner for a second or 2 before showing tabs. Also, now if you do a refresh that also shows the sync tabs spinner for a moment before loading the same cached tabs. I can look into this more.

(In reply to Sarah Clements [:sclements] from comment #2)

I have lately sometimes seen the "Nothing to show yet" message when running the local build and doing a hard refresh/rebuild. It'll do that, then if I hit refresh, I see the sync message and loading spinner, and then I see the same tabs as before.

On currently nightly, if I update and restart I have also seen the loading spinner for a second or 2 before showing tabs. Also, now if you do a refresh that also shows the sync tabs spinner for a moment before loading the same cached tabs. I can look into this more.

Showing 0 tabs when we actually have tabs to show is definitely a bug. I assume that's what you mean. But it is likely fixed (or at least substantially changed) by WIP on bug 1792040. We should probably re-test after that lands to see if there are cases not addressed which still reproduce.

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

Showing 0 tabs when we actually have tabs to show is definitely a bug. I assume that's what you mean. But it is likely fixed (or at least substantially changed) by WIP on bug 1792040. We should probably re-test after that lands to see if there are cases not addressed which still reproduce.

Sounds good.

This is annoyingly difficult to reproduce. I have seen it only happen once or twice since my previous comment two days ago despite multiple attempts and I'm unable to catch it in the debugger when it happens. I think we might want to re-evaluate the priority on this, considering that its not really broken and it happens inconsistently. Ray, what do you think?

Thanks for the flag Sarah. Totally OK with deprioritizing due to the infrequent nature of this bug.

I took another look at this and I can't reproduce it anymore. Sam, I'm curious if you've seen it recently (or anyone else following this bug). If not, perhaps we can close it out for now and reopen if needed.

I'm happy to dupe this over to bug 1792040. The STR are a little different, but its the same root cause that I think will be addressed by the patch on there.