Problem/Motivation

For some reason, "Disabled, show on scroll-up" seems to not work in the Git-version of Drupal 11.x-dev.

It works well if you install Drupal 11.x-dev with the standard, Composer method, i.e. composer create-project drupal/recommended-project and "minimum-stability": "dev" and "prefer-stable": false.

Steps to reproduce

  1. Install Drupal 11.x-dev with Git, instead of Composer, using this method:
    git clone https://git.drupalcode.org/project/drupal.git drupalgit
    cd drupalgit
    ddev config --project-type=drupal11
    ddev start
    etc.
    
  2. Enable "Disabled, show on scroll-up" under /admin/config/user-interface/admin-toolbar and see that it has no effect.
  3. Install another instance of Drupal 11.x-dev, but with the standard, Composer method, i.e. composer create-project drupal/recommended-project and "minimum-stability": "dev" and "prefer-stable": false and see that "Disabled, show on scroll-up" works well.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

ressa created an issue. See original summary.

ressa’s picture

Issue summary: View changes
dydave’s picture

Thanks @ressa!

Looks like there are going to be some substantial changes to the core Navigation in the 11.3.0 release, see:
#3421969-99: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable

I wonder if this could be somehow connected...

I'll take a closer look when I get a bit more time to test the upcoming 11.3.0. 👌

Thanks in advance! 😊

dydave’s picture

Hey @ressa! 😊

Is this issue still occurring on your setup?

I've been testing with the latest stable 11.3.0 and the 11.x dev branch checked out from the repo, but I can't seem to be able to reproduce the issue. 😖

Could you please maybe try on a fresh setup and see if the problem persists?
In which case it would be great to collect additional context information so we could try reproducing the issue.

Otherwise, from the latest rounds of tests I've carried locally, the sticky behaviors all seemed to be working fine (as expected).
Maybe it was a temporary change in the DEV branch that broke something at some point?! 🤔

Feel free to let me know if the problem is still occurring on your side, I would surely be glad to take a closer look. 👌
Thanks in advance!

ressa’s picture

Thanks for taking a look at this @dydave!

I tried with a fresh install, and latest dev-versions (Drupal core from 26 dec. and Admin Toolbar from 27 dec.), and got the same result ...

I took a look at admin_toolbar/js/admin_toolbar.sticky_behavior.js, and it seems like some checks may not work as intended, because I get different outputs. Around line 34, a check is used whether to proceed or not, and the variable Drupal.adminToolbar.toggleToolbarHidden is not identical ...

I inserted alert(localStorage.getItem('Drupal.adminToolbar.toggleToolbarHidden')) on line 20 (above "Attach to the ...") and get these results:

Drupal 11.2:
null

Drupal 11 DEV:
true

Maybe the toggleToolbarHidden variable needs to be initialized, for a consistent result?

If I switch the check for from true to false, it seems to work in both Drupal 11.2 and Drupal 11-DEV:

