Duplicated menus in ATK accessibility build

RESOLVED DUPLICATE of bug 277750

Status

()

Core
Disability Access APIs
RESOLVED DUPLICATE of bug 277750
14 years ago
13 years ago

People

(Reporter: Philip K. Warren, Assigned: Louie Zhao)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

902 bytes, patch
neil@parkwaycc.co.uk
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
When viewing Mozilla under at-poke, I see duplicated menus (but not menuitems).
For example, the hierarchy in at-poke looks something like this:

...
  File ->
    File ->
      New ->
        New ->
      Open Web Location
...

I also see this when navigating through Mozilla's menus in GOK.
(Reporter)

Comment 1

14 years ago
I believe this is a side effect of the checkin for Bug 242589. It removed the
following from nsAccessibilityService.cpp which prevented menu popup accessibles
from being created for invisible/offscreen menus:

-    PRUint32 role, state;
-    newAcc->GetRole(&role);
-    // don't create the accessible object for popup widget when it's not visible
-    if (role == nsIAccessible::ROLE_MENUPOPUP) {
-      newAcc->GetState(&state);
-      if (state & (nsIAccessible::STATE_INVISIBLE |
nsIAccessible::STATE_OFFSCREEN))
-        return NS_ERROR_FAILURE;
     }
(Reporter)

Comment 2

14 years ago
I'm not sure what the proper fix for this bug should be. I first considered not
creating accessible objects for <menupopup> XUL elements, thinking that we would
only need to expose the <menu> XUL elements. This doesn't work in all cases
however, since there are instances where <menupopup> XUL elements are used
without using a <menu> to wrap them.

I then tried making <menupopup> XUL elements use the ATK role
ATK_ROLE_POPUP_MENU instead of ATK_ROLE_MENU. With this change, the hierarchy in
at-poke looks like this:

-> File (menu)
  -> File (popup menu)
    -> New (menu)
      -> New (popup menu)
      ...
    -> Open Web Location (menu item)

This looks closer to what we want, however this broke navigation of the menus in
GOK.

Comment 3

14 years ago
The redundancy in the hierarchy is not good.  It's inconsistent with other
toolkits, and confusing to ATs.  The proper hierarchy is:

File (menu)
  New (menu)
    Navigator Window (menu item)
    Navigator Tab (menu item)
    ...
  Open Web Location (menu item)

etc.
(Reporter)

Comment 4

14 years ago
I'm beginning to think that we shouldn't create accessible objects for
<menupoup> at all. Since almost all <menupopup> elements have a <menu> parent
element, we would be pretty safe doing this. I went through all of the Mozilla
suite in DOM inspector, and found only a few instances where <menupopup> is used
without being contained in a <menu> element:

- <toolbarbutton type="menu"> or <toolbarbutton type="menu-button">. I plan on
fixing these cases in Bug 249292.
- The url bar history widget, where the autocomplete history is implemented as a
<menupopup> element with a <textbox> parent. I'm not really sure what to do here.
- The popup blocker menu, where a <menupopup> is a child of <popupset>.

Comment 5

14 years ago
I think Sun already has a fix for this. Correct?

Louie, can you see if there's a patch we can apply to the trunk for this?
Assignee: aaronleventhal → Louie.Zhao
(Assignee)

Comment 6

14 years ago
Created attachment 159835 [details] [diff] [review]
patch v1

I search the checkin list and found the fix, which is quite straightforward --
don't create accessible object for menupopup. At present, I have no time to
verify whether this patch works fine with trunk code because we have several
fixes in popup.xml for other issues.

Updated

13 years ago
Attachment #159835 - Flags: superreview?(neil.parkwaycc.co.uk)

Comment 7

13 years ago
(In reply to comment #4)
>- The url bar history widget, where the autocomplete history is implemented as a
><menupopup> element with a <textbox> parent. I'm not really sure what to do here.
This works like an editable menulist, if that's any help?
> - The popup blocker menu, where a <menupopup> is a child of <popupset>.
That's a context menu. Or do you need it to be a <popup>?

Comment 8

13 years ago
Comment on attachment 159835 [details] [diff] [review]
patch v1

A popup's parent should never be a menulist. sr=me if you fix the condition on
the following line.
Attachment #159835 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+

Comment 9

13 years ago
Comment on attachment 159835 [details] [diff] [review]
patch v1

We also need to patch toolkit.

Hmm, how would createXULSelectListAccessible ever get called if we remove that
rule?
(Reporter)

Comment 10

13 years ago

*** This bug has been marked as a duplicate of 277750 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.