Found in

• 109.0a1 (2022-12-15)

Affected versions

• Firefox Nightly 109.0a1 (2022-12-15)

Affected platforms

• All

Steps to reproduce

1. Open and Close a few tabs.
2. Reach the Firefox View page.
3. Use the Middle Mouse Wheel to click any of the links from the Recently closed tabs.

Expected result

• Users should be able to open those links in a new tab without focusing the tab.

Actual result

• Mouse Wheel will turn into Scroll wheel when clicking any links from the Firefox View page.
  When we close a lot of tabs and we want to reopen multiple specific links, users are forced to Left Mouse click each link open it in a new tab focus that new tab and then go back and scroll through the Firefox View page for the other links.
  When we want to open multiple links this becomes tiring.

Regression range
No

Anna -- Wanted to get your insight on this one. It looks like the scrollwheel behaves the same on every item within Firefox View. But this does not match the functionality of the scrollwheel elsewhere in the browser. My assumption is that we should fix this in View?

(In reply to Ray Fambro from comment #1)

Anna -- Wanted to get your insight on this one. It looks like the scrollwheel behaves the same on every item within Firefox View. But this does not match the functionality of the scrollwheel elsewhere in the browser. My assumption is that we should fix this in View?

To be fair, I do not even know if it is an expected behavior. And I've never heard about testing it during accessibility audits. My first instinct is that we would want to follow the Fx pattern for consistency reasons at least.

Maybe Jamie could be more helpful here?

I'm not familiar with this scroll wheel behaviour. I'm guessing that clicking the scroll wheel is similar to right clicking a link and choosing Open Link in New Tab?

Interestingly, I can right click on the Tab pickup links and see "Open in New Tab", but this option is not available in the context menu for Recently closed links. I'm guessing this is due to the way these are implemented (Recently closed aren't actually links). Does this same difference not apply to clicking with the scroll wheel? I don't understand why it wouldn't, but i get the impression from comment 2 that they all behave the same way.

Anyway, I don't really see this as an issue that disproportionately affects users with a11y needs, more a UX issue that equally impacts everyone. I guess lack of consistency impacts users with cognitive disabilities more than it does some others, but I'd guess that's only slightly relevant in this case.

If this is something you want to address in Firefox View, I'd guess an s3 at highest (because there is a clear, simple workaround), maybe even an s4. I see this is already rated s4 and I don't see any strong reason to disagree with that.

Since, as Jamie pointed out, the recently closed tabs aren't treated as links I don't know if this is something we should fix. I know Gijs has been involved in numerous conversations in the past about links vs buttons and what behaviors the recently closed tabs should have so I'm curious what he thinks about this.

Yeah, this keeps coming up. Closed tabs aren't links in a number of ways:

• they restore state other than just a URL (where the page is scrolled to, form input state, back/forward history for that tab, container, etc. etc.)
• they are associated with a specific position in the tabstrip
• because of this, it's possible for the same URL and/or URL+title combination to occur multiple times in the list
• also because of this, it's possible for "new tab" to appear in the list (if there are other history items that would be restored for that tab)
• all the other pre-existing surfaces effectively treat this and the non-closed tabs as two buckets - closing or undo-closing moves the tab from one bucket to the other.

We could make Firefox View treat closed tabs differently and "pretend" they are just links, but it's very unclear how that would work. What happens if you open the item in a new window/tab (do we lose the tabstrip position? What about the history and other information?)? What happens if you do the same but in a private window (which loses container information, which also means you could lose login state etc.)? In either case, do we remove the item from the list? What about using the context menu to just copy the URL or send it to a different device with sync, and what happens to the item in the list in that case?

We could also hook up middle mouse click to something approximating "duplicate tab", which does most of the same stuff as restoring the tab, but would presumably keep the closed tab in the list.

All of this is a product call. But so far we've persisted in the fact that these two lists are just different kinds of lists and therefore have different interaction patterns.

Thanks for the breakdown of the logic here. It's helpful to understand why and how links and buttons trigger differing behaviors. As Jamie stated, I also don't see this as a huge issue to address at the moment given that there is a workaround. But I would like to ensure that we are considering uninformed user expectation as much as we can here. i.e. the average user won't necessarily understand why a button and a link are different per say.

Emanuela, do you foresee any issues with us keeping the current behavior here as is?

Closing this out. Will address the UX implications separately as we continue to develop the new design.