235687 - ATK menu hierarchy is missing most menu items

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Bill Haneman]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031103

The basic ATK hierarchy for the Mozilla main menu bar seems broken.  Most of the
menu items visible to the user are not displayed (for instance, the File menu
only contains two items, "New" and "Send Page...", and the other toplevel menus
are empty).

Also - the menu items expose AtkActions which are also broken - but I will file
a separate bug on that issue.

Reproducible: Always
Steps to Reproduce:
1.Go to gnome environment with accessibility gconf key "true".
2.start mozilla
3.start at-poke, "poke" mozilla, and "expand".

Actual Results:  
Issues is visible in ATK hierarchy as displayed by at-poke: menus are missing
many children.



Expected Results:  
All of the menu items which are displayable in the mozilla menus should have
appeared in the ATK/at-poke hierarchy.

marking "normal" severity, but it's not "normal" to a user of assistive
technology, who relies on these items being exposed correctly.  This bug will
prevent some users from being able to use mozilla at all.

Comment 1

[Bill Haneman]

please see gnome's bugzilla entry:
http://bugzilla.gnome.org/show_bug.cgi?id=135314
which is blocked by this bug.

Comment 2

[Bill Haneman]

see related bug 235690

Comment 3

[Kyle Yuan]

-> Louie

Comment 4

[Kyle Yuan]

This is because all menus in mozilla are written in XUL, and most of them are
generated at run-time, for example, the "Go" menu, it will get the history
information of current tab/window before it gets popped up.

XUL menu has an attribute called "menugenerated". Setting it to true can make
the menu hierarchy build up at start up. I do have a patch for this, will post
it here later.

Comment 5

[Kyle Yuan]

Attachment: proposed patch

add menugenerated="true" to all top level menus.

Comment 6

[Kyle Yuan]

*** Bug 193795 has been marked as a duplicate of this bug. ***

Comment 7

[Kyle Yuan]

Neil, we need to get all sub-menu items without opening the top menu. People
with disablities need this feature to manipulate the software. Do you think my
patch is a proper way to implement this? Will it cause any side-effect for mozilla?

Comment 8

[[e-mail]]

This doesn't look like a good idea to me, it's too inflexible. Perhaps you can
make the accessibility handlers poke the menugenerated attributes if someone is
trying to access the menu? As I don't know anything about the accessibility APIs
I would have to guess at fixing nsXULMenuitemAccessible::GetChildCount

Comment 9

[Kyle Yuan]

Sounds much better than mine :)

Comment 10

[Kyle Yuan]

Attachment: new patch

generate sub-menu items (if necessary) on
nsXULMenuitemAccessible::GetChildCount

Comment 11

[[e-mail]]

I really have no idea if your code works at all, but you might find you have to
loop through all the child nodes to find the menupopup.

Comment 12

[Kyle Yuan]

Attachment: loop all children to find menupopup

I tested. It really works.

Comment 13

[Louie Zhao]

Comment on attachment 142893 [details] [diff] [review]
loop all children to find menupopup

The patch works for me.

Comment 14

[Henry Jia]

Comment on attachment 142893 [details] [diff] [review]
loop all children to find menupopup

sr=Henry

Comment 15

[Kyle Yuan]

checked in.

Comment 16

[Aaron Leventhal]

+      if (element) {
+        nsAutoString attr;
+        element->GetAttribute(NS_LITERAL_STRING("menugenerated"), attr);
+        if (!attr.Equals(NS_LITERAL_STRING("true"))) {
+          element->SetAttribute(NS_LITERAL_STRING("menugenerated"),
NS_LITERAL_STRING("true"));

You should just be able to do:
if (element) {
+          element->SetAttribute(NS_LITERAL_STRING("menugenerated"),
NS_LITERAL_STRING("true"));
}