I love the high level overview of Firefox View, but it also allows me to spot tabs I am done with relatively easily.

It would be nice if I could close those tabs remotely via Firefox View.

We don't have the capability to remotely close synced tabs in Firefox View, but we can give users the ability to hide any tabs they don't want to see. The only caveat (at this time) is that if they visit that tab again, it will show up again, because of how the API is designed.

Anna, Josh has given us the figma spec [https://www.figma.com/file/gbcRgA6Z8KtwmRSSgokZvl/Fx-View-2023---Iteration?node-id=2905%3A35262&t=04Irkh151A5JKba4-0] for this feature. Could you advise on how to handle the 'hide' button within the tab for keyboard navigation?

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

Anna, Josh has given us the figma spec [https://www.figma.com/file/gbcRgA6Z8KtwmRSSgokZvl/Fx-View-2023---Iteration?node-id=2905%3A35262&t=04Irkh151A5JKba4-0] for this feature. Could you advise on how to handle the 'hide' button within the tab for keyboard navigation?

Thank you for tagging me, Sarah!

The keyboard navigation would now need to be tabbing between controls, because arrowing (which is implemented in Nightly) is expected to be between similar elements (between list items, for instance). Tabbing would also be in accordance with the existent navigation pattern for the Top sites cards on about:newtab. It is more cumbersome especially for users with limited dexterity, but at the same time it is more intuitive pattern that should work better for this complex case and be easier to discover by keyboard users.

Similar keyboard navigation pattern change has been implemented with the bug 1787945, so the patterns within the Fx View would be consistent too.

Thanks for responding, ayeddi. I think my biggest concern with the keyboard navigation implementation of this update is that the entire card is actionable with a button within this card now also being actionable. Top Sites as well as the recent implementation for Recently Closed tabs have two distinct actionable areas you can focus rather than one inside of the other. It's not a scenario I've worked through before, but hopefully it'll be easier than I'm imagining.

(oops, duped the wrong one - sorry for the noise)

Even outside of keyboard navigation I guess, how would we click the Hide button without also triggering the click action for the entire card without absolutely positioning the Hide button on top of the card (which wouldn’t work here because I think we need the width the Hide button to determine the truncation of the card’s tab title).

(In reply to Kelly Cochrane [:kcochrane] from comment #6)

Even outside of keyboard navigation I guess, how would we click the Hide button without also triggering the click action for the entire card without absolutely positioning the Hide button on top of the card (which wouldn’t work here because I think we need the width the Hide button to determine the truncation of the card’s tab title).

The hide button's click handler can call event.stopPropagation(), which would stop the click handler for the entire card from running, I think (assuming the right bubble/capture bits). In the sense that the item is inside a link that has a default handler, we might also need to call event.preventDefault() to stop that link navigating.

Yeah that makes sense, Gijs. Thanks!

Oops. I didn't get a chance to look at this for a bit.

This bug has been repurposed for hiding tabs; but I did really originally open it because I see Firefox View as having potential for helping me clean up my tabs across my devices, as a central dashboard for all my tabs. I'll leave it to the view team if they want to open a new bug, and unsubscribe myself from this one.

Gijs, I've started the implementation here, but I have a few questions in terms of expected behavior. Are we expecting this dismissed tab to persist for a certain period of time? If so, what would be the best path for implementing that? Would we expect/want a previously dismissed tab to reappear in Tab Pickup if revisited on another device?

Looks like some of these questions were posed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1790853#c3, but it never really got discussed further.

Hey Kelly, you can find a lot of conversation on functionality here: https://docs.google.com/document/d/1VO_fhmEaxAew8d-hu4hsUbD84nNkDXKg9iogEGybr54/edit?usp=sharing

I believe the answers to your questions are:

1. Dismissed tabs stay dismissed unless a new sync entry is created
2. Revisiting a tab on another device creates a new sync entry so this would cause a previously dismissed tab to reappear.

Awesome, thank you Josh! I hadn't seen this before.

NewTabUtils' BlockedLinks.block could be reused, but its use case was a bit different as top sites would only show high frecency urls that should be a relatively stable and small set of potential urls. Tab Pickup probably will have a large variety of urls, so if many get blocked to permanently never see them again in new tab nor firefox view, the underlying storage as a url hashed into a map stored as json browser.newtabpage.blocked could grow.

Reusing the behavior should be fine if we indeed want to permanently hide certain pages like suggested in bug 1790853. However, if users just want to temporarily skip over some tabs to try to get at other synced tabs, a different approach might be desired such as an in-memory store that gets cleared on restart. Also, if we do reuse and urls get added permanently, it's a bit harder to untangle things to be temporary.

Josh, we've been discussing this some more, and think we could have dismissed tabs work similarly to dismissing Top Sites on the New Tab page. It creates a hash and adds it to a more permanent block list (accessible via browser.newtabpage.blocked in about:config). Previously dismissed tabs would then no longer reappear in the Tab Pickup list regardless of if they visited the same full url at a later time on their other device. Mardak has addressed some potential concerns with this route above, but I think we'll eventually want to give users a way to display a more complete list of synced tabs rather than 3 which would prevent the need to dismiss through tabs until you find the one you're looking for. We may even want to give them a way to "undo" dismissing certain tabs if we take this more permanent block list route.

(In reply to Kelly Cochrane [:kcochrane] from comment #15)

Josh, we've been discussing this some more, and think we could have dismissed tabs work similarly to dismissing Top Sites on the New Tab page. It creates a hash and adds it to a more permanent block list (accessible via browser.newtabpage.blocked in about:config). Previously dismissed tabs would then no longer reappear in the Tab Pickup list regardless of if they visited the same full url at a later time on their other device. Mardak has addressed some potential concerns with this route above, but I think we'll eventually want to give users a way to display a more complete list of synced tabs rather than 3 which would prevent the need to dismiss through tabs until you find the one you're looking for. We may even want to give them a way to "undo" dismissing certain tabs if we take this more permanent block list route.

For additional context, through some code discovery Gijs found out that Fenix doesn't appear to temporarily hide dismissed Sync tabs, so doing it the way Kelly suggested would align with how Fenix dismisses synced tabs (although I think the language there is "Remove"). Also Markh from the sync team might have thoughts here.

Seems like this convo is happening two places at once. Bringing my comments from the google doc to here.

We might want to change the language to map to the functionality. If it will never appear again I would say remove is like more appropriate. I would also say if there is a block list there should be a way to remove URLs from the block list which starts to make things more complicated. While we technically do have this available I would say anything in about:config is advanced functionality most users wont mess with.

Also I want to be careful about conflating the purpose of hide with the need for more tabs. Right now dismissing a tab could be a workaround to access more tabs, but i wouldnt assume that's the intended functionality. Even in a future where there is better access to more/all synced tabs, the dismiss functionality will be useful for controlling what content appears on this page in shared physical spaces (at work for example).

Based on a chat with Perla, Sarah, Kelly and Emanuela, we're moving forward with the functionality Kelly described above: "Previously dismissed tabs would then no longer reappear in the Tab Pickup list regardless of if they visited the same full url at a later time on their other device." Given the action will be a little more 'permanent' than previously discussed / designed, the string for this action should be Remove rather than Dismiss. This keeps it consistent with terminology used elsewhere on the same surface - removing recently closed tabs.

Will also note that we've decided to store these url hashes separately from the existing browser.newtabpage.blocked string and instead store them similarly using a new pref (like browser.syncedtabs.blocked or something similar). Removing a synced tab from Tab Pickup should also remove it from elsewhere in the browser where synced tabs are shown.

We will also be adding telemetry similarly to how we've implemented it here as part of this update.

Josh, just wanted to give you a heads up that we've decided to actually go with the word "Remove" if you'd like to bring the Figma file in line.

Note that using the full URL might not do what user's expect. Eg, I'd imagine that I'd personally use this to try and hide slack, calendar, etc, but using the complete URL would probably mean this would not work (or worse, only appear to work sometimes)

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

Note that using the full URL might not do what user's expect. Eg, I'd imagine that I'd personally use this to try and hide slack, calendar, etc, but using the complete URL would probably mean this would not work (or worse, only appear to work sometimes)

:markh, yeah there was some discussion in the document. I could see arguments for both sides honestly. :sclements brought up her concern in the document:
"Someone might not want to see www.developer.mozilla.org/<someSpecialPage> but might want to to still see www.developer.mozilla.org/ and www.mozilla.org/ or www.developer.mozilla.org/<anotherPage>."

I doubt there's a correct answer here - 2 URLs on developer.mozilla.org is probably seen by some users as 2 discrete pages. 2 URLs on slack is probably seen by some as the same page (ie, typically just means a different channel/thread is selected on what looks like the same page).

Depending on the implementation plan, an option might be to ask the user if they want to remove the site or the url? My main point though was to make sure this edge-case was considered and I'm happy to hear it was, thanks.

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

I doubt there's a correct answer here - 2 URLs on developer.mozilla.org is probably seen by some users as 2 discrete pages. 2 URLs on slack is probably seen by some as the same page (ie, typically just means a different channel/thread is selected on what looks like the same page).

Depending on the implementation plan, an option might be to ask the user if they want to remove the site or the url? My main point though was to make sure this edge-case was considered and I'm happy to hear it was, thanks.

Yeah, the plan after talking to Katie, Perla and Emanuella is to build upon this in the future (give users some more fine-grained privacy control and likely the ability to unblock urls, which was also Josh's concern), so I think this is really just an immediate first step to address privacy concerns.

Removing needinfo. Thanks!

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

Yeah, the plan after talking to Katie, Perla and Emanuella is to build upon this in the future (give users some more fine-grained privacy control and likely the ability to unblock urls, which was also Josh's concern), so I think this is really just an immediate first step to address privacy concerns.

The initial report here was related to relevance, not privacy - ie, the reporter wanted the ability to close tabs once they are "done" with them. This then transformed into "we can't close them, how about we hide them?" as a vehicle for trying to ensure the 3 tabs Firefox View shows are relevant.

For that use-case, I don't think it follows that the tabs should be hidden from all surfaces - the fact I might not want slack on Firefox View certainly doesn't mean I don't want it ever shown as a remote tab in places where there are no size constraints.

Re the privacy argument - I can't see any evidence there's an actual use-case there - if there was, it would have been raised over the years that synced tabs have existed - but that request/concern has never come up. The tab will still appear in autocomplete etc, and quite probably in the new tab page due to history syncing, so if privacy is a driver it will need more thought than just hiding the synced tab.

The initial request (to close remote tabs) has come up before though - bug 1330816 - and the use-cases there are all about closing "obsolete" tabs, not about privacy. That bug is something we could scope out if product wanted it treated as a priority.

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

The initial report here was related to relevance, not privacy [...] Re the privacy argument - I can't see any evidence there's an actual use-case there - if there was, it would have been raised over the years that synced tabs have existed - but that request/concern has never come up.

Counterpoint: it has come up. My dupe bug 1790853 focused on the privacy argument. It was duped here, but perhaps we should un-dupe it if we want to consider it separate?

The tab will still appear in autocomplete etc, and quite probably in the new tab page due to history syncing, so if privacy is a driver it will need more thought than just hiding the synced tab.

That might be an issue, yeah.

Notably, all of those other contexts (autocomplete, new-tab-page, and also the Show All History window) each offer their own UX for deleting the unwanted site from your history. I suppose our "Synced Tabs" menu UI doesn't offer that, but that menu is also not as obvious/discoverable as Firefox View intends to be.

Anyway: from my perspective, a potentially-ephemeral "Remove" option is fine for the scenarios in my dupe bug. If someone really wants to purge an embarrassing site from their history, they will likely want to dig in a bit deeper and we don't want to build that UX into Firefox View. I was mostly focusing on having a quick intervention available for someone who's e.g. about to do a screencast or have shoulder-surfers, and realizes that a prominent piece of Firefox UI is surfacing a piece of history that they consider to be sensitive for whatever reason.

Adding bug 1801295 as a blocker. When removing a synced tab, there are some instances where it looks like you suddenly drop from 3+ to 0 tabs, when that's not the case. This was a preexisting issue, but it's much easier to see/reproduce with this "remove synced tabs" update.

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

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

The initial report here was related to relevance, not privacy [...] Re the privacy argument - I can't see any evidence there's an actual use-case there - if there was, it would have been raised over the years that synced tabs have existed - but that request/concern has never come up.

Counterpoint: it has come up. My dupe bug 1790853 focused on the privacy argument. It was duped here, but perhaps we should un-dupe it if we want to consider it separate?

(On further thought, I don't actually think we should un-dupe bug 1790853 -- it'd be better to just start fresh with a new bug to cover whatever additional privacy-focused followup work that we want to add in this area.)

Emanuela, are we okay to isolate this removal of synced tabs functionality to just the Tab Pickup area in Fx View for now? :markh had some concerns with applying it to other surfaces that he brought up in comment 27.

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

(In reply to Sarah Clements [:sclements] from comment #25)
The initial report here was related to relevance, not privacy - ie, the reporter wanted the ability to close tabs once they are "done" with them. This then transformed into "we can't close them, how about we hide them?" as a vehicle for trying to ensure the 3 tabs Firefox View shows are relevant.

You're right, and unfortunately I've caused some confusion here by duping the original privacy bug 1790853 which was the primary driver behind hiding the synced tabs. You can see the lengthy conversation about how to implement it in the doc Kelly linked to, which to some degree explains the evolution of hiding to dismissing/blocking. Even though this bug has morphed in a less-than-ideal way, there's enough relevant conversation that it doesn't make sense to file a new bug just for the privacy angle. Let's keep this bug as-is and I'll file a bug to address the remote closing of tabs in Firefox View specifically.

Re the privacy argument - I can't see any evidence there's an actual use-case there - if there was, it would have been raised over the years that synced tabs have existed - but that request/concern has never come up. The tab will still appear in autocomplete etc, and quite probably in the new tab page due to history syncing, so if privacy is a driver it will need more thought than just hiding the synced tab.

In addition to the bug that Daniel filed, we've implemented the removal of tabs for Recently Closed tabs in Firefox View (see bug 1787945). Both of these bugs address privacy concerns specifically about Firefox View that were brought up in foxfooding.

The initial request (to close remote tabs) has come up before though - bug 1330816 - and the use-cases there are all about closing "obsolete" tabs, not about privacy. That bug is something we could scope out if product wanted it treated as a priority.

I guess I'm a bit confused about which PM's would be prioritizing it (Vesta since it's a sync wide thing, or the View PM's?).

UX is currently conducting user research of how people use Firefox View. AIUI, that information will be used to redesign aspects of the Tab Pickup section, which may very well address the original request for this bug. If that's the case, we can reach out about that.

Comment on attachment 9307903 [details]
Firefox View Data Collection Request.txt

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, :kcochrane is responsible.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction.

Is the data collection request for default-on or default-off?

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does the data collection use a third-party collection tool?

No.

Result: datareview+

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

Even though this bug has morphed in a less-than-ideal way, there's enough relevant conversation that it doesn't make sense to file a new bug just for the privacy angle. Let's keep this bug as-is and I'll file a bug to address the remote closing of tabs in Firefox View specifically.

I don't want to labour this too much, but I don't agree that it makes sense to conflate the privacy considerations (as described in the dupe) and the "only show relevant tabs" as described in this bug. They have significantly different characteristics in terms of remediation. In particular, Firefox View did not introduce these privacy considerations (synced tabs in the browser always had them even if Firefox View did make them more noticeable for users of that surface) whereas the "only show relevant tabs" request is purely a Firefox View consideration (all other surfaces show all tabs whereas Firefox View often shows exactly 1 from a device)

Re the privacy argument - I can't see any evidence there's an actual use-case there - if there was, it would have been raised over the years that synced tabs have existed - but that request/concern has never come up. The tab will still appear in autocomplete etc, and quite probably in the new tab page due to history syncing, so if privacy is a driver it will need more thought than just hiding the synced tab.

In addition to the bug that Daniel filed, we've implemented the removal of tabs for Recently Closed tabs in Firefox View (see bug 1787945). Both of these bugs address privacy concerns specifically about Firefox View that were brought up in foxfooding.

As I mentioned though, IMO they address the privacy considerations poorly in the context of the rest of the browser. So I don't really object to hiding it in Firefox View if you think that addresses Firefox View considerations, but I don't think we should say we are addressing the broader privacy considerations when we aren't considering the broader context (eg. about:newtab, awesome bar, etc). Are there any stats for how often about:newtab is viewed versus Firefox View?

UX is currently conducting user research of how people use Firefox View. AIUI, that information will be used to redesign aspects of the Tab Pickup section, which may very well address the original request for this bug. If that's the case, we can reach out about that.

That's fantastic, but if that research is limited to Firefox View, the default position IMO should be that outcomes should be limited to Firefox View and not extrapolated to places which were not considered.

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

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

As I mentioned though, IMO they address the privacy considerations poorly in the context of the rest of the browser. So I don't really object to hiding it in Firefox View if you think that addresses Firefox View considerations, but I don't think we should say we are addressing the broader privacy considerations when we aren't considering the broader context (eg. about:newtab, awesome bar, etc).

I don't recall anyone making this claim about the privacy considerations. I think we should have a chat outside of this bug; I'll schedule a 1:1.

I'm going to close this bug after meeting with Product (including Vesta) and UX since its caused confusion, and they want to reevaluate how to implement this feature (it's on hold for now). I've captured this original request in bug 1805254, and I'll reopen the privacy bug for posterity.

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

I'm going to close this bug [...]
I've captured this original request in bug 1805254, and I'll reopen the privacy bug for posterity.

Thanks!

Minor bit of tidying, hopefully not stepping on toes: given that we've got bug 1805254 open to capture the same request as in this bug here, a "wontfix" resolution here doesn't make sense. (WONTFIX implies we-would-not-land-a-fix-to-address-the-issue-that-was-described.) It seems like we're using bug 1805254 as a clean slate to cover the same thing originally requested here, so let's change the closed-bug-resolution here from "wontfix" to "dupe of bug 1805254", to express that the original request is still under consideration, over on bug 1805254.

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

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

I'm going to close this bug [...]
I've captured this original request in bug 1805254, and I'll reopen the privacy bug for posterity.

Thanks!

Minor bit of tidying, hopefully not stepping on toes: given that we've got bug 1805254 open to capture the same request as in this bug here, a "wontfix" resolution here doesn't make sense. (WONTFIX implies we-would-not-land-a-fix-to-address-the-issue-that-was-described.) It seems like we're using bug 1805254 as a clean slate to cover the same thing originally requested here, so let's change the closed-bug-resolution here from "wontfix" to "dupe of bug 1805254", to express that the original request is still under consideration, over on bug 1805254.

*** This bug has been marked as a duplicate of bug 1805254 ***

Good point, thanks!