1937627 - Optional permissions moz-toggle buttons are now positioned on the left of their label since Bug 1917305 changes landed in central

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect, P1)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: aboutaddons-optiona-permissions-moztoggle-regression-20241216.png

I've noticed this regression today while reviewing a patch which was applying changes in the optional permissions UI area, it didn't look something that the patch I was reviewing could have regressed and so I looked into bisecting the actual regression change (that I expected it to be pretty recent change too).

I ended up bisecting it manually (without mozregression or hg bisect) because while taking a look into the changes we applied recently on the moz-toggle button I noticed that Bug 1917305 could be likely be related and I opted to verify manually that I wasn't able to reproduce the regression anymore after moving my working tree to the parent of the first patch landed from Bug 1917305 on central (and that it was reproducible on the last patch part of Bug 1917305).

Looking more closely to the change I also confirmed that this part of "Bug 1917305 - Part 2:" https://hg.mozilla.org/integration/autoland/rev/168f6caa3b16#l4.145 replaced the previous lit template where the span containing the label was right before the input toggle button element, while after that patch we inherit the template from MozBaseInputElement where the input toggle button element and span element for the label are reversed (and so the input element come first and the span element right before that), which also match what observed in the attached screenshot before/after state of the resulting about:addons UI.

Reverting all of Bug 1917305 changes due to this visual regression feels a bit overkill, and I wouldn't exclude that we may want to also consider other options, e.g.:

• have moz-toggle to provide an additional attribute to opt-in a specific moz-toggle instance in the previous order of input and span elements
• or to confirm with UX if we would instead prefer to keep the new order but align the toggle buttons with the list of non-optional permissions that is right above the optional-permissions list,
• or maybe to consider a combination of both (e.g. a new moz-toggle attribute to fix the visual regression first by opt-in to the previous order of input and span elements, and then separate followup to tweak the UX design so that wouldn't need that attribute anymore).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

:hjones, since you are the author of the regressor, bug 1917305, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Hanna Jones [:hjones]]

Just a bit of context from the recomp team - this was an intentional visual/structural change to the toggle. This change fixes some accessibility issues with the moz-toggle component by moving the toggle button closer to the label. It also makes the toggle more consistent with our other input elements like radio buttons and checkboxes that always follow the structure of <input/button element> <label element>. This change was driven by UX and I think an announcement went out in some UX channels about the reasoning, but we need to get better about communicating these kinds of reusable components changes via dev channels as well.

Due to to the motivations/reasoning behind this change the recomp team would prefer to fix this bug by aligning the toggle buttons with the list of non-optional permissions, though if that's not possible or sufficient for whatever reason we are happy to discuss alternative solutions.

Comment 3

[Eiichi]

See also Bug 1937715

Comment 4

[Rob Wu [:robwu]]

Hanna - has there been an effort to audit current uses of moz-toggle that are affected by this? If yes, where is the overview?

There are currently two reported regressions. I'm slightly concerned that there are more.

And if there are more situations where the visual appearance changed, then this needs to be reflected in user documentation. For example:

• (this bug) https://support.mozilla.org/en-US/kb/manage-optional-permissions-extensions
• (bug 1937715) https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop

P.S. Since we're on the topic of accessibility anyway - even before the moz-toggle repositioning change I found it slightly user-unfriendly that the permission toggle was relatively far away from the label, without any visual feedback on what the toggle belongs to when hovered. I thought of adding a :hover style that added a subtle background change or outline/border of the whole permission label, but never got to actually doing that. With the toggle now being closer to the label, I wonder whether it would still make sense to do something like this with the toggle: hovering the label changes the appearance of the toggle, but hovering the toggle does still not draw attention to the label it belongs to.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 1937627 - Align about:addons optional permissions and granted permissions labels, toggle buttons and green checkmarks.

Comment 6

[Hanna Jones [:hjones]]

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

Hanna - has there been an effort to audit current uses of moz-toggle that are affected by this? If yes, where is the overview?

Hi Rob - the reusable components team is aware of all locations where moz-toggle is used and did a manual visual audit + ran any tests that cover these areas to ensure nothing was changing beyond the desired, UX-driven change of moving the toggle button position. We consulted with teams when code changes were required, but clearly our communication efforts on the dev front were not extensive enough. We will take this into consideration and be sure to give all potentially impacted teams an advanced heads up next time so that we can try to address concerns in advance since nobody likes a surprise, even if it's well intended.

And if there are more situations where the visual appearance changed, then this needs to be reflected in user documentation. For example:

• (this bug) https://support.mozilla.org/en-US/kb/manage-optional-permissions-extensions
• (bug 1937715) https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop

Thanks for calling this out - I'll take a look at the different surfaces and try to file bugs/loop in the SUMO folks as needed.

P.S. Since we're on the topic of accessibility anyway - even before the moz-toggle repositioning change I found it slightly user-unfriendly that the permission toggle was relatively far away from the label, without any visual feedback on what the toggle belongs to when hovered. I thought of adding a :hover style that added a subtle background change or outline/border of the whole permission label, but never got to actually doing that. With the toggle now being closer to the label, I wonder whether it would still make sense to do something like this with the toggle: hovering the label changes the appearance of the toggle, but hovering the toggle does still not draw attention to the label it belongs to.

That's an interesting suggestion - I don't think we've considered providing visual feedback on the associated label when the control is hovered since that's not standard for input elements like checkbox/radio, and that's where we've been taking our cues from. It could definitely be worth getting UX + a11y feedback on that though. If you want to file a bug/enhancement for that as part of this meta bug or somewhere in Toolkit::UI Widgets we could discuss more there.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cbef57602b65
Align about:addons optional permissions and granted permissions labels, toggle buttons and green checkmarks. r=desktop-theme-reviewers,robwu,hjones

Comment 8

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/cbef57602b65

Comment 9

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (136.0a1/20250109183505) and Beta (135.0b2/20250108092002) under Windows 10, Ubuntu 24.04 LTS and macOS 11.3.1.

The optional permissions and granted permissions labels as well as the toggle buttons and green checkmarks are now aligned in about:addons. See attached screenshot for more details.

Comment 10

[Alex Cornestean]

Attachment: 2025-01-10_10h48_26.png