Closed Bug 1786011 Opened 2 years ago Closed 2 years ago

"List all tabs" / tab manager button appears when opening Firefox View

Categories

(Firefox :: Tabbed Browser, defect, P3)

defect
Points:
2

Tracking

()

RESOLVED FIXED
106 Branch
Tracking Status
firefox106 --- fixed

People

(Reporter: dao, Assigned: dao)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [fidefe-firefox-view])

Attachments

(2 files)

We have a security / user control feature where the "List all tabs" button provides access to hidden tabs. Normally, the button appears when tabs overflow, but because of said feature, having hidden tabs makes it show up as well. So what's happening here is that because Firefox View is using a hidden tab, opening it suddenly shows the "List all tabs" button at the end of the tab strip.

So this is a bit of an odd bug report. There's nothing inherently wrong with what I've described above and I'm not suggesting that we change the logic around hidden tabs.

I think the most straightforward solution or improvement we can make here is to set browser.tabs.tabmanager.enabled = true, that is, show the "List all tabs" button always and unconditionally. Bug 1494755 tracks that. There are a couple of bugs marked as blocking that bug, but they're potential enhancements to the menu (which we've already exposed to users under the conditions I mentioned) that shouldn't block flipping the pref. The feature is pretty much ready as-is.

Whiteboard: [fidefe-firefox-view]

I could be aligned to showing the button always and unconditionally.

Could help discoverability to have it persistent.

The dropdown also has functionality that extends beyond the window. So even though that window with only Fx View and NTP doesnt have any overflow tabs if you have many windows open you can search for tabs in other windows with that "search tabs" functionality. (I know you can do that using the icon in the bottom of the awesome bar but that also has discoverability issues).

I'm aligned to this as well. Let's show the "List all tabs" button unconditionally.

Severity: -- → S4
Priority: -- → P3
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Points: --- → 2
Component: Firefox View → Tabbed Browser
Blocks: tab-manager
No longer depends on: tab-manager

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P3 → --
Priority: -- → P3
Attachment #9290649 - Attachment description: WIP: Bug 1786011 - Show the "List all tabs" button unconditionally. → Bug 1786011 - Show the "List all tabs" button unconditionally.
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a47784ff266f
Show the "List all tabs" button unconditionally. r=sfoster
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 106 Branch

This is breaking my workflow quite a bit. When I minimize a browser window, my eye tracks quickly to the minimize button as I move the mouse toward it. Habitually I track to the left most button in the command button area. I now find myself visually stopping on the drop down arrow, I have to pause for second and think.. 'oh yeah, that's not the right button'. So what was once a habitual gesture now requires mental cycles to accomplish.

I'd highly suggest we remove this.

Flags: needinfo?(sfoster)

I can see how that might create confusion. I'm not sure what the best resolution is though. I'm going to forward to Ray to get this into the right hands.

Flags: needinfo?(sfoster) → needinfo?(rfambro)

So we could use a different piece of iconography for windows that helps differentiate from the expand/minimize/close controls. Right now the scale and style of the iconography is basically equivalent. I noticed chrome on windows puts the chevron in a circle and while the circle probably maintains the same tap target size as the larger icons the chevron size is reduced which makes the button feel scaled down.

We can mock up some alternative UI implementations and potentially run a usability test with windows users.

Thanks for this suggestion Josh. I'd like to run some usability tests on Windows users for sure in order to pinpoint our best option to improve this UI. We will proceed as is for the 106 release and prioritize user testing in a follow up iteration.

Flags: needinfo?(rfambro)
See Also: → 1784432
QA Whiteboard: [qa-106b-p2]

Ray, will that be mentioned in 106 release notes?

Flags: needinfo?(rfambro)

Providing an update. Working with Design for a new UX pattern on this. We won't need to run a usability test. Will be something that we address in our follow up work.

Flags: needinfo?(rfambro)
Blocks: 1788692
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Ray, please file a new bug / jira issue for any new work, as we had already landed a fix here and don't want to lose track of that.

Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Flags: needinfo?(rfambro)
Resolution: --- → FIXED

(In reply to Pascal Chevrel:pascalc from comment #11)

Ray, will that be mentioned in 106 release notes?

Fwiw, I think the answer to this is no, we don't need to add anything to the 106 release notes for this.

Thanks for the reminder to do this Dao. Is it Ok to recycle this Jira issue and create a new bug? I feel like the Jira story was pretty vague and wasn't directive on a solution at the time of creation.
https://mozilla-hub.atlassian.net/browse/FIDE-1011

Flags: needinfo?(rfambro)

(In reply to Ray Fambro from comment #15)

Thanks for the reminder to do this Dao. Is it Ok to recycle this Jira issue and create a new bug? I feel like the Jira story was pretty vague and wasn't directive on a solution at the time of creation.
https://mozilla-hub.atlassian.net/browse/FIDE-1011

That's the product story - I think we don't have a strong opinion about how the product stories are used. For engineering though, this will need a new bmo ticket and an associated new FIDEFE jira ticket.

Flags: needinfo?(rfambro)

Sounds good. Since there's a Product and and UX story, let's map any new ENG Jira ticket there.

Flags: needinfo?(rfambro)

Would it make sense to exclude the Firefox View tab from the hidden tabs list? We don't show it with the regular tabs in the horizontal tab strip, and now we hide it from the ctrl+tab panel as well. It doesn't get recorded in any (user-facing) way AFAICT. We seem to exclude it from the "reopen closed tab" session store feature, including the "recently closed tabs" menu. Putting aside the issue of Firefox View making this button appear when it otherwise wouldn't, it still seems a little weird for Firefox View to show up in the all tabs menu at all, when almost everywhere else (in UI) it's not really treated like a tab.

Especially because it's going to be the only hidden tab in most use cases, and there can only be one instance of it, it feels a bit buggy for it to show up in that list. If you use session restore, it's easy to accumulate enough tabs that the all tabs menu takes up all the vertical space of your screen. And then, if Firefox View has been opened, the hidden tabs button appears in the list. Clicking it takes you to a subview whose content is only like 80px tall, with just 1 button. Yet because panel height is "sticky," the panel remains super tall, with like 95% of its height just empty space. Of course that is expected behavior, but it doesn't feel right.

I agree with everything you said, Shane. I already suggested it in bug 1790633 to exclude it from the hidden tab list, but it was resolved as WONTFIX. But that doesn't mean that the decision can't be revisited. 😉

See Also: → 1798375
See Also: → 1796068
Blocks: 1576130
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: