User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0pre The example url has a context menu with 11 items. The first 8 are standard menuitems, the last three are checkable menuitems. The Accessible description for the first 8 are "x of 8" where x is the position of the menuitem in the list of items. There is no description for the 3 checkable menuitems. Since they are included within the same menu, they should also be counted. Note that you can also substitute "nightly" in the above url in place of "dojo-2008-06-25" to get the most up to date test file if you are brave. Reproducible: Always Steps to Reproduce: 1.Open inspect32 or other tool to view MSAA information - set it up to track keyboard focus 2.Open the above url 3. put focus in the first text box on the page 4. press shift-F10 to bring up the context menu. 5. arrow down to the menu item "cut", notice that the description in IA2 is listed as "4 of 8" 6. arrow down to the menu item labeled "checked", notice that there is no description. I think it should be "9 of 11" Expected Results: description for "checked" menu item should be "9 of 11"
Confirmed. Becky, is there a separator below the 8th menu item (where it stops counting) and above the checkable items? I've done a test on the regular Firefox View menu, and noticed that I'm getting a higher count (13 items in my case) than are actually visible, and I am wondering whether we are counting separators in this case, but on the sample page, are thinking that at the separator, the menu ends.
For any changes we make to ARIA processing, please update this doc: http://developer.mozilla.org/en/docs/ARIA_User_Agent_Implementors_Guide
Created attachment 326879 [details] [diff] [review] patch
Created attachment 326885 [details] [diff] [review] patch2
Is this patch meant to stop counting on a snormal separator, for example as seen in Firefox's "View" menu? Because with this patch applied, it still has 13 items (10 items plus 3 separators), and the description still says "1 of 13, 2 of 13, 3 of 13, 5 of 13".
In answer to the question of the separators. The are three separators in the menu. There are two which are not counted (based on the code when I submitted the bug) within the first 8 items. In other words, there are eight actual menu items and 2 separators. Then there is a separator created in the same manner as the others, then the 3 checkable menu items. I don't think that separators should be counted since they are never navigated to.
Technically in the example those separators aren't separators in a11y terms (they haven't role separator and they are exposed as role nothing). I really haven't idea why they are counted (because we count only accessibles with the same role). So the question is for Becky: what the difference is between our example in mochitest (see the patch2) and your example? Marco, why the bug is fixed?
(In reply to comment #7) > Technically in the example those separators aren't separators in a11y terms > (they haven't role separator and they are exposed as role nothing). I really > haven't idea why they are counted (because we count only accessibles with the > same role). So the question is for Becky: what the difference is between our > example in mochitest (see the patch2) and your example? Alex, the ARIA menu that Becky linked to now works correctly with your patch, it counts 11 items. However, in our own View menu, we also count the separators. Look at the "View" menu in DOM inspector. The patch hasn't changed that, although I thought it would. Or did you not intend to also change regular menus that have separator accessibles? > Marco, why the bug is fixed? With your patch, the ARIA bug is indeed fixed. I am just wondering whether this patch also should address regular menus or not.
No, it shouldn't address the original xul:menu, please file another bug for this. Marco, did you land the patch if you marked it as fixed? You didn't set r+ in any way and fixed looks strange :)
Oops, thanks for the pointer! I must have accidentally hit that radio button somehow.
Comment on attachment 326885 [details] [diff] [review] patch2 r=me
Pushed to mozilla-central in changeset: http://hg.mozilla.org/mozilla-central/index.cgi/rev/e4d8bb043ef7
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008062804 Minefield/3.1a1pre.