"Inspect Accessibility Properties" menu item should not be visible if accessibility services are not enabled
Categories
(DevTools :: Accessibility Tools, defect)
Tracking
(firefox78 fixed)
| Tracking | Status | |
|---|---|---|
| firefox78 | --- | fixed |
People
(Reporter: glob, Assigned: yzen)
References
Details
Attachments
(1 file)
Nightly: 78.0a1 (2020-05-06) (64-bit) on MacOS
"Inspect Accessibility Properties" menu item should not be visible if accessibility services are not enabled.
Having it added as the bottom-most menuitem on the context menu breaks my "Inspect Element" muscle memory, and is particularly painful given that it takes me to a devtools tab that is not functional.
|
||
Comment 1•6 years ago
•
|
||
(In reply to Byron Jones ‹:glob› 🎈 from comment #0)
Nightly: 78.0a1 (2020-05-06) (64-bit) on MacOS
"Inspect Accessibility Properties" menu item should not be visible if accessibility services are not enabled.
This is intentional if devtools.accessibility.auto-init.enabled pref is set to true. With the landing of bug 1602075, the new menu item should be visible and the accessibility panel is auto initialized if you select the new item.
Having it added as the bottom-most menuitem on the context menu breaks my "Inspect Element" muscle memory, and is particularly painful given that it takes me to a devtools tab that is not functional.
The last part of this is concerning; the panel initializes and works as expected for me. ni? yzen for thoughts on this.
This is intentional if devtools.accessibility.auto-init.enabled pref is set to true
Thank you; I've toggled this to false because muscle memory is a blessing and a curse.
Something I realised after filing this bug is I have the Prevent accessibility services from accessing your browser option enabled in Preferences; this is likely the root cause of the accessible panel not working.
Perhaps the accessibility menu-item shouldn't be initialised when accessibility.force_disabled is set to 1?
|
Assignee | |
Comment 3•6 years ago
|
||
(In reply to Byron Jones ‹:glob› 🎈 from comment #2)
This is intentional if devtools.accessibility.auto-init.enabled pref is set to true
Thank you; I've toggled this to
falsebecause muscle memory is a blessing and a curse.Something I realised after filing this bug is I have the
Prevent accessibility services from accessing your browseroption enabled in Preferences; this is likely the root cause of the accessible panel not working.Perhaps the accessibility menu-item shouldn't be initialised when
accessibility.force_disabledis set to1?
Yeah that's probably reasonable.. I'll check with the team too.
|
|
||
Comment 4•6 years ago
|
||
Setting to S3 because it does seem somewhat broken if accessibility.force_disabled is 1.
|
|
Assignee | |
Comment 5•6 years ago
|
||
|
||
Updated•6 years ago
|
|
|
||
Updated•6 years ago
|
|
||
Comment 7•6 years ago
|
||
| bugherder | ||
Looks like this fix resolves my side comment about the ordering of the item (thanks!) but not the primary issue of the menu item being visible when accessibility services are disabled.
Sean - should I reopen this bug or file a new one to address this issue, or is the omission of that change from the patch a signal that it won't be addressed? I'm not fussed if the visibility concern isn't addressed (ie. comment 4), I just want to make sure it wasn't accidentally overlooked.
|
|
Assignee | |
Comment 9•6 years ago
•
|
||
(In reply to :glob (Byron Jones) 🎈 from comment #8)
Looks like this fix resolves my side comment about the ordering of the item (thanks!) but not the primary issue of the menu item being visible when accessibility services are disabled.
Sean - should I reopen this bug or file a new one to address this issue, or is the omission of that change from the patch a signal that it won't be addressed? I'm not fussed if the visibility concern isn't addressed (ie. comment 4), I just want to make sure it wasn't accidentally overlooked.
I opened a bug 1639921 specific to the issue in comment 4 and other bits that might be involved.
Description
•