Bug: Status bar tooltips are inverted (and VERY slow)
pjeby opened this issue · 14 comments
Steps to reproduce:
- Enable any plugin that uses tooltips on status bar items (e.g. workspaces plus, mysnippets, pane relief, etc.)
- Hover over the item
The tooltips act as if the top of the status bar is the bottom of the item. This appears to be a 1.x regression; I still have a machine with 0.15.9 and it doesn't do this.
I apparently only just noticed the issue because it seems to have come with a new .75 second default delay for tooltips, which seems way longer than necessary - when I actually wanted to look at a tooltip today I thought it was broken and wasn't coming up at all... and then when it did show up I noticed the positioning issue. (The long hover requirement seems like a potential a11y issue to me for people with trouble keeping a mouse steady, unless they have specialized tools to make the tooltip visible without it. But that's a separate issue from the apparent API change(?) or implementation issue with tooltip positioning.)
If there is a way for plugins to work around this (including the delay) that'd be great; it's just occurred to me that one issue someone had recently with Pane Relief may well have been because they never saw the tooltip.
Did you try Chetachi's MySnippets? It has the issue too. I didn't know there were any builtin plugin with status bar tooltips or I'd have tried that. But Pane Relief works fine in 0.15.9 and does not in 1.3.5+, same for Workspaces Plus and MySnippets. Was there a change to the API besides the default delay?
Oh I see what's going on. At one point we had to rename aria-label-position
to data-tooltip-position
because aria-label-x
is considered an invalid aria tag which we were told may cause issues for some screen readers.
I should probably look into exposing the tooltip utilities.
Looks like we will be changing aria-label-delay
to data-tooltip-delay
for consistency as well.
Ah. Isn't aria-label-delay also nonstandard, though? I couldn't find any docs for it on Google. But yes, utilities sure would help going forward.
Speaking of... while I was working on the feature that prompted me to notice this, I discovered that the new way of setting icon size doesn't actually work because the stock theme overrides --icon-size
on icons in the status bar. To override that, you have to set --icon-size
on the icon, not the element you call setIcon on. Not sure if that qualifies more as a documentation issue or a theme issue? I'm not sure why the theme doesn't just set --icon-size on .status-bar instead of targeting the svg elements directly.
Are you using non-standard icons? Generally you shouldn't need to tweak the icon size as it should be specified by the theme for where the icon belongs.
I'm guess you might have a custom icon that's a tad bit too big or too small, and you're trying to size it to fit? In that case, you should tweak the svg to be conformant to the icon format as described in https://forum.obsidian.md/t/1-0-theme-migration-guide/42537
More details at https://github.com/lucide-icons/lucide/blob/main/docs/guide/design/icon-design-guide.md
It's the Lucide screen-share
icon, actually, but it's adjacent to text and looks ridiculously oversized at 16px. Dropping it to 12 makes it match the text. Not all of the Lucide icons have reasonable proportions, especially when placed next to text.
Also, that theme migration link seems to be broken? Googling "obsidian theme migration guide" also returns nothing. It looks like it got taken down when the announcements forum was retired? Can't find it in the blog or changelog either.
It's the Lucide
screen-share
icon, actually, but it's adjacent to text and looks ridiculously oversized at 16px. Dropping it to 12 makes it match the text. Not all of the Lucide icons have reasonable proportions, especially when placed next to text.
So here's the dilemma - if a theme developer sets icons to a different size than 16px, your now hardcoded 12px icon would look really out of place. IMO if the icon doesn't fit, I would consider choosing a different one, or injecting your own copy that's better sized. Let's take the discussion to the discord server where kepano and others can help.
Also, that theme migration link seems to be broken? Googling "obsidian theme migration guide" also returns nothing. It looks like it got taken down when the announcements forum was retired? Can't find it in the blog or changelog either.
Ah you're right, seems like that was an archived post that's no longer public. Seems like the information has been rewritten into various pieces of the CSS docs - specifically about the icon here: https://docs.obsidian.md/Reference/CSS+variables/Foundations/Icons
It's not hardcoded to 12px, it's set to var(--status-bar-font-size)
, as I'm basically using it as an emoji. If there were a "popout window" emoji I could put in the text, I'd be using that instead. IOW, it's not really an "icon" in the sense of being a status indicator or control of some kind, as is the case for most status bar icons. At any rate, it'll resize with the status bar font.
Anyway, wrt the main issue, it sounds like I need to use both the old and new attributes in the meantime, and maybe file some bug reports or PRs with the other plugins. Or maybe just wait till there's a valid API to do that since it sounds like you'll be exposing one.
Will add it to v1.4.4! Unfortunately in the meantime depending on how far back you want to support you will have to use the old names.
No problem. Thanks for the info.