[snkiz]

Fixes #96. With vertical tabs the puzzle button sits in the nav-bar and the extension icons beside it are nav-bar items too, outside the tab-bar rules, so --uc-hide-extension-icons did nothing for them.

This adds the drawer for that case: the run of extension icons touching the puzzle on its left tucks away, and slides out when the pointer rests on the puzzle, the hamburger or one of the icons, or while an extension popup is open. It applies only while the tab strip is vertical and --uc-hide-extension-icons is 1. Horizontal tabs are not touched, and nothing sets --uc-extensions-button-right.

Trimmed to what was asked for in the issue: nav bar only, no side option, both rules gated on :root:has(#tabbrowser-tabs[orient="vertical"]), #PanelUI-button:hover in the reveal conditions, and a prefers-reduced-motion entry. The vertical gate in the hide rule sits inside :where() so it adds no specificity, which lets the reduced-motion rule tie with it and win by coming later.

Checked on ESR 153 and Nightly with vertical tabs, with --uc-hide-extension-icons at 1 and 0. I use windhawk, my reduced motion settings can't be trusted.

[Firnschnee]

Thanks, the scope is exactly what we discussed. I ran it through my vertical-tabs checklist on Release 160 (Windows 11, plain FoxOne, no FoxMica patches), and one thing fails: I can't get from the puzzle onto the icons.

Hovering the puzzle or the hamburger slides the drawer out fine. But as soon as the pointer leaves the puzzle towards the icons, the drawer closes, slow or fast, so the icons can't be reached at all. I stopped there, since most of the remaining checks need the icons in reach.

What I checked in the Browser Toolbox:

• Forcing :hover on one of the run's toolbaritems (addon_darkreader_org-browser-action) opens the drawer and keeps it open. So the reveal selector matches.
• With the drawer held open that way, the icons take real hover (the amber ring shows), so they are reachable once they're out.
• Rewriting the icon branch the way the Hover-reveal for pinned extension icons #13 rules do it, :has(#nav-bar-customization-target > toolbaritem[id$="-browser-action"]:hover) with the sibling chain only inside the :not(), changed nothing.
• Unchecking pointer-events: none on the hide rule didn't help either. Odd side effect: the bar then kept an empty gap the width of the drawer between the URL bar and the puzzle (the star moved left), with no icons visible in it. That may be a Toolbox artefact, but it could also mean the collapsed icons aren't really at zero width.

You wrote it works for you on ESR 153 and Nightly. Could you try it on Release 160, and on a profile without the FoxMica patches? My guess is that something on your side covers a gap that plain FoxOne leaves, maybe the grab-handle margin or patch 48, but I couldn't pin it down from here.

[Firnschnee]

A follow-up, since your PR text mentions the three PRs together: I tested this on 160 together with #100 (merged now), with and without a spring in the nav bar. Same result, the drawer still closes as soon as the pointer leaves the puzzle. So the grab-area margin from the prototype isn't what made it work on your side.

[snkiz]

I went back and looked again. The prototype had the problem. There was enough cushion in the old rules combined with my muscle memory I could make it look like it passed. And I could still hit the first one even with the latest iteration. Slowing down showed it. I can't explain why it does that. It's like there's a gap between the buttons. But 150ms papers over it nicely.