User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Build Identifier: rv:1.8) Gecko/20051111 Firefox/1.5 Open the page with onclicks - http//www.pctuning.pl using FireFox 1.5 final (polish language version) This version don't reports onclicks on veb pages in browse mode using WE 5.5. The english version show onclicks perfectly. Reproducible: Always Steps to Reproduce: 1. 2. 3. Open any veb pages with onclicks Actual Results: No posibility to find onclicks on veb pages Expected Results: Show onclicks as english version do.
I can't get the referenced www.pctuning.pl site to load, but I don't see how this is a security problem from the description. (Isn't there a product/component for localizations? I can't find one)
I'd like to remind this bug as we are introducing Polish version of Window-Eyes 5.5. This bug seems to affect only Polish version of FF, not English one. Forget about www.pctunning.pl and go to http://www.gwmicro.com/wetest/w3c/onclick.htm There is one onclick tag and Window-Eyes 5.5 does not see it through the browse mode with Polish version of FF (Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:184.108.40.206) Gecko/20060111 Firefox/220.127.116.11) while it is seen with English version.
WFM on Firefox 18.104.22.168 Linux
I don't see any reason why this would work for an en-US build and not for an pl build, as that is just the repackaged en-US build. Given that WE is commercial software that our localizers don't have access to, I'm shoveling this back to a11y for verification. I installed a 22.214.171.124 pl installer build on windows, AccessibleMarshal.dll is there, and the plain web-page part of the onclick handler works great, too.
Although we have no localized demo version yet, you can use English demo from GW Micro to see (or hear) it. http://www.gwmicro.com/Window-Eyes/Demo/ I see that AccessibleMarshal.dll is exactly the same... But may be in case of the onclick reporting to screenreader you feed WE with some string from other file that should not be translated but actually was?
This is a big bug for any non-English Firefox users with screen readers.
Is this actually confirmed then? Do we have any idea what it'll take to fix this? Please nominate when there's some confirmation/investigation to consider.
(In reply to comment #6) > This is a big bug for any non-English Firefox users with screen readers. > Aaron, does it mean that you confirmed that bug? If so, can I assign it to you?
WFM on the GWMicro test page given in comment 2. Polish version of Firefox 126.96.36.199, WindowEyes 5.5.
(In reply to comment #9) > WFM on the GWMicro test page given in comment 2. > > Polish version of Firefox 188.8.131.52, WindowEyes 5.5. > I don't know what 'WFM' means, but have read that WORKSFORME resolution means: "All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened." But problem still exists somewhere as I do not see the onclick on that page using Polish FF 184.108.40.206 and WE 5.5 (Polish, but according to my knowledge it is not important). From comments here and on GW Micro side I understand that you know where is the cause of such behavior, but the solution is open for discussion. However may be the solution should be on WE side... So I cannot agree with what WORKSFROME means. Here is the comment to this from Aaron Leventhal: Here's why onclick is not working in non-English versions of Firefox with Window-Eyes. Firefox is translating default action names. For example, the German for "click" is "Klicken". Is this something we should really fix on the Firefox end? Are those default action strings supposed to be localized or not? At some point we are planning to allow web authors to define a set of actions and descriptions for any element, and expose it to Window-Eyes. This would allow web applications to have the equivalent of context menus. For example, imagine a web mail app with a context menu for messages allowing you to "Delete a message" or "Mark message as Junk". I can't imagine that mechanism working unless the strings are localized and Window-Eyes just speaks them. Perhaps rather than looking to see if we have an action with the exact string "click", Window-Eyes should just look for any action and let the user activate it? Or is this something we really need to fix in Firefox? And the answer from Bill Smith from GW Micro: I just looked at the documentation for get_accDefaultAction. It specifically says that the string should be localized so Firefox is doing the right thing. But it also says that, for example, a button on a toolbar should return "Press" and not "Print the current document". This seems to mean that the customized widgets and whatsits need to have a different way of getting the detailed description text to the user than putting it in the default action string. I can imagine that the list of "generic" actions in this property isn't fixed, but it shouldn't contain a different string for each control in the app. I think we need to come up with a way for Window-Eyes to recognize the strings from different localized versions of Firefox. It would be best if the language that Window-Eyes had been localized could be different from the language of Firefox and still have things work correctly. How this should best be done is open for discussion...
The default action for any widget is generally to click it. So if Bill ignored the default action name I think that would be fine.
Can anybody reproduce the bug with a latest build of Firefox 2, 3, or trunk?
WFM with FF2.0.4 Polish and WE 6.1. My understanding is that this is something GW Micro will or has already fixed and nothing more need be done on our end.
Yes, it is fixed by GW Micro and you not only need not do anything here but I would say you should not do [smile]. Now WE is looking for any of the strings: "click", "Klicken", "Kliknij", etc. including strings for all languages WE is localized to. So if you change this string in particular translation of FF it certainly stops working for this language.