Repository navigation
URL-bar icons: reveal without getting in the way of typing #59
Description
@snkiz mentioned this in #55 and #58: with FoxOne's defaults, the hover-revealed URL-bar icons (reader view, translations and so on) slide in as soon as the pointer is over the bar, which gets in the way when you only want to click into the text. FoxMica handles this with a hover delay (snkiz/FoxMica#1, snkiz/FoxMica#15). Opening this so we can work it out together and it doesn't get lost.
The core problem: CSS only sees states like hover and focus, not intent. A pointer over the URL bar might be there to edit the URL, to click the shield, or to wait for the hidden icons. A delay doesn't solve that, it just favours one of them: it helps people who type and makes people who want an icon wait.
Options so far:
- Hover delay (FoxMica's approach): simple and already proven, but it has the trade-off above, and the bar still shifts, just later.
- Reveal on focus only, as an opt-in: the icons appear once you click into the bar, not on hover. This is honest about intent, but every icon costs an extra click.
- Hover zone at the right end: only hovering the end of the bar, where the icons sit, reveals them, and hovering the text area does nothing. This comes closest to reading intent from where the pointer is aiming, but it's untested, and the URL-bar icon containers in Nova have been fragile to style before.
Whatever we pick should be opt-in with today's behaviour as the default, like the nav-button options in #58.
snkiz, since you've lived with the FoxMica version for a while: how does it feel in daily use, and would option 2 or 3 work for you?
Activity
snkiz commentedon Oct 9, 2026
2 seconds eh? Edge case I did not consider. But good catch. The nav buttons are the thing that makes the bar jump. The url icons, (you may catch me calling them charms) don't really move the bar I've noticed unless you're counting expansion, I have the collapsed state tight enough that more then a couple takes all the clickable text area. That size is not yet set in stone.
Living with it so far, it works when you have intent at 600ms. And falls apart if you hesitate, you wouldn't think it, but that little thing forces you to be deliberate and it's finicky. I was leary of moving that number too much and inducing a lag feeling, it's a fine line.
Funny you mention option 2 that was on my todo list, *in my head. I also had the same thought for the nav, hide them when you click into the text area. You're typing not naving at that point, haven't tried that. I'd say it's half a click extra, habit has been to click the bar to expand it anyhow. None of this reveal stuff feels right, yet. But on my side 0ms was unusable, and here we are.
The reveal on click, would work but it hurts discover-ability, those icons being dynamic based on content, and there's add-ons too. They shouldn't be a problem on an expanded bar, not for a human readable link. You may have noticed I don't make user decisions so I'd be inclined to offer every reasonable choice. I don't have to like it.
Firnschnee commentedon Oct 10, 2026
About the 2 seconds: that was only a test value in my review of #58, to make the timing easy to see. Your 600ms sounds like a sensible value for anyone who turns the delay on. The hover colour issue isn't specific to 2 seconds though, it happens with any delay, 600ms included. It's just much harder to notice there.
Thanks, that's really useful, especially the daily-use part. "Works when you have intent, falls apart if you hesitate" sums up my doubts about the delay better than I could. It doesn't remove the conflict, it only moves it to a different point in time.
On hiding the nav buttons when you click into the text: I'd rather not. In the default layout the buttons are always visible, so hiding them on focus would shift the whole bar by three button widths at the exact moment you click, which is the jump #55 is trying to avoid, just at a worse moment.
On option 2 and discoverability: fair point, the icons depend on the page and on add-ons. FoxOne's default already trades some of that away by hiding them until hover, though, so option 2 would only go one step further. I wouldn't rule it out, but I don't see it as the best candidate either.
What I'd like to explore first is option 3, the hover zone at the right end of the bar. It's the only one that tries to tell the cases apart instead of favouring one: aiming at the text does nothing, aiming at the end where the icons live reveals them right away. I haven't tried it yet, so it may turn out to be fragile in Nova. If you get to experiment with something like that in FoxMica before I do, I'd be very interested in how it feels.
One thing about scope, so we're on the same page early: for FoxOne I'd add at most one new option here, and only once a variant has proven itself in daily use. Same reasoning as with the two states in #54: every option has to be explainable in one line of the customisation guide. FoxMica is of course free to offer more.
snkiz commentedon Oct 10, 2026
My theory is that the right delay on option 2 over the two elements would give you just enough delay to get to the text area, and only reveal everything, if you haven't clicked the bar in time. option three is better as a stand alone option. Discoverer-ability can go to far, just look at the tab menu. This is a compact-ish theme right? (Me more so then you.)
Firnschnee commentedon Oct 10, 2026
Hmmm... I want to make sure I read your theory right, because I can see two versions of it:
A: hover with a delay reveals the icons, and clicking into the bar reveals them right away, like auto-hide mode 1 for the nav buttons. The delay just buys time to reach the text before they show up.
B: hover with a delay reveals the icons, but clicking into the bar before the delay runs out cancels the reveal. A quick click means "I want to type", so the icons stay hidden. Only lingering without clicking brings them in.
B is the one I find interesting, because it uses the click as the intent signal instead of guessing from timing alone. It should also work in plain CSS: in #58 the click couldn't cut the delay short because the target values didn't change, but here focus would set the hidden state as the target, which replaces the running transition. The catch is that while the bar is focused, the icons would be out of reach until you press Esc or click away. Which one did you mean?
Compact-ish, yes, but functional: hiding the icons until hover is already FoxOne's compromise between the two. FoxMica going further makes sense for a theme that's more compact by design.
On scope: rather than two separate options, I'd compare B and option 3 in daily use and add whichever holds up better. If one of them turns out clearly better, that's the one option.
snkiz commentedon Oct 10, 2026
I had I think on this, option b is what I had in mind yes, but I've thought it out more.
For the charms, a binary choice you could do would be current behaviour vs reveal on hover of the star, like you do with the extensions and the hamburger. with just enough delay that passing over it doesn't instantly show them. And yes clicking into the text area they go away, you don't need them anymore right? I'm working on that after I do some irl chores. And those tweaks to the PR. I've got some example code infornt of me. That I haven't tried at all. So I'm hesitant to pass it out right now.
Edit: thing about delay, it's subjective, it needs a knob.
snkiz commentedon Oct 10, 2026
I am making a new comment to ping you. I'm just gonna quote the spitballing I'm doing, I don't know how to word this better. Thought it would be useful if you're tinkering before me.
Firnschnee commentedon Oct 10, 2026
The star-hover idea is basically option 3 with a real target instead of an invented zone, which removes the part I was worried about in Nova.
I like it, and I'm testing a prototype:
#page-action-buttons:hoverreveals after 300ms, the revealed icons sit inside the same container so they stay while you're over them, and:focus-withinreveals right away for keyboard users who arrow onto the star. I did the same on the left for the permissions icon, which now only shows when you rest on the shield next to it (granted camera, mic or location still show permanently).On
pageproxystate: Firefox already does that part natively. Its urlbar.css hides every.urlbar-page-actionwithdisplay: nonewhile the state isinvalidand whileusertypingis set (checked in 157 and 158), so the first keystroke drops the icons no matter what we do. That leaves[focused]as the only thing to decide, and in this mode I simply don't reveal on focus. Clicking into the text moves the pointer off the star anyway.One trap if you build your own version:
max-width: nonecan't be interpolated from 0, so it jumps immediately and ignorestransition-delay. You get an empty gap first and the icon only after the delay. A length (I used 40px and 200px) fixes it.On the knob: for FoxOne I'd keep the delay fixed. On a 16px target it only has to filter out passes, not guess intent, so it's less subjective than with the nav buttons. FoxMica can of course expose it.
and no rush on #58, whenever you get to it!
snkiz commentedon Oct 10, 2026
I ran the test with all three, the nav hide, star hover and click override. I used nav at 450 star at 300, they land at the same time. Feels pretty smooth. Defaults are normal if you try it, turn everything on first. 7dec808
Firnschnee commentedon Oct 11, 2026
Thanks for testing all three together! And very good to hear the 450/300 combination lands at the same time.
One thing for FoxMica: I think your version cancels the
[focused]reveal but has no:focus-within, so keyboard users can't reach the icons anymore. Adding#page-action-buttons:focus-withinto the reveal (without the delay) brings them back when you tab onto the star.Reveal URL-bar icons from the star and shield only (#59)
Firnschnee commentedon Oct 11, 2026
Shipped in f3f90c1 on main, on by default: the page icons (reader, translations, add-to-taskbar, add-ons) now only appear when you rest on the bookmark star, and the permissions icon only when you rest on the shield. 300ms delay on hover, immediate on keyboard focus.
--uc-urlbar-icons-reveal: 0brings back the old URL-bar hover reveal. Thanks @snkiz for the star idea and for testing it together with the nav delay from #58.C-O-D commentedon Oct 11, 2026
Hi there, really nice additions, thank you very much for that. I just noticed in V 3.9 that the nav buttons also appear when hovering over the star / zoom indicator, which I think is actually unnecessary (too much movement in the bar). When I hover the star I want to see the icons and not use the nav buttons, which would also be too far away. Conversely, the icons don't appear when I hover over the URL bar, which makes perfect sense. What do you all mean? Could you at least make it optional?
In any case, thank you very much for your great work and best regards!
Keep auto-hidden nav buttons hidden on the bookmark star (#59)
Firnschnee commentedon Oct 11, 2026
Thanks for the report @C-O-D , and good catch! Seriously... damn!
You're right: since 3.9 the star is where you go for the icons, so revealing the nav buttons there as well works against that. The nav-button reveal from #58 listens to the whole toolbar, and the star is part of it.
Fixed in 3.9.1 (8615557): with
--uc-urlbar-icons-reveal: 1, the auto-hidden nav buttons now stay hidden while you rest on the star, the zoom indicator or the revealed icons. If you come from the URL text and they're already out, they slide away at the same moment the icons appear, so it's one movement instead of two. In auto-hide mode 1 they still stay visible while the URL bar has focus.One more thing:
--uc-autohide-nav-delaynow defaults to450ms. With0ms, the short strip between the tabs and the star is enough to flash the nav buttons on the way in, so if you've set your own value, I'd go with something around 450ms.I didn't make it a separate option: with the star-only reveal on, I can't think of a case where you'd want the nav buttons on the star. If you find one, let me know.
C-O-D commentedon Oct 11, 2026
Thanks man, sunday saved 😄