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

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Accessibility, defect)

Description

[Hisham]

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.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 2

[Hisham]

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

[Stuart Morgan]

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.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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

[Stuart Morgan]

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.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Confirming; we can use this bug to track removal of the alternates on Bookmarks (and History) if/where possible.