Found in

• 135.0a1 (2024-12-19)

Affected versions

• 135.0a1 (2024-12-19)

Tested platforms

• Affected platforms: Windows 10x64
• Unaffected platforms: macOS 12

Preconditions

• sidebar.revamp enabled

Steps to reproduce

1. Open the Customize sidebar.
2. Go to Customize Toolbar.
3. Click on Manage Themes.

Expected result

• The Customize sidebar icons are correctly positioned.

Actual result

• The Customize sidebar icons are lifted.

Regression range

• pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7e2ae0e42af3c7bef3e608f047d4d05ddbccf8c0&tochange=1a5773cdbbec4c63ae5370d820a1d4023cbcc605

Additional notes

• Attached a screen recording.

This is also happening on macOS

Changing the component to Toolkit > UI Widgets for the ReComp team to investigate further. We're using the moz-checkbox component for these radio buttons.

Mark, would someone be able to look into this and get a fix by 137?

I was clicking around trying to figure out why this is happening...it still makes no sense to me, but getting rid of the relative/absolute positioning seems like a potential fix (which in turn maybe points towards what's causing this in the first place?):

diff --git a/toolkit/content/widgets/moz-input-common.css b/toolkit/content/widgets/moz-input-common.css
--- a/toolkit/content/widgets/moz-input-common.css
+++ b/toolkit/content/widgets/moz-input-common.css
@@ -48,10 +48,6 @@
     }
   }
 
-  .label-content {
-    position: relative;
-  }
-
   /* Input */
 
   #input {
@@ -76,7 +72,6 @@
   /* Icon */
 
   .icon {
-    position: absolute;
     width: var(--icon-size-default);
     height: var(--icon-size-default);
     margin-block: var(--icon-margin-block-adjust);
@@ -85,7 +80,8 @@
     stroke: currentColor;
 
     + .text {
-      margin-inline-start: calc(var(--icon-size-default) + var(--space-small));
+      margin-inline-start: var(--space-small);
+      vertical-align: top;
     }
   }

Setting inset: 0 on .icon also appears to fix this, but I don't know why. It seems like the stacking context has changed or something. Interestingly this doesn't reproduce in my release build. Running mozregression.

Actually there is a regressor on here already, but manually reverting that locally doesn't seem to fix it...

My mozregression pointed to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=68328f7bb0766007cf5acc0ac993e5c613bf39e4&tochange=840b6bd0d6e4f247b6111895bd33bd67ab08ed2f which seems more likely, but I still don't see what would have caused this (or realistically how this could possibly happen)

That push has changes from Bug 1917305 (hjones's changes related to the input, seems likely) and Bug 1936684 (emilio, build fixup related to margins, maybe also related but that just feels so unlikly for both of these to be together haha)

@emilio any idea how this absolute positioned element could shift like this? Interestingly inspecting the box around these inputs which is a shadow root fixes the issue

No, this is due to the CSS, and it's a long-standing issue. The containing block is the .label-content, which is an inline, and this is using the hypothetical position (inset: auto).

We have some long-standing issues on this area, see bug 489100 and bug 255139.

That said, that seems like a rather odd styling choice? It seems it's so that the alignment doesn't affect the height of the line, is that right? That seems rather odd, you could just use vertical-align: top to prevent that. Or just make the label-content display: inline-block or so but...

https://hg.mozilla.org/mozilla-central/rev/20ab12263bfa

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Verified fixed with Firefox 136.0a1 (2025-01-12) on Windows 10x64 and macOS 12.