What happens
With showValueAsTags: true, a selected tag gets a tooltip only if its label is judged to overflow. That judgement is made against the wrong element and the wrong font, so:
- tags that visibly truncate can end up without a tooltip;
- tags that fit comfortably can end up with one.
Why
setValueText() measures the label before the tag markup exists:
const valueTooltipForTags = Utils.willTextOverflow($valueText.parentElement, label)
? this.getTooltipAttrText(label, false, true) : '';
$valueText is .vscomp-value, so the container passed in is .vscomp-toggle-button, and willTextOverflow() compares the measured text width against that element's clientWidth, using that element's computed font. Neither matches what the text actually gets:
|
Compared against |
What the tag text really has |
| Width |
.vscomp-toggle-button clientWidth |
minus the button's padding (4px 22px 0 10px), the tag's border + padding + margin (~17px) and the 24px clear button — roughly 73px less |
| Font size |
inherited 14px from .vscomp-wrapper |
.vscomp-value-tag renders at 12px, so the measurement runs ~17% wide |
The two errors push in opposite directions and do not reliably cancel.
Suggested fix
The check does not need an off-screen node at all.
- The rendered tags are already collected into
this.$valueTags immediately after the innerHTML write.
setValueTagAttr() already iterates every one of them.DomUtils.hasEllipsis() (scrollWidth > offsetWidth) already exists, and is already used for the non-tag value text.
Doing the check there measures the real rendered box, so both inaccuracies disappear, and it replaces one forced synchronous layout per tag with a single batched read pass. Utils.willTextOverflow() and the shared measurer node can then be removed.
One constraint: read every tag first, then write the tooltips, so the loop does not interleave reads and writes and reintroduce the layout thrash.
Impact
More tags will carry tooltips than today. That is the corrected behaviour rather than a regression, but it is a visible change and worth a line in the release notes.
What happens
With
showValueAsTags: true, a selected tag gets a tooltip only if its label is judged to overflow. That judgement is made against the wrong element and the wrong font, so:Why
setValueText()measures the label before the tag markup exists:$valueTextis.vscomp-value, so the container passed in is.vscomp-toggle-button, andwillTextOverflow()compares the measured text width against that element'sclientWidth, using that element's computed font. Neither matches what the text actually gets:.vscomp-toggle-buttonclientWidth4px 22px 0 10px), the tag's border + padding + margin (~17px) and the 24px clear button — roughly 73px less14pxfrom.vscomp-wrapper.vscomp-value-tagrenders at12px, so the measurement runs ~17% wideThe two errors push in opposite directions and do not reliably cancel.
Suggested fix
The check does not need an off-screen node at all.
this.$valueTagsimmediately after theinnerHTMLwrite.setValueTagAttr()already iterates every one of them.DomUtils.hasEllipsis()(scrollWidth > offsetWidth) already exists, and is already used for the non-tag value text.Doing the check there measures the real rendered box, so both inaccuracies disappear, and it replaces one forced synchronous layout per tag with a single batched read pass.
Utils.willTextOverflow()and the shared measurer node can then be removed.One constraint: read every tag first, then write the tooltips, so the loop does not interleave reads and writes and reintroduce the layout thrash.
Impact
More tags will carry tooltips than today. That is the corrected behaviour rather than a regression, but it is a visible change and worth a line in the release notes.