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

I've added the css to fix this:

https://git.drupalcode.org/issue/drupal-3531516/-/commit/8fda91d0d4805a5...

I've patched my sites with it and everything works as expected now.

Hello,

This issue still requires some adjustments.
For example, on the /user/1 page, the element still doesn't take up 100% of the height.
I haven’t tested it on other pages yet.

Screenshot:

I have used gitpod (drupal 11.2.1-dev)

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

Thank you for testing, i’ll leave it on needs review for now and see if we can have an extra pair of eyes on this one.

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!

@xjm it should be fixed now. Thanks!

f0ns → closed merge request !12437

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;
  }
}

You might be right, I did not notice this css at first.

I’ll test this and get back on this.

f0ns → closed merge request !12438

The suggestion indeed also fixes the problem and seems to me that this is a better solution (delete one line of CSS instead of adding one line of CSS).

Please review!

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

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 📌 Define the 3 areas the Top Bar will provide Active . 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 🐛 Regression: Drupal.displace() not working on new Navigation module in 11.2 Active , which should have been fixed, but might be affecting something here.

I think it depends on how you see the sidebar vs the topbar.

Since the sidebar holds the logo I personally feel it should always be 100% height and the header shouldn't overlap it or push it down because the logo wouldn't be in the lefthand top corner in this case which feels visually weird.

Per @finnsky on Slack, the regression actually came from 🐛 Navigation top bar should utilize Drupal.dispace() Active .

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.

Then I can’t think of a case where you need to calc the height dynamically where it’s not 100% of the height for the sidebar.

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 🐛 Navigation top bar should utilize Drupal.dispace() Active , 2025-06-04). I re-tested, and the navigation section (admin toolbar) had full height. That is two days later than 🐛 Regression: Drupal.displace() not working on new Navigation module in 11.2 Active , 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 🐛 Navigation top bar should utilize Drupal.dispace() Active 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 🐛 Navigation top bar should utilize Drupal.dispace() Active --drupal-displace-offset-top was not initialized 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.

finnsky → changed the visibility of the branch 3531516-admin-toolbar-height to hidden.

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 🐛 Admin toolbar height is not 100% since upgrading to Drupal 11.2 Active 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 🐛 Admin toolbar height is not 100% since upgrading to Drupal 11.2 Active 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 ✨ Support for core navigation experimental module Active 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).