User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Actual results:

It seems like the new Tab Pickup feature in Firefox 106 includes pinned tabs. This makes the feature less useful since pinned tabs are usually not ones I want to share between devices - furthermore, I have about half a dozen pinned tabs on all my devices meaning that I never actually see tabs I may want to move over.

Expected results:

It would make more sense to simply not include pinned tabs under Tab Pickup - making the feature work better for its indented purpose of letting you quickly share temporary tabs between devices.

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

AFAICT on the receiving side we can't currently tell which tabs were/weren't pinned, and adding that information would be something that'd need to happen in sync code in the first instance. We can't just change the desktop clients to not send the pinned tabs because that'd probably be unexpected for other surfaces. FxView was primarily designed for mobile tabs, which don't support pinning in the first place.

I don't know anything about how the backend works here, but would another approach be to simply reverse the order in which the shared tabs are displayed in Tab Pickup? Since pinned tabs are always shown first, guessing that would have the same effect and the cutoff would then happen before you get to the pinned tabs if there's more than 3.

(In reply to Ivar Hill from comment #3)

Since pinned tabs are always shown first,

I don't think this is the case in general? The sort order is governed by the time since the tab was last accessed (selected / foreground tab). There's a known issue with background windows (bug 1756851), but not with pinned tabs as such, as far as I'm aware.

Presuming this is what you're seeing, it would be useful to know more about your setup (how many devices, how many windows, how many tabs / pinned tabs, are the pinned tabs often also selected?).

simply reverse the order in which the shared tabs

So that wouldn't work because we'd show your least-recently-accessed tabs first, which are probably the least useful.

Another interesting question (well, I think it's interesting anyway...) is whether you have similar pinned tabs on all your connected desktop (non-phone/tablet) devices.

Oh, I might have misunderstood how the feature works then. After checking more closely, it indeed works the way you describe and indeed that makes my earlier suggestion irrelevant.

For what it's worth I'm currently using two desktops and a laptop (and no other devices), all of them with the same 6 tabs pinned. Since those are indeed very often selected, I rarely if ever actually see any non-pinned tabs that I may want to move over. Of course I can still move tabs over manually through the account menu but it does mean that the Tab Pickup section of Firefox View is essentially pointless for my workflow.

I see what you're saying about it being tricky to change though, it makes sense. Maybe enough people don't use pinned tabs much that it still stays useful for many!

Right, but if the pinned tabs are similar across devices, perhaps a URL-based filter could be used so we don't show tabs with domains that match domains of pinned tabs on the local machine, or something.

That would make a lot of sense, even more generally speaking since even if not pinned, there's no reason to show a tab that is the same as one you already have open. And indeed it would solve my particular issue as well since the pinned tabs I got are all the same on all devices.

FTR, it wouldn't be too difficult to have desktop add a "pinned" attribute to synced tabs, but that's not a panacea and I like the idea of "smarter" deduping.

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

perhaps a URL-based filter could be used ...

I agree - a naive "dedupe exact URLs" will probably not be good enough IMO - my slack/calendar/etc pinned tabs have different URLs on each device (different thread/event/message etc) - so I'm adjusting the title to be more vague. I suspect heuristics might be tricky though (eg, I've many bugzilla tabs but probably do want fairly strict URL matching there) - maybe we should move ahead with a new "pinned" attribute as well in case this gets very tricky?

OTOH - I'm now having second thoughts :)

For my use-case and bugzilla tabs: If I just had a bugzilla bug open on my laptop, I would still want it in my "tabs pickup" list, even if it's already open locally- I've probably forgotten where it is locally.

Pinned sites from other devices should still only appear if they are in the 3 most recent tabs from the other device - that's still a reasonably strong signal it's relevant. Maybe we should just be switching to the pinned tab instead of hiding it?

(We should probably check there's no bug with pinned tabs updating their last-used timestamp etc - that if pinned-tabs show, they really were the most recent tab(s) on that device [edit], but I've never noticed that)

Since there's a few different ideas floating around we should probably get product and UX involved...

Some of the ideas that I can see are:

1. General deduping of tabs across all devices with exact urls
2. General deduping of tabs across all devices with exact domain
3. Adding a "pinned" attribute to desktop devices and filter only by that attribute but again, would this be by domain or exact url matches?

If we only focused on pinned desktop tabs, that might miss a tab that's open but not pinned on other devices as well (mobile, tablet, and even another desktop device).

I think 1 and 2 are more aligned with the user request per the conversation in the this bug.

Thanks for the tag. I think this is all good conversation. Adding additional UX stakeholders, because I think this could be a great candidate for concept/usability testing.

Picking this thread back up. I think that we can focus initially on the first two areas in Sarah's summary above for immediate action. It seems like this would naturally take care of the example concern, right? i.e. I have the same pinned tabs across devices "open/selected"

(In reply to Ray Fambro from comment #13)

Picking this thread back up. I think that we can focus initially on the first two areas in Sarah's summary above for immediate action. It seems like this would naturally take care of the example concern, right? i.e. I have the same pinned tabs across devices "open/selected"

We could certainly start with removing synced tabs with the exact url. Where it gets tricky is removing a dupe of a domain. I don't think we want to do that across the board, even within the constraint of whether its pinned. If "https://developer.mozilla.org/en-US/" is pinned on one device, and "https://bugzilla.mozilla.org/" is pinned on another - we'd end up removing one of those. Would removing a dupe by subdomain be OK if it's pinned? Maybe this is where we could get UX/UR involved.

As Mark was saying, it sounds like a "pinned" attribute could be added to synced tab data for desktop, but that doesn't help if you have a tablet and mobile device with the same url (unless we do general deduping of urls).

This leads me to another question though, about how much we want behavior dedicated to Sync to apply across all surfaces that show synced tabs. If we dedupe urls for synced Tabs in Firefox View, it'd probably make sense for that to be reflected in other surfaces. Mark, any thoughts on this?

I think the key distinction here is that all tab surfaces show all tabs, so dupe tabs are a minor annoyance but don't prevent the user finding the tab they want. Firefox View limits the number of tabs shown to what it decides are only the "important" ones so it makes sense to dedupe more there IMO.

Let's proceed here by deduping tabs across devices with exact url matches. This should apply to the FxView surface as well as the other Sync surfaces in the browser (i.e. Application Menu FxA account surface, Sidebar - Synced Tabs surface).

FYI, it looks like we might be implementing bug 1330816 - quite possibly starting in q1, but discussions with Ania are still a little up in the air about that.

(In reply to Ray Fambro from comment #17)

Let's proceed here by deduping tabs across devices with exact url matches. This should apply to the FxView surface as well as the other Sync surfaces in the browser (i.e. Application Menu FxA account surface, Sidebar - Synced Tabs surface).

This implementation will cause some complications for that bug - the user will be unable to close a tab on DeviceA if it only being shown in DeviceB due to this de-duping. Or maybe that other bug morphs into "close tab on every device"? Maybe we should drop grouping by devices entirely?

In addition to Mark's concern above, he's also pointed out that we should still show a client in the list (in the Synced Tabs area of the menu) if it now appears to have no tabs as they were duplicates that were removed. We may need to add separate messaging there to prevent confusion. The current messaging says "No open tabs" which is technically not accurate in this scenario.

Here's an example where I have Facebook open on my Android device as well as my Macbook Air, with the most recently used one being on my Macbook Air. It now says "No open tabs" under the Firefox for Android client, but we'll probably want to adjust the messaging in this case, although to what I'm not sure.

One option is to keep this de-duping for Firefox View for now, to get around the limitation of three tabs where two of them might be dupes. And then reevaluate this implementation when the Firefox View layout changes (if tabs are separated out by device which is what I've seen in some concepts, we can then revisit how or if this would be a global sync change and address the issues Mark pointed out).

Yeah, Sarah, I think that might be the best option to move this along. Ray and I just discussed some more and agreed we should isolate this to Tab Pickup in Fx View for now. Mark (and potentially others from other teams) should have a discussion at some point about how we could work through implementation of this de-duping for other Synced Tabs surfaces given updates such as bug 1330816. Good call out, Mark, and thanks for bringing that to our attention!

Hi Kelly,
The other surfaces don't really have the same size constraints Firefox View does, so I'd suggest we just de-dupe per device, meaning it's fine that the same tab does appear multiple times, but each time will be for a different device.

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

Hi Kelly,
The other surfaces don't really have the same size constraints Firefox View does, so I'd suggest we just de-dupe per device, meaning it's fine that the same tab does appear multiple times, but each time will be for a different device.

I don't think that addresses the issue in this bug though, where someone saw the same (pinned) tab from multiple devices in Firefox View.

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

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

Hi Kelly,
The other surfaces don't really have the same size constraints Firefox View does, so I'd suggest we just de-dupe per device, meaning it's fine that the same tab does appear multiple times, but each time will be for a different device.

I don't think that addresses the issue in this bug though, where someone saw the same (pinned) tab from multiple devices in Firefox View.

Yeah I also think it may cause some confusion to de-dupe across all clients/devices in Fx View, but then only de-dupe per each device/client elsewhere in the browser? Either way I think we should have some further discussion before updating synced tabs out side of Fx View.

IMO:

• We should probably remove per-device dupes in synced tabs in general, because (a) there doesn't seem any value in having them and (b) it seems like it would allow sane semantics for bug 1330816, otherwise the user will not know which tab is going to be closed. As mentioned though, this doesn't help FxView so probably should be its own bug.

• FxView should arrange to never show the same URL in the 3 it shows (which seems like it would be a much simpler algo than deduping the entire set of tabs, but that's an implementation detail.) This also allows for a more flexible definition of "dupe" if desired (eg, never show the same origin) without that decision impacting the tabs menu or sidebar etc.

Appreciate the feedback here Mark as always! One thing we should probably call out however is that the next iteration of FxView will expand beyond just 3 tabs in the UI.

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

IMO:

• We should probably remove per-device dupes in synced tabs in general, because (a) there doesn't seem any value in having them and (b) it seems like it would allow sane semantics for bug 1330816, otherwise the user will not know which tab is going to be closed. As mentioned though, this doesn't help FxView so probably should be its own bug.

• FxView should arrange to never show the same URL in the 3 it shows (which seems like it would be a much simpler algo than deduping the entire set of tabs, but that's an implementation detail.) This also allows for a more flexible definition of "dupe" if desired (eg, never show the same origin) without that decision impacting the tabs menu or sidebar etc.

Yeah I've already got a patch up to de-dupe across all devices/clients which I think, to Ray's point, might be better in the long run considering we're planning on showing more than 3 synced tabs in Tab Pickup in the next iteration.

And yeah I agree that de-duping synced tabs outside of Firefox View / Tab Pickup should be handled in a separate writeup.

Thanks as always for your input, Mark!

https://hg.mozilla.org/mozilla-central/rev/63481d910f2c