Option for the Toolbar *not* to auto-open the "Manage" sub-menu?

Yes, please. ;) Neither Google nor pouring through the toolbar.module component issue queue turns up any answers. IMHO it's weird and annoying that the manage tray is always open on initial page loads, mobile or otherwise. I'd rather toolbar remained slim, and users got to click on any of the links/trays they need, instead of it always taking up so much screen real estate.

Thanks, yeah, I'm familiar with it. However:
a) It has the same problem (and starts with the manage tray open by default)
and
b) It massively bloats the size of the HTML on every page since it unwinds the entire admin menu (so all the drop-downs work)

But again, thanks for the pointer. I have used admin_menu on various sites, and I go back and forth between loving and hating it. ;)

Meanwhile, I wonder how hard this is to get working. Sadly, a very preliminary hack to toolbar_preprocess_html() to *not* set the 'toolbar-tray-open' class doesn't do anything. Something deep in the toolbar JS world doesn't care about that class at all and opens the tray, anyway. This behavior seems deeply baked into the module. Hell, grep even turned this up:

./tests/src/FunctionalJavascript/ToolbarIntegrationTest.php: $this->assertTrue($content->isVisible(), 'Toolbar tray is open by default.');

So, we've got a FunctionalJavascript test to ensure the UI is broken for years to come. ;) Fun! Guess we'll have to alter that test as part of fixing this. Presumably, we'll have to make the default behavior configurable, since apparently lots of people wanted it this way in the first place. Adding #2464193: Provide configuration options for toolbar menu as a related issue, therefore.

Argh. This forced behavior was introduced as a "bug fix" at #1850164: Default state of toolbar should show menu tray in non-narrow viewports. Good grief. :/

I can already tell it's going to be an uphill battle to convince anyone "upstream" that this should be configurable at all. But at least that points me to the spot where this behavior is coming from, so I can hack^H^H^H^Hpatch core to fix this to not be so terribly annoying. ;) Here's a patch to "unfix" the non-bug and restore sanity to the toolbar. It'll probably fail the aforementioned test, and no one will commit it to core, but at least I can tell composer to install it on my sites. :)

Meanwhile, I see #2667396: Make the toolbar remember its open/closed state when in the horizontal position. exists to try to mitigate the pain. That way, although it would start open by default, you could at least close it once and it would stay closed across future page loads (I guess until you logout or something). So, that's probably the best we'll do in terms of fixing it in an official release of core. Someday. Interested parties are invited to help move that along.

Cheers,
-Derek

Ugh, well, that alone doesn't totally solve it, since there's a flicker where the Manage tray is still always shown for a split second before it either disappears or is covered by the actually active tab. Although, in fairness, that behavior exists without this patch, too. :/ *shrug*

Here's a re-roll for 8.7.x that goes one step further: my users now always want the toolbar closed on a fresh page load. If they want anything, they'll click on it. But having it auto-open, ever, is confusing and unwanted for them.

Again, I'm sure this won't land in core, as-is, but I sure wish there was an option to control this behavior or a cleaner way to manage this than patching core JS files. ;)

@dww I support this as a potential feature. The toolbar should not be always open by default on page load--that goes for all submenus. That said, I did try the patch in Drupal 9 and it has no effect for me. The toolbar remains open on page load regardless. Thanks.

I find the auto-open behavior desirable for an administrator in a desktop environment. For non-administrators, having it configurable would be great. However regardless of role, this behavior sucks on mobile. On my sites, the toolbar-tray-open CSS class and thus the padding to the side is always added, which makes mobile theming a mess.

@dww Thanks for finding all those related issues, I will be using one of those approaches for the meantime. I can understand the passive aggressive non-love, but maybe tone it down a notch for us fellow bugged people reading along here ;)

@ckaotik: Thanks for the reminder about my tone. Re-reading this issue, agreed that I'm not helping the cause by writing with my frustration / disappointment pouring out of what I'm saying. I'll work on being more productive and positive...

This needed a re-roll for 9.3.x and 9.2.x. Uploading as do-not-test to not waste testbot cycles on them, since they're the behavior is still not configurable so this is not going to be committed to core as-is. There's no interdiff. Only changes from #8 or between the two are in patch context lines.

Not sure if it's better to work directly in here, or over at #2464193: Provide configuration options for toolbar menu. I asked there and added a link to this back in June 2020, but there's been no action.

I'd be happy to try to turn this into a setting, if this should be the first issue to add a toolbar setting. I'm often wrong about scoping decisions, and would love input on the best way to proceed.

Thanks/sorry,
-Derek

Patch 2801501-15.no-auto-open-toolbar.9.3.x.do-not-test.patch is causing a display issue on loading for about 0.5-1 seconds so I'd say this is not ready yet.

Reroll for 9.5.x

Thank you for the patch. It's working but on desktop the toolbar menu is then always closed. On desktop the toolbar should stay opened if user has opened it, isnt' it?

Thanks for the patch, I tested it and it works, but ye the issue form #18 still persists, there is a display issue on loading for about 0.5-1 seconds, so is any progress on that?

Hrm, partial re-roll for the 10.1.x branch. Lots of changes to toolbar in D10. Sort of works, but there's a bit of weirdness in the behavior of the toolbar trying to remember which tray you had open. This isn't done, but it's a start of a D10 "port".

Would still be interesting to consider if there's a way to do this that could actually be committed to core someday, so we don't have to keep patching and re-rolling like this. 😅

Upon further testing, #24 is fairly broken, at least on D10.5. Here's a slimmed down version that does a better job of the UX I'm aiming for. It'll still remember an active tray (if set in localStorage), and be closed if there's nothing active. It "just" removes the case of trying to open the "first" tab if there's 0 toolbar state and it's the first time a user is interacting with the toolbar.

On the site where I care about this, the logout link is inside a toolbar tab. I don't want that tab to auto-open whenever someone logs back in. So I'm doing some custom JS treachery to clear out toolbar stuff from localStorage and sessionStorage whenever folks click a logout link.

The Toolbar Module was approved for removal in #3476882: [Policy] Move Toolbar module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3484850: [meta] Tasks to deprecate Toolbar module and the removal work in #3488828: [meta] Tasks to remove Toolbar module.

Toolbar will be moved to a contributed project before Drupal 12.0.0 is released.