623927 - Expose 'Gecko' as the 'toolkit' via an AtkObject attribute

Status: REOPENED

(Core :: Disability Access APIs, enhancement)

Description

[Joanmarie Diggs]

Because applications can and do embed Gecko content, it is not always reliable for an assistive technology to use akt_util_get_toolkit_name(). That method only reports what the parent application toolkit happens to be.

We need toolkits to report themselves at the widget level. And the only way to do this, at the moment, seems to be as an attribute of the AtkObject associated with each widget, e.g. 'toolkit':'Gecko'.

FWIW, WebKitGtk does this now ('toolkit':'WebKitGtk') and it's quite helpful in Orca's ability to present information from Yelp 3.0 and Epiphany.

Comment 1

[Fernando Herrera]

Attachment: Patch adding "toolkit" attibute to AtkObjects

Comment 2

[Ginn Chen]

MAI_NAME is defined in src/atk/nsApplicationAccessibleWrap.cpp

It should not be defined in 2 places.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> MAI_NAME is defined in src/atk/nsApplicationAccessibleWrap.cpp
> 
> It should not be defined in 2 places.

and nsApplicationAccessibleWrap should use nsApplicationAccessible.

Fernando, do you want to take a bug?

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #0)

> We need toolkits to report themselves at the widget level. And the only way to
> do this, at the moment, seems to be as an attribute of the AtkObject associated
> with each widget, e.g. 'toolkit':'Gecko'.

Joanie, why can't get_toolkit_name on AtkUtilClass be used instead an object attribute?

> FWIW, WebKitGtk does this now ('toolkit':'WebKitGtk') and it's quite helpful in
> Orca's ability to present information from Yelp 3.0 and Epiphany.

It's good point to be compatible with other applications and if you think it's worth to follow them then we can do this I think.

Comment 5

[Fernando Herrera]

(In reply to comment #4)
> Joanie, why can't get_toolkit_name on AtkUtilClass be used instead an object
> attribute?

get_toolkit is not so useful when an application mixes two toolkits, like for example yelp using gtk for its chrome and gecko for html rendering.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #5)
> (In reply to comment #4)
> > Joanie, why can't get_toolkit_name on AtkUtilClass be used instead an object
> > attribute?
> 
> get_toolkit is not so useful when an application mixes two toolkits, like for
> example yelp using gtk for its chrome and gecko for html rendering.

Does gecko creates an application accessible in this case? It should.

Is there a way to get AtkUtilClass for Gecko part?

Comment 7

[alexander :surkov (:asurkov)]

Ping?

Comment 8

[Fernando Herrera]

If we are going to add the toolking name attribute, it makes sense to add also the toolkit version.

The patch will be less hacky if we add the "custom" attributes inside ConvertToAtkAttributeSet function (because they are atk attributes and not genereci ns attributes).

Finally, if I am correct we do not support embedding Gecko anymore, so the case where you have two diferent toolkits like Gtk embedding Gecko is not possible anymore.

Comment 9

[alexander :surkov (:asurkov)]

Fernando, I have to ask you. When you do the comment providing some summary then please specify where it comes from. Otherwise it sounds that it's your personal observations and not a result of group discussion. Group decision is probably what we just should follow, personal observations are probably what should be discussed more.

Comment 10

[Fernando Herrera]

Attachment: Updated patch

Yeah, sorry. We were discussing this during the Atk hackfest and we (Joanie, Alexander, API and me) that it would be nicer so have some kind of AtkToolkit interface, but that cannot be done until Atk 2.0. In the meantime we agreed that a temporary solution can be having it as an attribute.

Regarding the old patch, I uploading a new version doing two things after Alexander comments:
- Moving the custom Atk attributes adition into the ConvertToAtkAttributeSet function
- Using nsApplicationAccessible::GetPlatformName to retrive our toolkit name (and GetPlatformVersion for toolkit version) instead of having those MAI_NAME and MAI_VERSION.

However, I see two problems with this patch:
- If we move the haspopup attribute adition into ConvertToAtkAttributeSet we need to modify the function prototype to pass also the accessible.
- Using nsApplicationAccessible::GetPlatformName is much more lines of code (and calls) than using a compilation time define.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to comment #10)
 
> Regarding the old patch, I uploading a new version doing two things after
> Alexander comments:
> - Moving the custom Atk attributes adition into the ConvertToAtkAttributeSet
> function

> However, I see two problems with this patch:
> - If we move the haspopup attribute adition into ConvertToAtkAttributeSet we
> need to modify the function prototype to pass also the accessible.

I didn't mean that. What I said is add atk specific attributes directly to atkrelationset. ConvertToAtkAttributeSet should convert gecko attributes, nothing else.

> - Using nsApplicationAccessible::GetPlatformName to retrive our toolkit name
> (and GetPlatformVersion for toolkit version) instead of having those
> MAI_NAME and MAI_VERSION.
> 

> - Using nsApplicationAccessible::GetPlatformName is much more lines of code
> (and calls) than using a compilation time define.

You can extend/change nsApplicationAccessible for that.

Comment 12

[Eitan Isaacson [:eeejay]]

Like fer said, you can't embed Gecko anymore. So this issue will never show up again :)

Comment 13

[alexander :surkov (:asurkov)]

(In reply to Eitan Isaacson [:eeejay] from comment #12)
> Like fer said, you can't embed Gecko anymore. So this issue will never show
> up again :)

I don't recall a reason why it's still needed but I hope Joanie can give a hint. If occasionally we don't need to fix it then uploaded patch has some cleaningups and we should take them (file new bug for that or rename this one).

reopen for now (to make sure we don't loose it by chance)

Comment 14

[Joanmarie Diggs]

If it will never, ever be the case where the reported toolkit of a Gecko application  can be something other than Gecko, I suppose it is no longer needed.

Comment 15

[alexander :surkov (:asurkov)]

Thanks, Joanie. So let's take cleaning up from uploaded patch and close the bug or if you like close this one and file new one for cleaning up.

Comment 16

[Joanmarie Diggs]

And also please do the same for your chrome (i.e. XUL or whatever). Thanks!

Comment 17

[alexander :surkov (:asurkov)]

Some summary of the discussion with Joanie. Orca has different processing of XUL and web content, and thus it needs to know where the user is. Historically Orca relies on toolkit object attribute for that. For example, epiphany browser exposes 'toolkit:gtk' for browser UI accessible objects, web content object exposes 'toolkit:webkitgtk'. To make Gecko compatible with ATK practices the suggestion is
1) expose 'toolkit:gecko' for content
2) expose 'toolkit:geckoxul' for browser UI