Open Bug 1733844 Opened 3 years ago Updated 6 months ago

4 letters badge text of extension buttons is unexpectedly truncated

Categories

(WebExtensions :: Frontend, defect, P3)

Firefox 92
defect

Tracking

(firefox-esr78 unaffected, firefox-esr91 unaffected, firefox93 wontfix, firefox94 wontfix, firefox95 wontfix, firefox96 wontfix, firefox97 wontfix)

ASSIGNED
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- wontfix
firefox97 --- wontfix

People

(Reporter: yuki, Assigned: yuki, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Patches introduced at the bug 1714135 reduces max-width of badge text element from 24px to 20px. As the result, the 4th letter in alphabetic text are unexpectedly truncated now. This breaks extension compatibility, for example Minimal Digital Clock uses 4 digits to show the clock but the last letter is cut off.

Steps to reproduce

  1. Install Firefox 92 or later.
  2. Start Firefox.
  3. Install Minimal Digital Clock.

Actual result

Only three digits are visible for the time "00:00".

Expected result

Full 4 digits are visible for the time "00:00".

Environment

  • Firefox 92.0.1
  • Windows 10
  • Minimal Digital Clock 1.2

Workaround

userChrome.css can fix this for now:

.toolbarbutton-badge-stack {
  position: relative;
}

.toolbarbutton-badge {
  max-width: 24px !important;
  position: absolute;
  right: var(--toolbarbutton-inner-padding);
  top: var(--toolbarbutton-inner-padding);
}
Assignee: nobody → yuki
Status: NEW → ASSIGNED
Attachment #9244104 - Attachment description: WIP: Bug 1733844 - Allow longer batch text without increased button size → Bug 1733844 - Allow longer batch text without increased button size

Recent regression. Oops.

Severity: -- → S2
Keywords: regression
Priority: -- → P2
Regressed by: 1714135
Has Regression Range: --- → yes
Attachment #9244104 - Attachment description: Bug 1733844 - Allow longer batch text without increased button size → Bug 1733844 - Allow longer batch text without increased button size r?mixedpuppy
Attachment #9244104 - Attachment description: Bug 1733844 - Allow longer batch text without increased button size r?mixedpuppy → Bug 1733844 - Allow longer batch text without increased button size r?dao

While I creating the patch, I saw an odd CSS behavior around XUL and XHTML. CSS spec says that coordinates of a position:absolute element should be calculated based on its offset parent: the nearest ancestor element with position except static. So the following example should show a "!!!" badge at top-right of the "back" button (please run it for a browser window via the Browser Console):

{
  const button = document.querySelector('#back-button');
  const badge = document.createElement('label');
  badge.textContent = '!!!';
  badge.setAttribute('style', 'position: absolute; right: 0; top: 0; background: red; color: white; width: 24px; height: 20px');
  button.style.position = 'relative';
  button.appendChild(badge);
}

However it actually shows the "!!!" badge at top-right of the toolbar, and the "back" button never become the offset parent. Should I file a new bug for it? What product should I choose? ("Core"?)

Set release status flags based on info from the regressing bug 1714135

(In reply to YUKI "Piro" Hiroshi from comment #3)

While I creating the patch, I saw an odd CSS behavior around XUL and XHTML. CSS spec says that coordinates of a position:absolute element should be calculated based on its offset parent: the nearest ancestor element with position except static. So the following example should show a "!!!" badge at top-right of the "back" button (please run it for a browser window via the Browser Console):

...

However it actually shows the "!!!" badge at top-right of the toolbar, and the "back" button never become the offset parent. Should I file a new bug for it? What product should I choose? ("Core"?)

Is the behavior actually incorrect? If I traverse the element and ancestors of #back-button, then the first positioned element appears to be toolbar#nav-button, so what you're observing seems correct to me.

{
let but = document.querySelector('#back-button');
let getPos = elem => elem.ownerGlobal.getComputedStyle(elem).position;
console.log(getPos(but));                       // "static"
console.log(getPos(but.parentNode));            // "static"
console.log(getPos(but.parentNode.parentNode)); // "relative"
console.log(but.parentNode.parentNode);         // <toolbar id="nav-button" ...>
}

(In reply to Rob Wu [:robwu] from comment #5)

Is the behavior actually incorrect? If I traverse the element and ancestors of #back-button, then the first positioned element appears to be toolbar#nav-button, so what you're observing seems correct to me.

Hmm, your results looks different to the one on my environment (Nightly 95.01a on Windows 10). On my environment:

{
const button = document.querySelector('#back-button');
const badge = document.createElement('label');
badge.textContent = '!!!';
badge.setAttribute('style', 'position: absolute; right: 0; top: 0; background: red; color: white; width: 24px; height: 20px');
button.style.position = 'relative';
button.appendChild(badge);

const getPos = elem => elem.ownerGlobal.getComputedStyle(elem).position;
console.log(getPos(button));                       // "relative" <= expected
console.log(getPos(button.parentNode));            // "static"
console.log(getPos(button.parentNode.parentNode)); // "relative"
console.log(button.parentNode.parentNode);         // <toolbar id="nav-bar" ...>
console.log(button.lastChild);                     // <label style="position: absolute; ...>
console.log(button.lastChild.offsetParent);        // <toolbar id="nav-bar" ...> <= unexpected (expected is the #back-button)
}

Set release status flags based on info from the regressing bug 1714135

Attached image Screenshot with issue.

Issue is also reproducing on badge from ClearURL add-on, for detailed steps to reproduce please see bug 1714135.

Dao, it looks like the patch was updated since you last reviewed it, could you take a look again?

Shane, is this actually S2?

Flags: needinfo?(mixedpuppy)
Flags: needinfo?(dao+bmo)
Severity: S2 → S3
Flags: needinfo?(mixedpuppy)
Priority: P2 → P3
Flags: needinfo?(dao+bmo)

I think we would still like to get this patch landed - they look like good changes. I can commandeer the patch if you prefer?

Flags: needinfo?(yuki)
Duplicate of this bug: 1884517
No longer duplicate of this bug: 1884517
Duplicate of this bug: 1884517

Sam, would you mind commandeering the patch and polish it to be ready for landing?

Flags: needinfo?(sfoster)

Note that currently also 1, 2 and 3 letters badge is cut on the right side (see with your eye how the border-radius is visible only on the left side).

(In reply to Rob Wu [:robwu] from comment #13)

Sam, would you mind commandeering the patch and polish it to be ready for landing?

Unfortunately probably not any time soon. I'm trying to see if any one else is able to pick it up.

Flags: needinfo?(sfoster)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: