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:
14 years ago
Attachment #197198 - Flags: review?(aaronleventhal)
Attachment #197198 - Flags: review?(aaronleventhal) → review?(Louie.Zhao)
Comment on attachment 197198 [details] [diff] [review] Proposed patch This patch is simple and straightforward.
Attachment #197198 - Flags: review?(Louie.Zhao) → review+
Attachment #197198 - Flags: approval-branch-1.8.1+
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?
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 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 ;-)
Attachment #197198 - Flags: superreview?(neil) → superreview+
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.
Okay, and let's expose the toolkit name as Mozilla. We can use this bug for that.
Summary: Firefox reports itself as "mozilla" to the a11y framework → Firefox reports itself as "mozilla" to the a11y framework -- "Mozilla" should be the toolkit name
Oy, this has already been fixed for a while. *** This bug has been marked as a duplicate of 321081 ***
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.