Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IE6 sometimes returns trash in accName #451

Closed
nvaccessAuto opened this issue Jan 1, 2010 · 11 comments
Closed

IE6 sometimes returns trash in accName #451

nvaccessAuto opened this issue Jan 1, 2010 · 11 comments

Comments

@nvaccessAuto
Copy link

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
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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
Copy link
Author

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

@nvaccessAuto
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant