If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Accessibility API is given wrong information on Bookmarks menu items (stop using alternates for Cmd- and Shift- handling on Bookmarks and History menu items)

NEW
Unassigned

Status

Camino Graveyard
Accessibility
7 years ago
7 years ago

People

(Reporter: Hisham, Unassigned)

Tracking

(Blocks: 1 bug)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.19) Gecko/2010051911 Camino/2.0.3 (like Firefox/3.0.19)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.19) Gecko/2010051911 Camino/2.0.3 (like Firefox/3.0.19)

Do this: Use Apple's Accesibility Inspector app and take a look at Camino's Bookmark's menuitem. The problem: each bookmark is provided thrice (3 times) to OS X's accessibility framework. This affects several apps which use the accessibility framework to access the menubar, including MenuEverywhere. In these apps, the Bookmarks menuitems will show three copies each.


Reproducible: Always

Steps to Reproduce:
1.Use Accessibility Inspector
2.Select the Bookmarks menu item
3. Hit CMD-F7 to freeze Accessibility Inspector and inspect Bookmark's accessibility info.
Actual Results:  
Bookmark menu item reports to Accessibility Inspector three copies of each menu item in Bookmarks.

Expected Results:  
Only one copy of each menu item should be reported to Accessibility Inspector and other accessibility framework apps.

You can see this bug rise up in any app that uses Apple's accessiblity framework, such as Accessibility Inspector or MenuEverywhere.
I'm not sure that there's a way to use alternates and then turn around and lie to the a11y API to make it think we're not using alternates.
(Reporter)

Comment 2

7 years ago
I don't understand your comment. What is ally? And what do alternate menu items have to do with the bookmark menu items? As far as I can see, the bookmark has no alternate menu items (unless I'm pressing the wrong modifiers to show them up). This has to do with simply the menuitems being given thrice to the accessibility api, or rather, that the menuitems are for some reason stored in three copies internally, or the menuNeedsUpdate:(NSMenu*)menu method is at fault.

Comment 3

7 years ago
You can't see the alternates because they look the same, but they are there. Prior to 10.5 (or is it 10.6?) it's the only reliable way of knowing what modifier keys were pressed when the item was selected. 

Unfortunately I think the change in NSEvent reporting may be SDK-based, so we can't conditionalize the behavior at runtime. Someone would need to check the AppKit release notes to be sure.
(In reply to comment #3)
> Unfortunately I think the change in NSEvent reporting may be SDK-based, so we
> can't conditionalize the behavior at runtime. Someone would need to check the
> AppKit release notes to be sure.

Bug 363895 comment 8 ("linked on or after Leopard", whatever that actually ends up meaning)

Comment 5

7 years ago
It's ambiguous, and I don't know if there's a clarifying explanation anywhere. It *could* mean it's only the build machine that matters. We should do some tests.
Blocks: 603048
Confirming; we can use this bug to track removal of the alternates on Bookmarks (and History) if/where possible.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Accessibility API is given wrong information on Bookmarks menu items → Accessibility API is given wrong information on Bookmarks menu items (stop using alternates for Cmd- and Shift- handling on Bookmarks and History menu items)
You need to log in before you can comment on or make changes to this bug.