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

Unicode character U+200E in the text of the clock #5729

Closed
dkager opened this Issue Feb 3, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@dkager
Collaborator

dkager commented Feb 3, 2016

On my Windows 7 system with en-US locale there are Unicode LTR marks in the text of the clock. I made some adjustments to the date and time format, but my guess is that this occurs for the clock in general. Probably also for RTL languages.

Steps to reproduce:

  • Press Windows+b to go to the notification area.
  • Press left arrow until you reach the clock.
    • Expected: see the date and time in braille.
    • Actual: see the date and time plus Unicode character U+200E (LEFT-TO-RIGHT MARK) prefixed to the date fields.

This character shows up because it is not in the liblouis table en-us-comp8.ctb. It's not likely to be in any other tables either.
Here is the text as copied from NVDA's review mode. Note that these characters are invisible:
Clock 19:21, ‎Sunday, ‎31-‎01-‎2016

I haven't encountered these characters anywhere else in Windows' GUI but apparently a similar situation exists in the file properties dialog, albeit with a different character:
https://blogs.msdn.microsoft.com/oldnewthing/20150506-00/?p=44924

Can anyone reproduce this? Is it something that could be addressed in NVDA, at least for the clock, e.g. by means of a simple filter? Or is this more of a liblouis thing?

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Feb 3, 2016

Contributor
Contributor

jcsteh commented Feb 3, 2016

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 4, 2016

Collaborator

Sounds good. Fixing this in liblouis would require either updates in all tables, which is unrealistic, or to pre-compile some rules, which IMO is ugly.

By the way, I experience #4364 too on Windows 7. But from what I read this is different in later versions. I'm not sure if this Unicode thing is specific to Windows 7, but I guess filtering it out on all versions doesn't hurt.

Collaborator

dkager commented Feb 4, 2016

Sounds good. Fixing this in liblouis would require either updates in all tables, which is unrealistic, or to pre-compile some rules, which IMO is ugly.

By the way, I experience #4364 too on Windows 7. But from what I read this is different in later versions. I'm not sure if this Unicode thing is specific to Windows 7, but I guess filtering it out on all versions doesn't hurt.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 10, 2016

Collaborator

Also confirmed on Windows 10. I still need to look at fixing it, though.

Collaborator

dkager commented Feb 10, 2016

Also confirmed on Windows 10. I still need to look at fixing it, though.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 11, 2016

Collaborator

So the fix is pretty easy: replace the value by the value with U+2003E stripped. But then upon value changes (i.e. when the clock changes) nothing is announced. Am I right in assuming I should add an overlay class?

Also, the name on Windows 7 is just "Clock", which is redundant since NVDA already announces that. On Windows 10 the name equals the value, which again causes repeated announcements. I'm not sure about XP/Vista/8.1, but maybe the name could be cleared for all of these.

Collaborator

dkager commented Feb 11, 2016

So the fix is pretty easy: replace the value by the value with U+2003E stripped. But then upon value changes (i.e. when the clock changes) nothing is announced. Am I right in assuming I should add an overlay class?

Also, the name on Windows 7 is just "Clock", which is redundant since NVDA already announces that. On Windows 10 the name equals the value, which again causes repeated announcements. I'm not sure about XP/Vista/8.1, but maybe the name could be cleared for all of these.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Feb 11, 2016

Contributor
Contributor

jcsteh commented Feb 11, 2016

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 12, 2016

Collaborator

Fixed it on Windows 7, now I just need to verify it on Windows 10 and maybe XP. PR to follow after that.

Also as a general note, the text that is actually shown on-screen appears to be in windowText. This isn't very useful because it doesn't include the date.

Collaborator

dkager commented Feb 12, 2016

Fixed it on Windows 7, now I just need to verify it on Windows 10 and maybe XP. PR to follow after that.

Also as a general note, the text that is actually shown on-screen appears to be in windowText. This isn't very useful because it doesn't include the date.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Feb 13, 2016

Collaborator

Ah, Windows XP is not affected by these tweaks because its accRole is ROLE_SYSTEM_CLIENT, whereas on Windows 7 it is ROLE_SYSTEM_CLOCK. The window classname is the same but on XP NVDA manually assigns ROLE_CLOCK. This is done in NVDAObjects.IAccessible.TrayClockWClass, which I could extend, but since we need different behavior on Windows 7 and up I would rather use the Explorer app module as previously suggested.

The difference in behavior is that on XP the object has no value and its name contains the time. So discarding the name would be a bad idea. Again, windowText is consistent across all platforms but does not contain the date, which I guess we want to show if possible even if it's not immediately shown visually.

Collaborator

dkager commented Feb 13, 2016

Ah, Windows XP is not affected by these tweaks because its accRole is ROLE_SYSTEM_CLIENT, whereas on Windows 7 it is ROLE_SYSTEM_CLOCK. The window classname is the same but on XP NVDA manually assigns ROLE_CLOCK. This is done in NVDAObjects.IAccessible.TrayClockWClass, which I could extend, but since we need different behavior on Windows 7 and up I would rather use the Explorer app module as previously suggested.

The difference in behavior is that on XP the object has no value and its name contains the time. So discarding the name would be a bad idea. Again, windowText is consistent across all platforms but does not contain the date, which I guess we want to show if possible even if it's not immediately shown visually.

dkager added a commit to dkager/nvda that referenced this issue Feb 13, 2016

Taskbar clock: filter out Unicode character U+200E (LTR mark) that is…
… included in the value on recent versions of Windows. This character is usually not defined in the liblouis braille tables. re nvaccess#5729

dkager added a commit to dkager/nvda that referenced this issue Apr 25, 2017

Revert "Taskbar clock: filter out Unicode character U+200E (LTR mark)…
… that is included in the value on recent versions of Windows. This character is usually not defined in the liblouis braille tables. re nvaccess#5729"

This reverts commit 6a16a24.

@nvaccessAuto nvaccessAuto added this to the 2018.2 milestone May 6, 2018

@feerrenrut feerrenrut closed this in f5bc848 May 6, 2018

feerrenrut added a commit that referenced this issue May 6, 2018

Update changes file for PR #5751
NVDA no longer reports (LTR and RTL marks) in Braille or per-character speech when accessing the clock in recent versions of Windows.
Issue #5729
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment