Open Leon-Lj opened 1 year ago
Confirmed.
I reproduced this with my NvDA log level set to input / output.
After speaking the main landmark, it then tried to speak two 0xfffd characters. which I believe are Unicode placeholder characters.
I think this may be a bug in NVDA where we have deliberately converted unknown / private use unicode characters into safe characters before explorting them via attributes in our internal xml representation of the content as it gets sent from the browser process to NVDA.
this is most likely then NVDA being too broad with its checks. There should certainly be a valid way of storing imoji unicode characters in an xml attribute string.
For anyone looking to fix this:
Please refer to appendCharToXML
in nvdaHelper/common/xml.h
NVDA does not read emojis that are in
aria-lable
, it just skips them and reads the rest of the label. Ifaria-labelledby
is used to link it to a section that contains a emoji, then it'll read it just fine.Steps to reproduce:
Actual behavior:
+2=6^{2}
It does not read the emoji (in the speech viewer it comes up as??+2=6^{2}
but that did not transfer when copied).Expected behavior:
🌻+2=6^{2}
It should read the emoji when in aaria-lable
. If you mouse over the emoji it reads it just fine (producing🌻+2=6
in the speech viewer), I assume that's because it then reads the content of the div rather than the label.System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
2022.3.1
Windows version:
10.0.18363 Build 18364
Name and version of other software in use when reproducing the issue:
Chrome 106.0.5249.119
Other questions
Does the issue still occur after restarting your computer?
Yes
If NVDA add-ons are disabled, is your problem still occurring?
No add-ons enabled.