Ticket #451 (closed defect: fixed)
IE6 sometimes returns trash in accName
| Reported by: | aleksey_s | Owned by: | aleksey_s |
|---|---|---|---|
| Priority: | minor | Milestone: | 2009.1 |
| Component: | Core | Version: | development |
| Keywords: | needsCodeReview | Cc: | sergei.starovoi@gmail.com |
| Operating system: | Windows XP | Blocked by: | |
| Blocking: |
Description
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.
Attachments
Change History
comment:1 Changed 2 years ago by aleksey_s
- Status changed from new to accepted
- Owner set to aleksey_s
comment:2 Changed 2 years ago by aleksey_s
- Keywords needsCodeReview added; ie6 removed
See atachment
comment:3 Changed 2 years ago by pvagner
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.
comment:4 follow-up: ↓ 5 Changed 2 years ago by mdcurran
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).
comment:5 in reply to: ↑ 4 Changed 2 years ago by pvagner
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
comment:6 Changed 2 years ago by jteh
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.
comment:8 Changed 2 years ago by jteh
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.
comment:9 Changed 2 years ago by aleksey_s
- Status changed from accepted to closed
- Resolution set to fixed
Fixed in R3349.
comment:10 Changed 2 years ago by jteh
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.



Finally, i think that implementing a workaround for this particular control will be more appropriate.