Recent update broke my top navigation bar

Some recent upgrade broke my top navigation bar - more specifically, the bar loads (it’s visible for a split second) but then the standard discourse header puts istelf on top of it and hides it.

I’m trying to figure out what exactly happened and/or how to fix it. Could someone point me in the right direction?

By inspecting the page in the browser, I figured out that setting

.d-header-wrap {
    margin-top: 48px;
}

will move the header down to reveal the navbar (which is 48px high) and that seems to have fixed things.

But I’m not sure whether this is a sustainable way of fixing it and I’m also still curious to learn what exactly happened.

I also had to remove

#main-outlet { margin-top: 48px; padding-top: 75px;}

from my component in order to remove the additional white space that had appeared under the header. This code has worked fine for years, so I’m curious what caused it to break…

I also removed something else, like

#main-outlet.docked {
    margin-top: 0px;
    padding-top: 123px
}

because it didn’t seem to make a difference.

Edit: The above is true for desktop CSS. On mobile, I did not need to increase the Z value of the Navbar.

2 Likes

The header changed from using position: fixed to position: sticky (https://github.com/discourse/discourse/commit/da5841de0b2b60ceaa2f2602d7231e7393a74e66) - this is one of the updates we’ve been able to make due to dropping IE11 support.

The change improves some small issues we’ve had with the header since Discourse has existed… what it means functionally is that instead of being in a fixed position (and unrelated to the position of other elements on the page), the header is now part of the natural flow of elements on the page… which is why the main outlet padding and margin are no longer needed.

When the change was initially made there was some extra padding on mobile in the default CSS, but that was fixed a day or two later… I’d guess you updated on the day between the initial change and the fix, if you update it again it should go away (you can alternatively add .mobile-view #main-outlet { padding-top: 0.25em; } if you don’t want to update again).

Your fix with .d-header-wrap seems sustainable to me.

5 Likes

See also Header submenus. Not sure whether the proposed sustainable fix applies to that, but I think they are related to the same change.

1 Like

I just upgraded to latest (2.8.0.beta4) after many months of negilgence and it seems that my fix wasn’t so sustainable (or perhaps the current issue is unrelated to this fix). I’m currently working to figure out what happened and will update here once I know, but if the following strikes a bell for anyone, please let me know.

So basically what happened is the same as described in the OP, except that this time it is not the discourse header covering the top navigation bar but the top navigation bar covering the discourse header . (edit: I now believe that the header is not covered but not rendered at all). When I disable the default theme via safe mode, it displays fine.

Strangely, though, when I navigate to /admin/customize/themes/11/desktop/scss/edit both the discourse header and the top navigation bar display correctly (both in safe mode and normal mode). I believe the reason why there is no difference between safe and normal mode on the theme page is that safe mode doesn’t apply to some of the admin pages. But what I don’t understand is why everything is displayed correctly on the admin pages but not otherwise.

Another thing I don’t understand: when I access the site on my mobile, it also displays correctly, even when I explicitly request the desktop version…

I will investigate further but would appreciate any hints here.

Edit: Here is what I see when I inspect a public page (in normal mode):

And here is what I see when I inspect an admin page (in normal mode):

As you can see, my CSS fix is present in both cases, but only the second one renders the page correctly…

OK, I believe I fixed it. The disappearing header was not related to my fix but caused by this theme component:

Removing it made solved the problem. Perhaps @Johani understands what is causing this? Perhaps it is related to the

Additional control of iframes in oneboxes

introduced in Discourse Version 2.6 - #2 by neil?