Admin toolbar height is not 100% since upgrading to Drupal 11.2

Hello,

I was able to reproduce the visibilty error visiting the /user/1 page Screenshot:

After testing on Gitpod using Drupal 11.2.1-dev and applying height: 100% from the patch provided makes the navigation bar correctly take up the full height.

I think this fix is ready for a merge request.

I’ve tested the patch on various admin pages, and it works as expected.
Many thanks to f0ns for the fix!

It would be ideal to know which commit caused this.

Thanks @f0ns. Your issue fork seems to be out of sync or perhaps created against a different source branch. Can you create a branch and merge request containing only the commit for your fix? Thanks!

I go though the issue and got that this issue is occured beacuse of block-size: calc(100vh - var(--drupal-displace-offset-top, 0px)); see the codebase link Code Link in line 95. In olivero frontend theme --drupal-displace-offset-top is set to 64px that's why navigation bar height is not getting 100%. In claro Admin theme i saw that --drupal-displace-offset-top is set not defined so we can see full height of navigation bar in claro. I am attaching images for clarity. Please share your thoughts.

I think may be we can remove the line block-size: calc(100vh - var(--drupal-displace-offset-top, 0px));

Before:

@media (min-width: 64rem) {
  .admin-toolbar {
    block-size: calc(100vh - var(--drupal-displace-offset-top, 0px));
    transform: none;
    inset-block-start: 0;
  }
}

After:

@media (min-width: 64rem) {
  .admin-toolbar {
    transform: none;
    inset-block-start: 0;
  }
}

I was able to visually confirm the patch successfully fixes the height of the navigation bar by visiting `/user/1`

I agree that this solution that deletes css is the superior fix.

I have added screenshots as evidence.

It would be good to check which issue added that line of CSS and whether it was added to fix a specific issue (or if it's not clear why it's there in git blame, e.g. added without comment as part of a larger change).

I saw this line is introduced in this issue queue https://www.drupal.org/project/drupal/issues/3484564. Here is the MR -> MR Link.

But it is not clear to me what issue it was fixing by decreasing the height from 100vh. Can you please look into it.

There is also #3526180: Regression: Drupal.displace() not working on new Navigation module in 11.2, which should have been fixed, but might be affecting something here.

Per @finnsky on Slack, the regression actually came from #3526266: Navigation top bar should utilize Drupal.displace().

Maybe it's not. :)
I'm not sure right now.

The top bar was added in a hurry and we need to review how it works with displace

@f0ns that seems to be the behaviour already, the top bar starts from the right edge of the sidebar for me.

I can confirm the fix in MR 12461 restores the height of the navigation sidebar.

I tested with the current 11.x and reproduced the problem.

Then I reverted 6bdfd060b136 (the commit from #3526266: Navigation top bar should utilize Drupal.displace(), 2025-06-04). I re-tested, and the navigation section (admin toolbar) had full height. That is two days later than #3526180: Regression: Drupal.displace() not working on new Navigation module in 11.2, so I think it is fair to say that #3526266 caused this bug, confirming Comment #28. I am adding #3526266 as a related issue.

I am setting the status to NW for some automated tests. Otherwise, we will have to go through the same arguments and similar research the next time this feature gets broken. I notice the comment #3526180-8: Regression: Drupal.displace() not working on new Navigation module in 11.2:

Note that I don't test out displace's functionality (that gets tested in its respective tests), I just test that the attribute is added properly, which is what the JS in this module does.

This time, can we get a functional test? That is, figure out the various combinations of window size, top bar, and navigation area, and confirm that things fit together the way we want them to?

@finnsky:

The top bar was added in a hurry and we need to review how it works with displace

Is there already an issue for that? If so, it would help to add it here as a related issue.

By the way, #3526266 changes markup (core/modules/navigation/templates/top-bar.html.twig) as well as CSS. Let's consider both before making further changes to the CSS.

@benjifisher, I tried reverted the commit from https://www.drupal.org/project/drupal/issues/3526266 and finds out that the issue caused this height bug.

Now after testing i came to know in this issue data-offset-top attribute is added in aside tag in top bar's twig file MR Link Issue #3526266. Because of that attribute --drupal-displace-offset-top along with other left, right and botton displace offset value is initialized and this is why the sidebar block-size: calc(100vh - var(--drupal-displace-offset-top, 0px)); it's height is reducing from 100vh.
Instead before this issue https://www.drupal.org/project/drupal/issues/3526266 --drupal-displace-offset-top was undefined as data-offset-top was not added as an attribute in Top Bar's aside tag, so we were getting full height 100vh of the sidebar.
Now i dont know how data-offset-top is related to --drupal-displace-offset-top but this are the things i mentioned above that i noticed.

I think that is the thing for which the height issue occurs due to that issue #3526266 commit. @benjifisher, Could you please share your thought on this.

The issue seems more deeper that just height, but about behaviour of Drupal Displace globally
When workspaces enabled we have top displace calculated wrong
https://gyazo.com/52b598ad2bac75476ccc48d88e4ad98c

1. Removed
{% if tools or context|render or actions|render %}
We have css for it. We may avoid it.

2. It is currently impossible to provide a shift of the toolbar and top bar together with displace offset top.
Therefore, let it always be aligned to the top of the screen
The drop-down popover accordingly too.

Workd good even with workspaces. Please review.

After this MR --drupal-displace-offset-top is undefined now. Now i found another regression due to that. Hamberger Icon and Search Box gets overlapped now as there is a regression in border-top-width property applied in .header-nav. I am attaching before and after image.

Before MR:

After MR:

Maybe we have to adjust border-top-width of .header-nav without --drupal-displace-offset-top

I don't think we need to test Olivero theme here, it is outside of that issue scope.

@finnsky, Thank you for the clarification, I tested the MR and it fixes the issues correctly. I am attaching images for better understanding.

Hi,

Thanks @finnsky.

I have tested MR https://git.drupalcode.org/project/drupal/-/merge_requests/12843, it fixes the issue.

Changing to RTBC as the test failure in the pipeline seems unrelated.

I am setting the status back to NW for an update to the issue summary. I already added the missing elements from the standard outline. Please

1. Fill in the "Proposed resolution" section. (See below.)
2. Add screenshots to the Before and After sections under "User interface changes". Probably you can use the screenshots attached to Comment #44 or #45.

That will make it a lot easier for others to review your work on this issue.

I would still like to see some automated tests, as I said in Comment #34, but I will not insist on that. I guess the navigation module is still experimental (especially the top bar).

From the MR, I see that you

• replaced the block-size and inset-block-start calculations with fixed values 100vh and 0
• changed the top bar (in some cases) from display: block; to display: flex; and replaced margin with padding
• removed the {% if ... %} ... {% endif %} around the <aside> element in a Twig file, and removed the data-offset-top attribute.

I can see what was changed, but the issue summary should explain the intention behind those changes.

I'm not sure what tests would look like for this (that would actually prevent the regression) except for visual regression tests that we don't have a framework for. If someone does, it would be great to add them here. If there's not a good way to add tests, we should open an explicit follow-up to add them later and add it to the navigation stable meta somewhere.

testing MR12843, the shift of the footer region is being fixed, but the problem @finnsky highlighted in #37 still persists and the expanded workspaces popup making the workspaces menu item button and the shortcuts menu items inaccessible while the popup is expanded. do i understand #39 correctly and workspaces popup covering parts of the navigation sidebar is impossible to fix at this point?

I can't find the core issue, but #3457688: Support for core navigation module has notes for a redesigned workspaces/navigation integration. So if this MR fixes other things but not workspaces, we should probably go ahead here and then fix workspaces in that issue (or open it if it doesn't exist).

