Nvda: NVDA announces document replacement character for Firefox documents

[leonardder]

Steps to reproduce:

1. Open Firefox
2. Disable browse mode
3. Focus the address bar with alt+d
4. Open: data:text/html, <p>something</p>
5. Focus the document by tabbing into it.

Actual behavior:

NVDA says: Document object replacement character.

Expected behavior:

No announcement of object replacement character as it is irrelevant.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

alpha-20220,1c4519a6

Windows version:

Windows 10 2004

Name and version of other software in use when reproducing the issue:

Firefox 76.0.1

Additional details

1. The object replacement character is stripped from virtual buffers
2. Introduced by https://github.com/nvaccess/nvda/pull/11110

[ruifontes]

It also occurs in Thunderbird, installed or portable, version 68.8.0 (32-bit) 68.8.0

[DrSooom]

See also: Issue #10634 – especially my comment here.

[DrSooom]

Imho this isn't a regression caused by PR #11110. A quick and dirty fix for the speech output only would be to set the symbol level for U+FEFF, U+FFF9, U+FFFA, U+FFFB, U+FFFC and U+FFFD from "none" or "some" to "all".

@leonardder and @ruifontes: Can you confirm that the braille output hasn't changed between NVDA 2020.1 and Alpha-20220 in these situations? I couldn't figure out any differences between NVDA 2019.2.1 (installed) and Alpha-20220 (portable) with Firefox 76.0.1 (64-bit, installed) on Win7x64 after pressing Enter on the password field at https://web.threema.ch/ (Threema for iOS or Android is required).

Or just open the following in Firefox and toggle to the Focus Mode:
data:text/html,<button>&#xFFFC;</button>

[Neurrone]

@feerrenrut any chance this could be fixed before 2020.2?

[feerrenrut]

@Neurrone Given how close the release is and given this issue is still being investigated it seems unlikely.
@sthibaul Could you please investigate this further?

[Neurrone]

Could the PR that introduced it be reverted? This is fairly annoying and is something that users are going to notice if it lands in 2020.2.

[lukaszgo1]

While the quick and dirty fix would be to change symbol level of the object replacement character perhaps in the long term we should consider removing it completely from the text of the control similar to what's been done for RTL and LTR characters in #8643

[sthibaul]

Perhaps just remove the rule for now to just avoid the issue for now, as done in PR https://github.com/nvaccess/nvda/pull/11267 , and take the time to see how to fix it after the release.

[feerrenrut]

I can't reproduce the issue as described. This makes it very difficult to be sure of any fix.

[Adriani90]

@feerrenrut this might have been fixed by your last improvements in PR #11245. I cannot reproduce anymore with NVDA alpha-20339,975d39d1 and Firefox 77.
@leonardder can you confirm?
If yes, I think #11267 is obsolete.

[leonardder]

I can still reproduce it, but only when browse mode is off. I'll update the description accordingly.

[Adriani90]

Ok, yes with focus mode it is still reproducible.
It is also reproducible in Thunderbird, when switching windows with alt+tab and the focused windo is the thunderbird window, then you you hear "object replacement character" multiple times.

[paulber19]

Hi,
You can also reproduce it by:

• focus the mail list,
• press "tab" to go to sender field
• and press "uparrow".

Best regards.

Le 17/06/2020 21:56, Adriani90 a écrit :
>

Ok, yes with focus mode it is still reproducible.
It is also reproducible in Thunderbird, when switching windows with
alt+tab and the focused windo is the thunderbird window, then you you
hear "object replacement character" multiple times.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nvaccess/nvda/issues/11177#issuecomment-645590431, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADZLFFGSRT5UOU47VSNAVBDRXENXJANCNFSM4NE6OQDQ.

[DrSooom]

Could all of you please read my previous comment about this again? Thanks.

[leonardder]

Entries in de symbols dictionary have nothing to do with braille.

A quick and dirty fix for the speech output only would be to set the symbol level for U+FEFF, U+FFF9, U+FFFA, U+FFFB, U+FFFC and U+FFFD from "none" or "some" to "all".

I think this makes more sense than removing the rules altogether.

[lukaszgo1]

Perhaps they should be set to character similar to what's been done for RTL and LTR marks.

[DrSooom]

Entries in de symbols dictionary have nothing to do with braille.

@leonardder: I know. I just wanted to say that these Unicode characters are also visible in braille (depending on the used braille table). I had the feeling that somebody here was too focused on the speech output side – and maybe forgot that these Unicode characters are part of the virtual buffer. In other words: Adding these Unicode characters to the "symbols.dic" isn't the problem – only their default symbol level is one.

