Closed (cannot reproduce)
Project:
Admin Toolbar
Version:
3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 Nov 2025 at 11:22 UTC
Updated:
17 Oct 2026 at 19:25 UTC
Jump to comment: Most recent
Comments
Comment #2
ressaComment #3
dydave commentedThanks @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! 😊
Comment #4
dydave commentedHey @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!
Comment #5
ressaThanks 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 variableDrupal.adminToolbar.toggleToolbarHiddenis not identical ...I inserted
alert(localStorage.getItem('Drupal.adminToolbar.toggleToolbarHidden'))on line 20 (above "Attach to the ...") and get these results:Drupal 11.2:
nullDrupal 11 DEV:
trueMaybe the
toggleToolbarHiddenvariable needs to be initialized, for a consistent result?If I switch the check for from
truetofalse, it seems to work in both Drupal 11.2 and Drupal 11-DEV: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.jsComment #7
dydave commentedThanks @ressa for the detailed report, and especially for comment #5: 🤩
The
localStoragevalues 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':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:
'false''true''true'This matches your observations in #5:
nullon Drupal 11.2 (working) andtrueon 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
truetofalse, 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
bodytag when the toolbar is hidden: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:
'false'stored, and with a stale'true'stored while the toggle shortcut is disabled.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?
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.Comment #8
ressaThanks for taking a look at this @dydave!
I tried to replicate the bug in the latest release of Drupal core's
mainbranch (where its latests release is drupal 12.0.0-beta2) but I could not replicate the problem, the behaviour is perfect ...I used
drupal/toolbarversion 2 and a Git clone of Admin Toolbar 3.x-dev, adding|| ^12undercore_version_requirementin 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?
Comment #9
dydave commentedThanks 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!
Comment #10
ressaThanks @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!