Shortcuts link in top bar has is-active class sometimes on login

I have login on my site but the shortcuts link is not active

I reproduced it another way, looks like maybe it's something to do with how Gin Top Toolbar is installed. It occurred here when I installed the module via the UI and it also occurs on first login when installing Drupal CMS.

I have overriden the is-active styles.

Before:

After:

Even with the patch this issue still persists on my end. Using Drupal 10.3 with the Navigation module installed. ULI link used on a new incognito session always seems to reproduce this.

@christosgeorgiadis I have made some changes to the css, can you please check it again

I haven't tested this but just noting that the active state is necessary still for the classic toolbar, just making sure that is accounted for.

Works as expected now. I've tested the classic toolbar and it doesn't seem to have any issues. Let's have someone take a second look just in case before we RTBC this!

I'm not in favour of changing the CSS for this. It feels like a workaround but doesn't tackle the source of the problem: the active state is set accidentally under some circumstances but not in others. We need to find out why this is happening and fix that. I'm going to have a look now.

I can't reproduce this problem. What I've done is installing a fresh Drupal CMS (latest version) and use the ULI link. I get to this:

When looking a bit closer, I see 2 tiny differences to the screenshot in the IS that may well be related:

• The breadcrumb: it's admin / admin / Edit User in the IS, but only admin / Edit User in mine. I guess the latter is correct and wonder where the extra breadcrumb item comes from.
• The message content: the IS message contains an extra part that explains that using this link is no longer necessary, etc.

As of those 2 extra pieces, is there any other module that's installed and causes those differences?

@jurgenhaas are you testing the uli link incognito? It only occurs for me locally incognito, so there's obviously a browser cache aspect to this. I just tested it again and I see it but again, only incognito.

I confirm that when launching the Drupal CMS rc1 zip with ddev in Firefox inkognito, I also see this bug.

Confirmed, I can reproduce this in incognito too. Investigating further.

So, I'm a couple of steps further. The HTML on that page gets delivered by Drupal without the is-active class. It looks like this:

<a href="/admin/config/user-interface/shortcut" title="Shortcuts" class="toolbar-icon toolbar-icon-shortcut trigger toolbar-item" id="toolbar-item-shortcuts" data-toolbar-tray="toolbar-item-shortcuts-tray" role="button" aria-pressed="false">Shortcuts</a>

The extra class gets added by javascript in the browser. This explains why incognito with no caching whatsoever behaves differently from a regular browser window.

It seems that Gin is not doing that, it must be coming from something else. I'm searching a bit more, but that's a difficult one.

@jurgenhaas I assume it's core Toolbar adding it?

I assume it's core Toolbar adding it?

I wish it was, can't confirm (yet). The problem is that debugging in an incognito window is hard, when it has to be the very first request to debug as we can't set a breakpoint early enough.

I tried to put an observer into the html itself. That confirms that the class is-active gets added client-side, but I can't figure out where this is coming from. So, maybe somebody with more javascript knowledge can dig deeper here?

This is what I did: edit web/themes/contrib/gin/templates/html.html.twig and add the following code in line 54 right after {{ page_bottom }}:

    <script>
      var elemToObserve = document.getElementById('toolbar-item-shortcuts');
      var prevClassState = elemToObserve.classList.contains('is-active');
      console.log(prevClassState);
      var observer = new MutationObserver(function(mutations) {
        mutations.forEach(function(mutation) {
          if(mutation.attributeName == "class"){
            var currentClassState = mutation.target.classList.contains('is-active');
            if (prevClassState !== currentClassState) {
              prevClassState = currentClassState;
              if (currentClassState) {
                console.log("class added!");
                console.trace();
              }
              else {
                console.log("class removed!");
              }
            }
          }
        });
      });
      observer.observe(elemToObserve, {attributes: true});
    </script>

This outputs to the console:

false edit:2566:15
class added! edit:2574:25
console.trace() edit:2575:25
    observer https://drupal-cms.dev.jurgenhaas.de/user/1/edit?pass-reset-token=TTNTqCbqwiJk_j8R5BnahTV4XOBe0w6cflAfbvHQ5ekoaoFdVx-JmMXCaq87tKhxbb3-mVpP5w&check_logged_in=1:2575
    observer https://drupal-cms.dev.jurgenhaas.de/user/1/edit?pass-reset-token=TTNTqCbqwiJk_j8R5BnahTV4XOBe0w6cflAfbvHQ5ekoaoFdVx-JmMXCaq87tKhxbb3-mVpP5w&check_logged_in=1:2568
    (Async: MutationCallback)
    <anonym> https://drupal-cms.dev.jurgenhaas.de/user/1/edit?pass-reset-token=TTNTqCbqwiJk_j8R5BnahTV4XOBe0w6cflAfbvHQ5ekoaoFdVx-JmMXCaq87tKhxbb3-mVpP5w&check_logged_in=1:2567

So, the element did not have the class when the page was loaded, then something added the class and finally we get the stack trace. But that doesn't tell us which script as actually adding it.

@jurgenhaas Unsure if this might help narrow the scope of determining “what script could be adding the is-active to the ‘Shortcuts’ link at the top”, but the issue only seems reproducible as long as the “Navigation” module is enabled. I couldn’t reproduce the issue if I uninstall “Navigation” and configure the Gin theme to use “ New Drupal Navigation”.

It makes me wonder if there is some sort of collision happening somewhere between “Navigation” and “Gin Admin Theme” with regards to the “Shortcuts” link at the top? I didn’t have a chance yet to dig into any of the scripts there, but might be a good place for someone who has way more JavaScript knowledge to start debug.

I was able to find that the class is added from ToolbarVisualView.js (web/core/modules/toolbar/js/views/ToolbarVisualView.js) at line 223

if ($tab.length > 0) {
  $tab
    .addClass('is-active')

I hope this helps somehow!

Yeah, that's it :-) Thanks @christosgeorgiadis for finding this.

I'm moving this to the Drupal core toolbar issue queue.

The class is getting added as per #24 But the session storage still sets activeTabId to toolbar-item-shorcuts

{
    "orientation": "horizontal",
    "hasActiveTab": true,
    "activeTabId": "toolbar-item-shortcuts",
    "activeTray": "toolbar-item-shortcuts-tray",
    "isOriented": true,
    "isFixed": true,
    "userButtonMinWidth": 0
}

Haven't tested this but I don't think it will really fix it, because something other than shortcuts can be the first link (e.g. 'Go to' from Coffee module) and that gets the active state if Shortcuts isn't present. It's not an issue with the Shortcuts link specifically, the issue is that whatever the first link in the toolbar is gets set to active initially.

But separately, the core toolbar should set the first link as active, regardless of what it is. And we don't want to interfere with that. So not really sure where this sits, considering that core says that you shouldn't use Toolbar with Navigation, but Gin requires it for now.

saschaeggi → changed the visibility of the branch 3490111-shortcuts-link-in to hidden.

saschaeggi → changed the visibility of the branch 3490111-shortcuts-link-in to hidden.

MR 550 needs a review

Works great. Tested on both Firefox and Chromium based browsers.

RTBC+1 looking good to me too.

fwiw agreed with the CSS fix here. There are three issues blocking the navigation top bar from being stable (more for navigation itself) listed on 📌 New Toolbar Roadmap: Path to Beta & Stable Active , so it may be possible to switch to the navigation toolbar in Gin / Drupal CMS when 11.2 comes out, or earlier if some of those are backportable to 11.1.

Thanks!

@catch thanks for confirming 👍

Automatically closed - issue fixed for 2 weeks with no activity.