And keep issue #10164 and #10634 in mind for later.

@lukaszgo1: No, please see my comment in issue #10634. Based on a quick test in Firefox, U+200E and U+200F already aren't part of the virtual buffer (Browse and Focus Mode).

[amirsol81]

This also affects Google Chrome in various controls/menus -- see #11285 which is now closed as a duplicate though I think it's more serious in Google Chrome as even the History list/Bookmark list is affected with NVDA+Up arrow.

[gregjozk]

Yes. try in a Chrome to play some videos/songs in youtube. but, as
some of us said, there would be a dirty fix with rool set to none.

regards,
Jožef

2020-06-21 21:42 GMT+02.00, amirsol81 [e-mail]:

This also affects Google Chrome in various controls/menus -- see #11285
which is now closed as a duplicate though I think it's more serious in
Google Chrome as even the History list/Bookmark list is affected with
NVDA+Up arrow.

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/nvaccess/nvda/issues/11177#issuecomment-647172432

[amirsol81]

Hi. I just installed Alpha 20381 which is supposed to remove this issue and the relevant Chrome bug via its "Remove rule for U+FFFC" fix. However, now the issue is that in Google Chrome 83, NVDA+Up says nothing and remains silent when pressed on controls and areas where it should read or spell the current line. Before this alpha, we would here "Object replacement character" instead of the actual line. But what we now get is total silence. For instance, in Chrome press ALT+F followed by B to move to your bookmarks and as you press Up/Down, try reading each bookmark by pressing NVDA+Up arrow.

[DrSooom]

@amirsol81: That's the expected result regarding this change. What's the braille output here? I know that this doesn't help non-braille users, but it would be interesting. (Currently I can't test this myself.)

[amirsol81]

@DrSooom What I'm describing is one of the most screen reader-unfriendly issues I've noticed: Insert+Up (NVDA+Up) must always read the current line or control, or spell it if pressed twice. Now if you press ALT+F in Chrome and press Up twice to reach Help submenu, pressing Insert+Up doesn't read it. If you press ALT+F and press Up a few times to reach items such as Copy and Paste, Insert+Up doesn't read them. The same is true about Make text larger, Make text smaller, More tools submenu, History submenu, Bookmarks submenu, all bookmarks inside the Bookmarks submenu, and most controls in the Edit bookmark dialog when Control+D is pressed. Most strikingly, however, NVDA fails to read all items in the History page, Control+H, the Remove bookmark control, and the Action menu there via Insert+Up. These need an urgent fix IMO.

[DrSooom]

@amirsol81: You're right, but this would be another issue and it has not directly something to do if U+FFFC is spoken or not. I have already noted down to open an issue for filtering certain Unicode characters from the virtual buffer. (I'll create a new issue regarding this in the upcoming days.) Unsure if this would help in the Chrome specific bug. So in the meantime I ask you to open a new issue regarding the Chrome bug you encountered. Thanks.

[amirsol81]

@DrSooom I opened #11285 few days ago to address those Chrome-oriented bugs, but someone closed it as it was deemed a duplicate of this one which apparently isn't.

[Adriani90]

@amirsol81 it is a duplicate of this. What do you expect to hear when you land on object replacement character? Previously you said it is an issue that it is reported, now you say it is an issue that it is not reported. The object replacement character does not give an user any useful feedback at all.

To come back to this issue, the removal of the role has now been merged because many users requested this character not to be reported at all. Now in my opinion at least such characters which are not useful for users at all, should be skipped from the object navigation when reviewing an object. Then users would not come across such characters at all. The characters could be included only when
simple review mode is disabled in NVDA's review cursor settings.

[amirsol81]

@Adriani90 Guess for the umpteenth time, I expect to have these controls and items announced or spelled when I press Insert+Up, once or twice, on them, regardless of whether or not they contain such a character. These are normal controls which are properly read/announced/spelled by other screen readers, so NVDA's behavior, whether it is the announcement of Object Replacement Character or it is total silence, is neither acceptable nor standard practice. So, I don't care which character they contain, I want to have them announced like any standard control with Insert+Up (NVDA+Up).

[Adriani90]

@amirsol81 thanks for the clarification.
Even though other screen readers announce it, these characters are useless in my opinion and you cannot interact with them anyway. So I would vote for excluding them from object navigation as pointed above.
Do you have certain use cases where you need to hear such characters like document replacement character?

[amirsol81]

