309789 - Firefox reports itself as "mozilla" to the a11y framework -- "Mozilla" should be the toolkit name

Status: RESOLVED DUPLICATE of bug 321081

(Core :: Disability Access APIs, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Moving upstream from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169146

Description of problem:
Firefox reports itself as "mozilla" to the a11y framework.

Version-Release number of selected component (if applicable):
firefox-1.1-0.2.8.deerpark.alpha2

How reproducible:
100%

Steps to Reproduce:
1.  Launch firefox
2.  Launch at-poke
  
Actual results:
Firefox has name and description of "Mozilla" (looking elsewhere it appears that
the description is set to "Mozilla Root Accessible"; perhaps at-poke is buggy)

Expected results:
Firefox should have name of "Firefox", or some way of identifying it.

Additional info:

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Proposed patch

Comment 2

[Louie Zhao]

Comment on attachment 197198 [details] [diff] [review]
Proposed patch

This patch is simple and straightforward.

Comment 3

[Aaron Leventhal]

Actually calling it Mozilla all the time has some advantages for the screen readers. They can determine what script to load based on the toolkit. Too bad we can't expose what the toolkit type is somehow as separate info.

Pete, Will -- is it alright if we use the correct name of the app for the app root accessible? Will that mess you up in terms of other apps like Thunderbird and xulrunner apps you don't even know about yet?

Comment 4

[parente]

For LSR, it's probably better if the at-spi application name is descriptive of the actual application (Firefox, Thunderbird, <some xul app>). That way, the screen reader scripts can be keyed specifically to what the application does. For instance, my Firefox script is probably going to be very different from my Thunderbird script.

If you keep the same name for all Gecko apps, then the screen reader has to use some dirty hacks to determine what script it should actually load. For instance, it might look at the structure of the accessible hierarchy to distinguish Firefox from Thunderbird.

You could, potentially, expose the toolkit as an object attribute (once it's implemented in atk and at-spi).

Comment 5

[[e-mail]]

Comment on attachment 197198 [details] [diff] [review]
Proposed patch

>-    aDescription.AssignLiteral("Mozilla Root Accessible");
>+    aDescription.AssignLiteral(NS_STRINGIFY(MOZ_APP_DISPLAYNAME) "Root Accessible");
Space before Root otherwise you'll get BonEchoRoot Accessible ;-)

Comment 6

[Willie Walker]

Hey Aaron:

There is a "toolkitName" field for the Application object in the AT-SPI, and Orca takes advantage of this if it exists (Firefox doesn't seem to provide it, though).  Avoiding the nitty gitty details, the basic logic Orca follows is:

1) Look for a script based upon the application name.  
2) Look for a script based upon the toolkit name.
3) Fallback to the default script.

BTW, using the application name is somewhat of a challenge because application names are pretty much unreliable, tend to be localized in some cases, and the AT-SPI providers often like to change them to match the title of the main window.

In any case, what do you mean by "use the correct name of the app for the app root accessible"?  If it allows me to use the app name to get a script specific to the app, then that would be a good thing.

Comment 7

[Aaron Leventhal]

Okay, and let's expose the toolkit name as Mozilla. We can use this bug for that.

Comment 8

[Aaron Leventhal]

Oy, this has already been fixed for a while.



*** This bug has been marked as a duplicate of 321081 ***