window.addEventListener('scroll', () => {
  if (
    localStorage.getItem(
      'Drupal.adminToolbar.toggleToolbarHidden',
    ) === 'false'
  ) {
    // If the toolbar is hidden, do not execute the scroll logic.
    return;
  }

PS. I also quickly looked at the JavaScript files, and these seem to have been added since Drupal 11.2, in case it could play a role:

  • /core/assets/vendor/htmx/htmx.min.js
  • /core/misc/htmx/htmx-utils.js
  • /core/misc/htmx/htmx-assets.js
  • /core/misc/htmx/htmx-behaviors.js
  • /core/modules/big_pipe/js/big_pipe.commands.js

dydave’s picture

Status: Active » Needs review

Thanks @ressa for the detailed report, and especially for comment #5: 🤩
The localStorage values you found were the key to understanding this.

Created the initial merge request MR !223 above at #6 assisted with AI, as an attempt to fix the problem initially reported.

Could you please give this patch a round of tests and see if it could fix the problem on your local setup?
Let me know if that works: Overall, a single line of JS was changed in this merge request 👌
(the rest is tests)

For reference, I've copy/pasted below the analysis of this issue by an AI agent.
Thanks again very much for all your great help! 😊

--------------------------

Analysis

The "Hide on scroll, show on scroll up" behavior is implemented in js/admin_toolbar.sticky_behavior.js. On every scroll event, it returns early when this local storage key is 'true':

localStorage.getItem('Drupal.adminToolbar.toggleToolbarHidden') === 'true'

This key is only written by the toolbar toggle shortcut feature (js/admin_toolbar.toggle_shortcut.js, Alt + P), which is disabled by default (enable_toggle_shortcut: false).

The sticky behavior therefore depends on a state owned by another, optional feature. If a browser origin ever had the toolbar hidden with the toggle shortcut, and the feature is not enabled anymore (or the site was reinstalled on the same URL), the key stays 'true' in the browser, and the sticky behavior silently never works.

Reproduction

I reproduced this in a headless browser (Drupal 11.5.x-dev), with "Hide on scroll, show on scroll up" enabled and the local storage value set directly before scrolling down the page:

Stored value Toggle shortcut Toolbar hides on scroll down
none disabled yes
'false' disabled yes
'true' disabled no (this is the problem reported here)
'true' enabled yes (the toolbar was hidden on purpose with the shortcut)

This matches your observations in #5: null on Drupal 11.2 (working) and true on the Git-based 11.x-dev site (not working). It would also explain why the Composer-based installation works: local storage is per origin, so a stale value would depend on the host name used. I could not confirm that last part: it is a hypothesis, since we do not know where the stored 'true' value came from on your setup.

Changing the check from true to false, as suggested in #5, makes the scroll logic run in your case, but it would also run when the toolbar was hidden on purpose and would reveal it on scroll up. It would also not remove the dependency on the stored value.

Proposed fix

Replace the local storage read with a check of the CSS class the toggle shortcut already adds to the body tag when the toolbar is hidden:

if (element.classList.contains('toggle-toolbar-hidden')) {
  // The toolbar was hidden with the toggle shortcut: do not execute the
  // scroll logic.
  return;
}

The class reflects the real state of the page: it is only present when the toggle shortcut is enabled and the toolbar is actually hidden, so leftover values in local storage are ignored.

With this change, a browser test (added in the merge request) shows that:

  • The toolbar hides on scroll down and shows on scroll up with nothing stored, with 'false' stored, and with a stale 'true' stored while the toggle shortcut is disabled.
  • With the toggle shortcut enabled and the toolbar hidden on purpose, scrolling up does not show it, and the sticky behavior resumes once the toolbar is shown again.

Against the current code, only the stale 'true' case fails.

Could you please confirm?

To check that this is the cause on your Git-based site, could you please run this in the browser console on that site, then reload the page and scroll down?

localStorage.removeItem('Drupal.adminToolbar.toggleToolbarHidden');

If the toolbar then hides on scroll down, the stale value is confirmed as the cause. Otherwise, please let us know what localStorage.getItem('Drupal.adminToolbar.toggleToolbarHidden') returns, and which Admin Toolbar settings are enabled (sticky behavior, toggle shortcut), so we can keep investigating.

ressa’s picture

Status: Needs review » Postponed

Thanks for taking a look at this @dydave!

I tried to replicate the bug in the latest release of Drupal core's main branch (where its latests release is drupal 12.0.0-beta2) but I could not replicate the problem, the behaviour is perfect ...

I used drupal/toolbar version 2 and a Git clone of Admin Toolbar 3.x-dev, adding || ^12 under core_version_requirement in all relevant *.info.yml files, and it worked well -- AT Search, AT Extra Tools, etc.

I also tried to apply the patch, and everything still worked well. So I am not sure if we should just close this issue as cannot reproduce?

dydave’s picture

Category: Bug report » Support request

Thanks so much @ressa for taking the time to test this, once again! 🙏

No problem to keep this one one the side for later. 👌
Glad to hear you're not reproducing the issue anymore. 🥳

I allowed myself to requalify the issue as Support request for now, to avoid impacting the "Bug reports" stats of the module unnecessarily and I hope you won't mind.

We could always move back the issue to a "Bug report" when we get back to it in the future, if the problem appears again.

Let's keep working on the next items of the roadmap! 🤓

Thanks again for all your great help!

ressa’s picture

Category: Support request » Bug report
Status: Postponed » Closed (cannot reproduce)

Thanks @dydave!

But maybe let's just close it, unless you think we should consider adding that one line? But as I see it, since it cannot be reproduced I am leaning towards closing it, we can always open it again, if it's needed. About the status -- sure, but since I am now closing it, I hope it's all right if I change it to what it is (or was), namely a bug :)

... and by the way, great to see all the activity, from many different users supplying MRs and testing, very nice!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.