IE6 sometimes returns trash in accName

[nvaccessAuto]

Reported by aleksey_s on 2009-11-02 09:09
My friend reported to me that NVDA reads the random characters after a link name in ie6 addons settings dialog. Further debugging shown that accName of those link objects contain a trash text after the null characters at end of the string.
for example:

nav.IAccessibleObject.accName(0)

u'\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435 \u043e \u043d\u0430\u0434\u0441\u0442\u0440\u043e\u0439\u043a\u0430\u0445 ...\x00\x00\x00\u0432\u0430\x00\u0435\x00'

from msdn:
A BSTR is a composite data type that
consists of a length prefix, a data string, and a terminator.

I suspect that msaa returns incorrect string length. Seems as we need to filter out somehow the strings received from msaa.

[nvaccessAuto]

Attachment patch451.txt added by aleksey_s on 2009-11-03 07:50
Description:
A new patch

[nvaccessAuto]

Comment 1 by aleksey_s on 2009-11-02 09:53
Finally, i think that implementing a workaround for this particular control will be more appropriate.

[nvaccessAuto]

Comment 2 by aleksey_s on 2009-11-02 10:40
See atachment

[nvaccessAuto]

Comment 3 by pvagner on 2009-11-02 11:59
Not only this fixes links for internet explorer. This also fixes spurious characters appended to the links accross various system dialogs. E.G. links on the Sharing tab of the folder properties dialog in the Windows Explorer or Main computer window.
I am suggesting to put this in for 2009.1 as it's already fixed.
@mick can you please test it on Vista if the problem with focus reporting stays unaffected? As this is why that class has been added into the NVDAObjects.IAccessible module.

[nvaccessAuto]

Comment 4 by mdcurran on 2009-11-02 22:43
Why the change to reportFocus?
I gather this name problem only occures in some non-english versions of Windows? I don't see any links in Explorer with this problem.
However, the code looks fine to me (for _get_name).

[nvaccessAuto]

Comment 5 by pvagner (in reply to comment 4) on 2009-11-03 06:22
Replying to mdcurran:

Why the change to reportFocus?

I guess because the fix you've added in r914 should only disable focus reporting for SysLink controls with role set to ROLE_SYSTEM_CLIENT. Now Aleksey has added other stuff into that class which also affects ordinary links. It's why I've asked you to test under Windows Vista.

I gather this name problem only occures in some non-english versions of Windows? I don't see any links in Explorer with this problem.

I've no access to pure english version of Windows I am running Windows XP SP3 with slovak multilingual user interface pack.

However, the code looks fine to me (for _get_name).

So Aleksey is free to commit. Thanks

[nvaccessAuto]

Comment 6 by jteh on 2009-11-03 07:28
Mick, the change to reportFocus() is because the !SysLink class is now being applied to !SysLink windows with role link as well as role client. Previously, your reportFocus() override only applied to !SysLink windows with role client.

Personally, I think I'd prefer we split this logic into two classes, one for role client (with Mick's reportFocus() override) and one for role link. Justification: these are very different objects. The client generally doesn't have a name and so probably doesn't need the name property override, and similarly, role link shouldn't have the reportFocus() overide. Also, this saves a call to IAccessibleRole on every call to !SysLink.reportFocus(), since the decision will have been made when the object was instantiated.

[nvaccessAuto]

Comment 7 by aleksey_s on 2009-11-03 07:53
Thanks Jamie, i've updated the patch appropriately.

[nvaccessAuto]

Comment 8 by jteh on 2009-11-03 08:01
Looks fine. Just a tiny nit:

name=super(SysLink,self)._get_name() 

You can actually call super with a property; e.g. super(SysLink, self).name.

[nvaccessAuto]

Comment 9 by aleksey_s on 2009-11-03 08:51
Fixed in R3349.
Changes:
State: closed

[nvaccessAuto]

Comment 10 by jteh on 2009-11-03 22:00
Thanks for your work.

For future reference, please note user visible changes like this that occurred since the last official release in the what's new document. The change should be explained in terms relevant to a user. Don't worry too much about linguistic errors; do your best and we will correct them if necessary. I've added an entry for this ticket in r3350.