Automatically close the admin menu tray after using it on narrow screens

I'd rather not introduce any configuration for the Navbar. But what if we vary the behavior by screen size. I'm thinking we leave the navbar open on larger screens if it was open on the previous page load and close the navbar on small screens in all cases. I agree it can be annoying to have the var open and dominating a small screen on a new page load.

What do you think?

Out of curiosity, why do you not want to introduce any configuration?

I tend to regard configuration as an abdication of the mandate to design. If a particular behavior is preferred, then we should just code that behavior in.

There's no way to do this without significant hacking.

I for one wish there was a configuration option or at least a hook to prevent the menu from being open on subsequent page loads. A quick 1-line workaround seems to be in navbar.js on line 56 make sure the activeTab variable can't find it's value in the cache...

activeTab: JSON.parse(localStorage.getItem('Drupal.navbar.activeTab___HA-HA-HA-YOU-CANT-FIND-ME'))

Added this JS to my theme, so it closes menu if its remain open

$(document).ready(function(){
  // Close Admin menu on page load
  var active_nav_icon = $('.navbar-icon-menu');
  if (active_nav_icon.length && active_nav_icon.hasClass('navbar-active')) {
    active_nav_icon.click();
  }
});

Thanks for the snippet, x610!

Can we just have this setting as a variable that can be overridden in settings.php? I prefer it to not remember what I had open on the previous page.

Thanks x610!

I'm using Themekey and Browsecap modules to identify mobile access to admin and loading Adminimal theme based on these conditions. I included #7 script on adminimal template.php so it will only trigger when access from a mobile browser. Hope this helps someone.

I would really love to have this option available as a setting. I personally think having settings is a good thing, not all people have the same preference or even not all projects require the same configuration. I think having a place to configure some of the default behaviours is better than having to install extra modules or adding js. My two cents.

Right now, regardless of screen size is quite annoying to have the navbar expand each time. Especially on slower connections.

Moving to D8 first.

Making a patch using #6 is better than #7 because it works for all themes. Most sites use a different theme for admin pages, and those are the pages where this functionality is needed. The admin themes are usually contribs not living in your repo. A year later and I am still patching each and every site I work on so the navbar goes away on subsequent page loads. In that time I haven't met a single developer or client who likes that it stays around.

I'd rather not introduce any configuration for the Navbar. But what if we vary the behavior by screen size. I'm thinking we leave the navbar open on larger screens if it was open on the previous page load and close the navbar on small screens in all cases. I agree it can be annoying to have the var open and dominating a small screen on a new page load.

+1

This sounds good. Lets do it

I´d personally also like the bar to close on large screens. It´s getting in my way there too, plus it just takes more time for the page to load when the menu is loaded again, expanded.

I´m not sure why having a config option for this is such a bad thing all of a sudden, it's not a crime is it?

#17: Jesse has explained why we want the toolbar to be configurationless. That's also not the scope of this issue. If you really want to discuss that, please open a new issue for that, so that we can continue moving forward here.

@Bojhan: considering @AlfTheCat's I´d personally also like the bar to close on large screens. It´s getting in my way there too, I wonder if what we really want is not to close the vertical admin toolbar tray only after using it on a narrow screen, but after using it on any screen? Jesse said I'm thinking we leave the navbar open on larger screens if it was open on the previous page load and this makes sense. But it actually doesn't make all that much sense when you've just used the toolbar. If you've used it, you're now where you want to be, so it should get out of the way.
Thoughts?

I think thats assuming to much, it's assuming the toolbar always gets you where you want to be. If it where a on hover interaction fly-out menu then this could work - but I dont think for Drupal's case.

Ok, so only on narrow screens for now.

Let's keep this issue focused, and do what's agreed upon. That's a step forward. If you think this isn't going far enough yet, please open a follow-up issue.

One of the reasons why I think the toolbar should have an option to always close is that for instance, if I visit a page that takes a while to load (/admin/modules for instance if a lot of modules are available) sometimes I accidentally click a menu item in the toolbar. The menu bar may not yet be visible, but you can already click menu items. So if I visit a page that takes a while to load, and happen to click on something to the left of my screen, I end up navigating away to whatever menu items turns out to be at the location I clicked.

@ Wim Leers
Thanks I will open another issue with a feature request for some configurable options, like the keep expanded/ not expanded. admin module would be a great example I think of where a few settings really help improve usability.

See #2464193: Provide configuration options for toolbar menu. Please vote it up :)

Just a reminder that we should pay attention to the screenreader experience if we change the behaviour. We might consider announcing that the tray is closed, or tweaking some invisible 'open/close' label.

I think if this could just be closed by default for small screens, that should make everyone's lives easier now. I can't think of another mobile site where an off canvas / hide-able menu is open by default. I love the idea of configuration options, but I could see how that might be a really big job and take some time.

tagging for https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html

This has been bothering me for a long time. The clients for a recent launch complained vigorously about the current behavior, especially on mobile, but even on wider screens.

I'm sure this won't be merged as-is, so I'm not wasting the resources with an MR and pipelines, but here's a simple patch that tells toolbar.js to always ignore the previous toolbar state and start every page load clean and closed. This is the behavior I (and these clients) expect, and it makes the site usable on mobile screens for everyone. Sharing here for posterity, and in case it helps anyone else.

To my great surprise (and delight), this patch applies cleanly (currently) to main, 11.3.x, and 10.6.x branches.

Enjoy,
-Derek

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 has moved to contrib