2015485 - The "Ask" button from the toolbar does not have a Clicked State

Status: VERIFIED FIXED

(Core :: Machine Learning: Frontend, defect, P1)

Description

[Rares Doghi, Desktop QA]

Attachment: 2026-02-09_16h36_58.mp4

Found in

• Nightly 149.0a1 (2026-02-09)

Affected versions

• Nightly 149.0a1 (2026-02-09)

Affected platforms

• All

Steps to reproduce

1. Switch to a Smart window.
2. Reach any website.
3. Click and Hold the left mouse click on top of the ASK button from the Toolbar.

Expected result

• The Ask button should also have a clicked state.

Actual result

• There is no clicked state for the Ask button from the toolbar.

Regression range
N/A

Comment 1

[Eitan Isaacson [:eeejay]]

It needs the checked toolbarbutton attribute.

Comment 2

[:jlewis]

Attachment: Bug 2015485 - The Ask button from the toolbar does not have a Clicked State r=#accessibility-frontend-reviewers

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3b316e9a8761
https://hg.mozilla.org/integration/autoland/rev/380146f515f2
The Ask button from the toolbar does not have a Clicked State r=accessibility-frontend-reviewers,desktop-theme-reviewers,ai-frontend-reviewers,echa,morgan,dao

Comment 4

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/380146f515f2

Comment 5

[BugBot [:suhaib / :marco]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 6

[BugBot [:suhaib / :marco]]

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

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox150 to wontfix.

For more information, please visit BugBot documentation.

Comment 8

[Rares Doghi, Desktop QA]

Verified as fixed in our latest Nightly 151.0a1 (2026-04-15)

Comment 9

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: This is an S2 accessibility bug - 'Ask' button is a core feature of the Smart Window and should be accessible to users.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: 1. Enable/open Smart Window

2. Use screen reader / Voice Over
3. Navigate to 'Ask' button - its checked/unchecked + expanded/closed state should be explicit to those using assistive technology

• Risk associated with taking this patch: low
• Explanation of risk level: Ask button's component is changed to a checkbox type element. Small architectural change but requires care as its a key part of the chrome in Smart Window.
• String changes made/needed?: No
• Is Android affected?: no

Comment 10

[:jlewis]

Attachment: Bug 2015485 - The Ask button from the toolbar does not have a Clicked State

Original Revision: https://phabricator.services.mozilla.com/D291233

Comment 11

[:jlewis]

Attachment: Bug 2015485 - The Ask button from the toolbar does not have a Clicked State

Original Revision: https://phabricator.services.mozilla.com/D291233

Comment 12

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: This is an S2 accessibility bug - 'Ask' button is a core feature of the Smart Window and should be accessible to users.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: 1. Enable/open Smart Window

2. Use screen reader / Voice Over
3. Navigate to 'Ask' button - its checked/unchecked + expanded/closed state should be explicit to those using assistive technology

• Risk associated with taking this patch: low
• Explanation of risk level: Ask button's component is changed to a checkbox type element. Small architectural change but requires care as its a key part of the chrome in Smart Window.
• String changes made/needed?: No
• Is Android affected?: no

Comment 13

[Rares Doghi, Desktop QA]

Attachment: Pressed.mp4

Noticed a minor issue here @mardak @ayeddi, it seems that the pressed not pressed expanded collapsed states keep changing when we use keyboard and then mouse clicks, not sure if this is ok, can you take a look ?

If I Use keyboard navigation to open and close the Ask Sidebar it will read it as not pressed collapsed, pressed expanded, but after changing to mouse clicks something happens and not pressed becomes expanded, pressed becomes collapsed, please take a look at the video.

Comment 14

[Rares Doghi, Desktop QA]

Also the issue here is not about the Voice over, when we Clicked and Hold the button using the Left mouse click, it wouldnt show that state as if the user is Clicking it, now it does.

Also I think the Screen reader state issue is fixed here with Bug 2017166 ? I tested in our latest Nightly and we do have the state read by Screen readers but with a minor issue encountered mentioned in the previous comment.

Comment 15

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Attachment: NVDA output for an expanded sidebar with a comment that “Pressed” state does not update when button is activated with a screen reader

(In reply to Rares Doghi, Desktop QA from comment #13)

Created attachment 9571535 [details]
Pressed.mp4

Noticed a minor issue here @mardak @ayeddi, it seems that the pressed not pressed expanded collapsed states keep changing when we use keyboard and then mouse clicks, not sure if this is ok, can you take a look ?

If I Use keyboard navigation to open and close the Ask Sidebar it will read it as not pressed collapsed, pressed expanded, but after changing to mouse clicks something happens and not pressed becomes expanded, pressed becomes collapsed, please take a look at the video.

Oh, this is a bug, thank you for catching it up, :Rares! It'll be access-S3 issue because it creates confusion for screen reader users (especially, those with vision who are likely to combine the mouse and keyboard use, i.e. someone with dyslexia)

The issue:

The pressed state does not update when button is activated with a screen reader, while aria-expanded is being updated as expected. I left a comment with a remediation recommendation in the patch for a related Bug 2017166 - the pressed state is likely coming from the checkbox type added to the toolbarbutton, which is redundant to the aria-expanded and is kind of a gray area for the markup clarity.

Recommendation:

As I mentioned in the patch D294362, I'd kept the aria-expanded state - because it more clearly signals to a user that there is, in fact, some additional content being shown or hidden. Plus, it seems that the logic for the expanded state is working well.

Expected behavior:

Screen reader announces the role (button) and only one state (expanded or collapsed) that is corresponds with the visibility of the sidebar (open or hidden)

Comment 16

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Clarifying: I still think the initial bug fix should/could be uplifted, because it would resolve a more severe bug than the remaining part of the bug that we described with Rares above.

Comment 17

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/4f2df6e14ab6
https://hg.mozilla.org/releases/mozilla-release/rev/2c1f44ae90cd

Comment 18

[Rares Doghi, Desktop QA]

The main issue reported + the NVDA button state issues are both verified as fixed in our latest Release 150.0.1, only the issue I mentioned in comment 13 remains.