1834241 - No default buttons on unified toollbar

Status: RESOLVED INVALID

(Thunderbird :: Toolbars and Tabs, defect, P1)

Description

[Wayne Mery (:wsmwk)]

Something is wrong with bug 1824156.

I installed 115.0a1 (2023-05-21) using a new profile and got no default buttons on the unified toolbar. Tested twice.

Looking at the code and as commented in bug 1824156, should not default buttons should be provided in a new profile?

Does anyone else get default buttons?

Comment 1

[Wayne Mery (:wsmwk)]

Attachment: v102 default toolbar buttons

(In reply to Wayne Mery (:wsmwk) from comment #0)

Looking at the code and as commented in bug 1824156, should not default buttons should be provided in a new profile?

Tags button at least should be shown.

Comment 2

[John Bieling (:TbSync)]

Indeed no default buttons in fresh profiles. However, that is not what I tested in bug 1824156, I only tested migration of existing profiles.

Comment 3

[John Bieling (:TbSync)]

I did not catch your request to test this for new profiles, as indicated in https://bugzilla.mozilla.org/show_bug.cgi?id=1824156#c6.

Comment 4

[Wayne Mery (:wsmwk)]

According to darktroja ... the real problem is the default buttons are the same for every space, and they're just the search bar. I guess getDefaultItemIdsForSpace is supposed to be changed to return the right buttons, but I'll leave that to the person who invented this stuff

Comment 5

[Alessandro Castellani [:aleca]]

For new profiles the default state of the unified toolbar is empty with just the search bar.
That’s on purpose because all the actions that users used to rely from the toolbar buttons are in context.
We do this only for new profiles because we want to teach new users to not rely on toolbar buttons by default, and get used to contextual actions.
This is not an issue and it was decided on purpose.

Comment 6

[Wayne Mery (:wsmwk)]

I don't have a strong objection, but why did no one say this 3-4 weeks ago?
And, is there nothing we can put on the toolbar that most users might want to use that don't have context equivalents?

Comment 7

[Alessandro Castellani [:aleca]]

We talked about this in the past many times.
The whole purpose of the toolbar migration is to carry the old customized toolbar for users upgrading from 102 to 115, or beta users that never customized the new unified toolbar.
For new profiles we never intended to put any default into the toolbar.

Comment 8

[Martin Giger [:freaktechnik]]

For new profiles we never intended to put any default into the toolbar.

There are two things that are in the unified toolbar by default: global search and the global app menu (plus less obvious items like window decorations, extension action buttons). Both are actions independent of the current tab.

Tags button at least should be shown.

For now there's a plan on how tags will be exposed in-context (see the folder pane in the 3pane mockups for example at https://developer.thunderbird.net/planning/roadmap#app-menu). As long as that plan doesn't change I'd suggest we don't spend resources on a different solution to the problem. And if the plan changes we should spend resources on the changed plan.

And, is there nothing we can put on the toolbar that most users might want to use that don't have context equivalents?

Are you asking the correct question here? Let's be careful about pointing out problems instead of jumping to solutions. I think the problem you're trying to solve is that some people don't expect to be able to customize the unified toolbar? I think bug 1824289 will help a lot with this, as it will point almost all paths users are used to at the new customization interface. Aside from that I don't think we had any more obvious indication previously that the toolbar is customizable.

but why did no one say this

I'm sorry if you had the impression we were going to 1:1 replicate the 3pane toolbar in the unified toolbar. I tried to be very clear in what I said and showed in my communication as to what to expect from the unified toolbar. I think mockups and roadmap also match this.

When I say "migration" I mean a process that adapts existing profiles to new features we implemented. New profiles should not need migrations (even if technically we currently run a single migration on new profiles), instead the default state should always match what we want new users to experience. Updating the new user experience is one of our bigger long term goals as far as I'm aware.

Comment 9

[Wayne Mery (:wsmwk)]

Thanks for the clarification