Menulists that are truncated with ellipses don't show the full value in a tooltip when hovered over.
Categories
(Core :: XUL, enhancement)
Tracking
()
People
(Reporter: mkaply, Unassigned)
Details
Attachments
(1 file)
|
200.99 KB,
image/png
|
Details |
Comment 1•8 years ago
|
||
| Reporter | ||
Comment 2•7 years ago
|
||
Brian:
Would you happen to know where code to do this would be?
Comment 3•7 years ago
|
||
Do you have a STR for this in the UI? I tried clicking around in about:preferences but most of the menulists here are inside of popups (like Default Font), and I don't see a tooltip on any of their items ellipsis or not.
| Reporter | ||
Comment 4•7 years ago
|
||
Here's an example from my font list in prefs.
As you can see, multiple things have the same name due to ellipses.
Typically when we have ellipses, we show the full text on hover, but this has never been the case for menulist.
Comment 5•7 years ago
|
||
OK, so the markup here is:
<menuitem xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" value="Hiragino Sans GB" label="Hiragino Sans GB">
<hbox class="menu-iconic-left" align="center" pack="center" aria-hidden="true">
<image class="menu-iconic-icon"/>
</hbox>
<label class="menu-iconic-text" flex="1" crop="right" aria-hidden="true" value="Hiragino Sans GB" />
<label class="menu-iconic-highlightable-text" crop="right" aria-hidden="true">Hiragino Sans GB</label>
</menuitem>
The label[value] is the one visible, at least in this case and I'm pretty sure we don't need to worry about the menu-iconic-highlightable-text case (where it's not using nsTextBoxFrame) because that's related to the search feature when the items aren't visible.
If I manually set [tooltiptext] on the menuitem it works fine, so there's no issue with rendering the tooltip on top of an opened menupopup. So I guess the trick is (a) detecting when the nsTextBoxFrame is cropped and (b) setting up a tooltip on the parent menuitem in that case.
Typically when we have ellipses, we show the full text on hover, but this has never been the case for menulist.
Do you have an example where that happens? I tried manually triggering some cropping on a random non-menu label in about:preferences and don't see the tooltip.
| Reporter | ||
Comment 6•7 years ago
|
||
I'm thinking that I'm crazy now. I swear it used to work this way in other places. So I guess I'll mark enhancement.
Maybe some day :)
Updated•3 years ago
|
| Reporter | ||
Comment 7•3 months ago
|
||
Closing WONTFIX.
The original reproducer (font preferences) has long since been rewritten in HTML, and the broader trend across chrome UI is the same direction — XUL menulist is legacy and won't be getting new framework-level affordances like automatic overflow tooltips. The proposed fix point, nsTextBoxFrame cropping detection, is XUL-only plumbing that no one is investing in.
For surfaces that still hit this and where it's genuinely confusing, the right pattern today is per-callsite in HTML: text-overflow: ellipsis plus a small check that sets title when scrollWidth > clientWidth. That's a few lines wherever it's needed and avoids growing the XUL surface area for a problem that will keep shrinking as more UI migrates.
If a specific current-day surface still reproduces this and is causing real user confusion, please file a fresh bug scoped to that surface — that's a better hook for an HTML-side fix than this generic XUL enhancement.
Description
•