'autohide_bookmarks_and_main_toolbars.css' breaks search-bar on New Tab page

[zZombieBatman]

On the new tabs page there is a search-bar that when typed into it will normally send your input to the URLbar, but when the navBar is hidden due to the autohide, it won't send that input over to it at all.

[MrOtherGuy]

Right, this is the same thing as 440 (urlbar having visibility: hidden) - I'll fix this shortly

[MrOtherGuy]

This should be fixed in 7c38557

[PavloVinnyk]

This should be fixed in 7c38557

With just this code in userChrome.css the urlbar renders outside interface.

[MrOtherGuy]

Sheesh. Seems like it's only broken in beta, but works correctly in release and nightly. What fun...

[MrOtherGuy]

I dunno, kinda seems that beta is currently in a funny state where urlbar bounds are not computed correctly (at least not correctly for our purposes). You can get somewhat better behavior if you add this snippet to the style #urlbar[popover]{ --urlbar-height: 32px !important; } but it urlbar will still be in the wrong position initially when new window is created, but it should move into place once focused and typed something into it.

Most entertainingly, toolbar heights can get wrong, but only sometimes when window is created. So if a window is affected, then web-content will partially overlap with tabs toolbar. That's like caused by some bit of javascript sometimes running a bit too late or early when window is being created.

I guess chances are that something regarding this will get changed in a later beta build, I'm sort of thinking that whatever causes this style to fail here would also cause some other urlbar related issues unless fixed.

[PavloVinnyk]

Thank you for help, it's ok solution for me. Will wait future browser updates.

[zZombieBatman]

I applied the userChrome.css fixes to both the Nightly and Dev Build(beta), but the URL bar didn't behave as expected on either. This is due to my titlebar+navar having reduced sized which I always accommodate for by changing '--uc-navbar-height' to -32px. However, the URL bar doesn't align properly. It places the #urlbar[popover] in what would be its default location

dev build (after launch):

dev build (post-initial focus):

nightly build:

Edit:

I don't know if I have broken anything else in the process, but by removing everything that had to do with --uc-urlbar-top, it seems like everything was fixed.

so that was: --uc-urlbar-top: calc(var(--tab-min-height) + (var(--tab-block-margin) * 2) + ((var(--urlbar-container-height) - var(--urlbar-height)) / 2)); top: var(--uc-urlbar-top) !important;

and

toolbar-menubar:not([inactive]) ~ #nav-bar #urlbar[popover]{

top: calc(28px + var(--uc-urlbar-top)) !important; }

I thought by removing this I would be screwing up position when it came to the menubar, but after removing it, the #urlbar[popover] was placed correctly regardless of the menubar being visable or hidden.

[PavloVinnyk]

In standard beta 133.0b2 it behaves like you described in initial message - window starts with shifted urlbar and moves to the right position with any input. And I checked that #urlbar[popover]{ --urlbar-height: 32px !important; } not needed to shift to right position - not sure how i missed it initially.

Update. Saw you edit and tried it - it works and I could not find any strange or wrong behavior.

And some question - is there a way to define pop up menus to prevent autohide when they opened? For example url bar stays shown when application menu, extensions, and library menus opens, but hides with downloads, extensions list (puzzle icon) and edit bookmark menus

[MrOtherGuy]

@zZombieBatman yeah it should be pretty safe to remove those --uc-urlbar-top uses in nightly - I added them for beta only really and I'm now really confused why sometimes things seem to work fine without them. But, as previously mentioned there appears to be some seemingly non-deterministic behavior on beta so I can't make too much conclusion in one way or another.

@PavloVinnyk The panels actually should have been preventing toolbars from hiding this whole time, but apparently I have just had them do that when hovered - I'll fix that soon.