@Adriani90 I don't hear Document Replacement Character or Object Replacement Character with other screen readers. Rather, I hear the name of the control or item on which I press Insert+Up. For instance, if I'm on Bookmarks submenu or a bookmark, pressing Insert+Up reads it to me and announces it the way it is read upon landing on it via Up/Down. Please kindly test these with JAWS 2020 June Edition and Chrome to get what I mean. With NVDA, you simply hear nothing when you press Insert+Up on, say, a bookmark or a history item.

[Adriani90]

Ok thanks. This indicates that other screen readers just skip them, which imo is expected behavior here.

Von meinem iPhone gesendet

Am 23.06.2020 um 22:07 schrieb amirsol81 [e-mail]:


@Adriani90 I don't hear Document Replacement Character or Object Replacement Character with other screen readers. Rather, I hear the name of the control or item on which I press Insert+Up. For instance, if I'm on Bookmarks submenu or a bookmark, pressing Insert+Up reads it to me and announces it the way it is read upon landing on it via Up/Down. Please kindly test these with JAWS 2020 June Edition and Chrome to get what I mean. With NVDA, you simply hear nothing when you press Insert+Up on, say, a bookmark or a history item.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[amirsol81]

Yes, they ignore the so-called useless and nonsensical character and
announce the rest of the control. NVDA ignores everything as it stands.

On 6/24/2020 12:40 AM, Adriani90 wrote:

Ok thanks. This indicates that other screen readers just skip them,
which imo is expected behavior here.

Von meinem iPhone gesendet

Am 23.06.2020 um 22:07 schrieb amirsol81 [e-mail]:


@Adriani90 I don't hear Document Replacement Character or Object
Replacement Character with other screen readers. Rather, I hear the
name of the control or item on which I press Insert+Up. For instance,
if I'm on Bookmarks submenu or a bookmark, pressing Insert+Up reads it
to me and announces it the way it is read upon landing on it via
Up/Down. Please kindly test these with JAWS 2020 June Edition and
Chrome to get what I mean. With NVDA, you simply hear nothing when you
press Insert+Up on, say, a bookmark or a history item.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nvaccess/nvda/issues/11177#issuecomment-648391524,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIGLZMV35KFL3FUHKFYNN4TRYED3HANCNFSM4NE6OQDQ.

[XLTechie]

@Adriani90 wrote:

Ok thanks. This indicates that other screen readers just skip them, which imo is expected behavior here.

@Adriani90, you are focusing too much on the document and object replacement
characters, and ignoring the rest of the problem.

What he is trying to tell you, is that other screen readers do skip those, but
they also do read the actual name of the element.

NVDA, on the other hand, now skips the object and document replacement
characters, but it also skips reading of the name of the buttons or controls.

That is very much not the expected behavior.

The expected behavior is for NVDA to skip the replacement characters, but
instead of saying nothing, it should announce the name of the controls. It
doesn't.
That is what @amirsol81 has been repeatedly saying.

[Adriani90]

Since this has been solved for now in #11267, I am going to close this issue.

[gregjozk]

Hello,

@adriani90 please, please again, do not close issues so agresively.
Comments from others clearly indicate, that problem has not been
solved yet. again, please carefully read comments and take some tests
if you can.

kind regards,
Jožef

2020-06-24 0:20 GMT+02.00, Adriani90 [e-mail]:

Closed #11177.

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/nvaccess/nvda/issues/11177#event-3475029023

[DrSooom]

@gregjozk: Please read my comment above as well as my comment in issue #10634. As U+FFFC isn't the only code point which should be filtered out from the Virtual Buffer by default – but still with the option to disable this filter via the Advanced NVDA Settings –, I'm going to submit a new issue in the upcoming days regarding this. I have to think carefully before I'm doing this, as there are multiple solutions we should talk about. And I want to provide a useful basic here. In favor of the upcoming issue, I already was planning on asking to close this issue. Furthermore the discussion in this issue here became … Sadly not the first time (see also issue #11157). A new one is easier to follow for developers.

[Update 2020-07-02 19:58 (UTC+2)] "upcoming weeks", sadly no longer "upcoming days", as I currently have to do some other, more important stuff. Thanks for your understanding. [/Update]

@DrSooom I opened #11285 few days ago to address those Chrome-oriented bugs, but someone closed it as it was deemed a duplicate of this one which apparently isn't.

@amirsol81: I have to apologize. A few hours after I had posted my comment I remembered that you already opened an issue for this. Sorry for the inconveniences.