Nav buttons: optional hover-reveal delay and hide disabled for Firnschnee/FoxOne#54

[snkiz]

Closes #54 and #55, as one PR since both touch the hover-reveal block.

--uc-autohide-nav-delay (default 0ms, so nothing changes)
With auto-hide 1 or 2, the hover state gets a transition-delay, so a quick pass
over the bar doesn't slide the buttons in and shift the URL bar. Leaving stays
immediate, and mode 1's focus reveal is excluded, so clicking into the bar still
shows them at once.

--uc-hide-disabled-nav-buttons (default 0, so nothing changes)
Two states as you suggested: 0 = dimmed (today), 1 = Back/Forward collapse while
there's nowhere to go. Works with auto-hide off too. The selector carries an extra
:root:not([customizing]) so it outranks the hover/focus reveal, and Customize mode
is left alone so every button stays reachable.

On your question: current Firefox doesn't collapse a disabled Forward button on
its own. In mozilla-central's toolbarbuttons.css and browser-shared.css nothing pairs
#back-button/#forward-button with [disabled]; they only get the generic
disabled-button opacity. So width: revert isn't undoing anything. The collapse I
missed is from much older Firefox.

Docs: both added to the CONFIG block with a comment line, and to the Visibility
Toggles table in customisation.md. scripts/check.mjs and
stylelint (npx stylelint@16 "*.css") both pass locally.

Related, not in this PR: with FoxOne's defaults, the bigger problem is the URL-bar icons (reader
mode, translations and so on): revealed on hover, they cover the text input area. This delay only helps
when auto-hide is on, and it's off by default, so it doesn't solve that. In FoxMica I delay those icons the same way
(hover-only transition-delay, focus stays immediate). Happy to open a separate issue for it.

Found while testing, not caused by this PR (edge case): with auto-hide 1 or 2, the existing hidden-state
rule isn't scoped to #nav-bar and has no Customize-mode exception. In Customize mode the buttons stay
collapsed until you click into the bar, and a Reload button dragged to the palette sits there at zero width
until you reset the toolbar. With auto-hide off, both behave normally. Adding :root:not([customizing]) #nav-bar to that rule, as the hide-disabled rule here does, would probably fix it.

So you know who you're talking to: the ideas and testing are mine; the deep CSS was worked
out with Claude's help. I've read every line and I'm happy to answer for it, but for CSS
questions I may take a little longer to come back to you.

Tested on Nightly 159, Windows 11, in a clean profile with plain FoxOne 3.8.8 plus this branch:

• Defaults as shipped: no visible change from 3.8.8.
• Auto-hide 1 and 2 with the delay at 600ms: buttons slide in late on hover and leave at once; in
  mode 1, clicking into the URL bar reveals them immediately.
• Hide-disabled 1, with auto-hide 0, 1 and 2: Back/Forward hidden on a fresh tab, Back appears after
  navigating, Forward after going back. Both visible in Customize mode.

[Firnschnee]

Thanks for this, and for the clear write-up. I tested it (FF 157.0.1 & FF 158.0b5) with auto-hide 1, a 2000ms delay to make timing visible, and hide-disabled 1. Both options behave as described, and the defaults leave 3.8.8 unchanged. Three things before I merge:

1. The delay also holds back the hover colour. The hidden-state rule sets transition: all 0.2s ease, so a plain transition-delay delays every property that changes while the pointer is over the bar, including the button's own hover colour. With 2000ms, the arrow turns amber two seconds after you point at it. The delay should only cover the reveal properties. Since the last matching entry in a transition list wins, something like this keeps everything else at 0.2s without delay:

transition:
  all 0.2s ease,
  opacity 0.2s ease var(--uc-autohide-nav-delay),
  width 0.2s ease var(--uc-autohide-nav-delay),
  min-width 0.2s ease var(--uc-autohide-nav-delay),
  max-width 0.2s ease var(--uc-autohide-nav-delay),
  padding-inline 0.2s ease var(--uc-autohide-nav-delay) !important;

2. This can live in the existing hover rule. I'd put it into #nav-bar:hover :is(...) instead of two separate container blocks. The mode 1 :not(:focus-within) exception doesn't change anything in practice: clicking into the bar always comes after the hover, so the reveal is already running with its delay (a running transition isn't restarted when its end value stays the same). Keyboard focus without hover never matches the delay rule in the first place.

3. Docs wording. Because of the above, clicking into the URL bar also waits for the delay. Only keyboard focus (Ctrl+L, F6) reveals immediately. Could you change "Leaving and focus stay immediate" to "Leaving and keyboard focus stay immediate" in the CONFIG comment and in customisation.md?

Your side finding was right. The hidden state applied in Customize mode and in the palette. That's fixed on main in d57ee31 (credited to you). Please rebase onto main. Your :root:not([customizing]) exception in the hide-disabled rule now actually takes effect, since the base rule no longer covers it, so a quick retest in Customize mode would be good.

[snkiz]

I integrated your changes then fired off another branch to try that text input detect on the nav, so they hide. see what you think, I dropped the delay to 450ms. I think it feels like the url is expanding both ways in response to your clicks. It's not jarring at all anymore. You'll have to change the hover settings.
ad317de