I see main issue that offcanvas JS
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/dialog/o...

not allows to set multiple top displacers.
https://gyazo.com/d598a5fdfad8d8ac8b6a2e415ec7a303

So we not able to add top shift with both top dialog and top bar.

I'm going to fix this.

A bit of background to address the comments above:

What is Drupal.displace() and how does it work.

Drupal.dispace() is a JS function that looks for attributes like data-offset-top, data-offset-left, etc. These are meant to be used by "sticky" position: fixed admin UI elements. And if used properly, will inform the front-end code how to properly place itself on the top of the page. For example, we don't want a fixed header to obscure the admin toolbar (or vice-versa).

So when Drupal.displace() is ran, it'll look for those data-offset properties, return the object, and also update those CSS vars that you're seeing.

(I should really turn this into a blog post).

Anyway, since the navigation's toolbar is fixed to the top, we definitely want that attribute on it.

Why was that line of CSS introduced?

To be honest, I might have done that back in the day (it looks like something that I would have written). When this was written, the top bar did not yet exist. And even though that didn't exist, there are other top bars (e.g. the old workspaces UI). So we needed to accommodate that.

For the Navigation module, the left toolbar is expected to go full height -- even if the the top bar exists. So the fix is simple. We need to just remove the one line of CSS.

From @catch in #47

I'm not sure what tests would look like for this (that would actually prevent the regression) except for visual regression tests that we don't have a framework for. If someone does, it would be great to add them here. If there's not a good way to add tests, we should open an explicit follow-up to add them later and add it to the navigation stable meta somewhere.

Agree. No easy way to currently add tests, and TBH, I don't even believe this is something that will likely break. I'll add a followup

OK. Easy fix. Hopefully we can get this in for 11.3.

That's pretty clear cut, thanks for the explanation in #52.

Just double-checking: the changes in MR 13918 look to be the same as MR 12461, which was done on a suggestion from #3531516-16: Admin toolbar height is not 100% since upgrading to Drupal 11.2. There's some back and forth on this after #22, and in that subsequent discussion it's unclear to me whether there are issues with this change. Have all those concerns been resolved?

unfortunately the workspace top bar overlaps with the navigation sidebar, inner menus are fine, we did the same as earlier in this issue 😂

Added check for when offcanvas is at top of screen.

Works for me. Conceptually makes sense that everything us pushed by the sidebar

Thank you! Tested manually and works great.

I noticed that for some reason the workspaces toggle doesn't always open the panel on the top but links to the page. 🤔 That seemed to be a pre-existing issue so maybe something we should work on in a separate issue?

Looks like this creates a regression. The off-canvas fills the whole screen when it's not displayed on top or bottom, but on the right of the screen.

That's because, even when displayed at the right of the screen, the container has the attribute data-offset-top="0"

Not sure if the syntax is correct, but we may have to add &:not:is([data-offset-right]) to the selector. And also, could the off-canvas be displayed on the left? If so, that would probably require another addition to the selector.

one example to illustrate the regression would be admin/config/user-interface/navigation-block with the navigation module installed - simply configure one block:

the context menus seem to be broken as well and missing styling but that might be unrelated.