239867 - [meta] Refine Atk information exported from mozilla

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Louie Zhao]

Since some Atk information exported from mozilla, e.g. AtkState of AtkObject are
different from GNOME applications, the interaction between mozilla and GNOME
Assistive Software, e.g. gnopernicus, gok has some problem.

This bug is to refine Atk information exported from mozilla. We can refer to
GNOME Applications, e.g. yelp (using $yelp [URL]), and the implementation of GAIL.

Comment 1

[Louie Zhao]

Attachment: patch v1

This patch enabled mozilla to work with the latest GNOME desktop (including gok
and gnopernicus).

Comment 2

[Louie Zhao]

Attachment: patch v1

This is the right one.

Comment 3

[Kyle Yuan]

Comment on attachment 145605 [details] [diff] [review]
patch v1

looks good to me. r=kyle.

Comment 4

[Aaron Leventhal]

What's happening with this one?

I think this comment should say "role" not "state"
+  // Other state from atk.h
+  enum { ROLE_ACCEL_LABEL = 1U };          // ATK_ROLE_ACCEL_LABEL
+  enum { ROLE_ARROW  = 4U };               // ATK_ROLE_ARROW
+  enum { ROLE_CANVAS = 6U };               // ATK_ROLE_CANVAS
+  enum { ROLE_CHECK_MENU_ITEM = 8U };      // ATK_ROLE_CHECK_MENU_ITEM

Louie, you're the general owner of ATK bugs now, right? Assign them to me if I
need to write the patch, or CC me otherwise.

Comment 5

[Louie Zhao]

> I think this comment should say "role" not "state"
Yes, there should be "role" instead of "state".

> Louie, you're the general owner of ATK bugs now, right? Assign them to me if I
> need to write the patch, or CC me otherwise.

Yes, now I am focusing on ATK bugs now. Acutally we have worked in our internal
codebase (Mozilla 1.4 / 1.6 based) for a period of time. Some of the patches
work fine and we should put them into trunk. (Some of them are not good enough,
so we hold them). I am very glad you have come back to work on this. I will CC
you if I file any new bug.

Comment 6

[Philip K. Warren]

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

Comment 7

[Philip K. Warren]

-    if (!(aState & nsIAccessible::STATE_UNAVAILABLE))
+    if (!(aState & nsIAccessible::STATE_UNAVAILABLE)) {
         atk_state_set_add_state (state_set, ATK_STATE_ENABLED);
+        atk_state_set_add_state (state_set, ATK_STATE_SENSITIVE);
+    }

What does this do? I have looked at the ATK documentation for
ATK_STATE_SENSITIVE and it states:

"ATK_STATE_SENSITIVE	 Indicates this object is sensitive"

Can you explain the meaning of ATK_STATE_SENSITIVE?

Comment 8

[Aaron Leventhal]

Why do we use STATE_UNAVAILABLE for so many of the objects?

I thought STATE_UNAVAILABLE is for objects that are currently disable, liek a
grayed out menu item. (Thanks to pkw for noticing).

Comment 9

[Louie Zhao]

(In reply to comment #8)
> Why do we use STATE_UNAVAILABLE for so many of the objects?
> 
> I thought STATE_UNAVAILABLE is for objects that are currently disable, liek a
> grayed out menu item. (Thanks to pkw for noticing).

Yes, this is right. STATE_UNAVAILABLE is for disabled object. In

nsAccessible::GetState(PRUint32 *aState)
nsFormControlAccessible::GetState(PRUint32 *_retval)
nsHTMLTextFieldAccessible::GetState(PRUint32 *_retval)
nsXULButtonAccessible::GetState(PRUint32 *_retval)
 
they will judge whether current element is disable, if YES, set
STATE_UNAVAILABLE. In
http://lxr.mozilla.org/seamonkey/source/accessible/src/atk/nsAccessibleWrap.cpp#502
if element has no STATE_UNAVAILABLE, ATK_STATE_ENABLED will be set. After
examing atk state exported by GNOME app, ATK_STATE_SENSITIVE always goes with
ATK_STATE_ENABLED, that's why we have patch below:

-    if (!(aState & nsIAccessible::STATE_UNAVAILABLE))
+    if (!(aState & nsIAccessible::STATE_UNAVAILABLE)) {
         atk_state_set_add_state (state_set, ATK_STATE_ENABLED);
+        atk_state_set_add_state (state_set, ATK_STATE_SENSITIVE);
+    }

Comment 10

[Louie Zhao]

In order to make it convenient to review and discuss the patch, I devide the
patch into several parts according to the bug symptom. Please see the "depends
on" sections above.

Comment 11

[Aaron Leventhal]

Can we close this bug since the last part of it is in bug 241055?

Comment 12

[Louie Zhao]

Close this bug.