Say all stops every 10th line in editors with NVDA

[Neurrone]

• VSCode Version: Code - Insiders 1.20.0-insider (2bab83a, 2018-01-10T05:13:51.946Z)
• OS Version: Windows_NT x64 10.0.15063
• NVDA Version: master-14774,0d94f5dd
• Extensions (4)

  Extension	Author (truncated)	Version
  vscode-markdownlint	Dav	0.12.1
  vscode-rust	kal	0.4.2
  rust	rus	0.3.2
  markdown-preview-enhanced	shd	0.3.2

Steps to reproduce:

1. Start NVDA. Create an empty file with the following content:

# heading 1

This is a paragraph
of some text
and some more text.

## heading level 2

* item 1
* item 2
* item 3

2. Perform a "say all" by pressing insert + down arrow (if NVDA is using a desktop keyboard layout which is the default) or caps lock + a if using laptop keyboard layout when your cursor is anywhere on lines 1-10 (the second-last line "* item 2")

Expected behaviour

This should cause NVDA to start reading downwards from the current position to the end of the document.

Actual behaviour

NVDA does start reading from the current position, but stops once it reads line 10 when you start reading from lines <= 10.

I remember reading that VS Code's worked with screen readers based on "paging the text". I'm not sure what that means, could this be a side effect?

Impact

Reading through long files always stops on every 10th line, which is most noticeable when proofreading long files e.g .md or .tex files.

[dranov]

This affects all Monaco editors, not just VSCode.

IAccessible.Value always gets set to the 10 line block that includes the focused line (e.g. if line 11 is focused, the value is lines 11-20, or if line 8 is focused, the text is lines 1-10).

Bonus: if this issue is fixed (such that IAccessible.Value includes the full document text), it would be possible to implement an NVDA app module (app-specific addon) to speak the current line number. (See #52429.)

[dranov]

I remember reading that VS Code's worked with screen readers based on "paging the text". I'm not sure what that means, could this be a side effect?

Background on this: #26730

Relevant lines in the code: textAreaHandler.ts:226 and textAreaState.ts:230

---

The Chromium performance issue which motivated introducing text paging in the first place seems to still exist. Details here (marked fixed, but I can still reproduce on latest Chromium) and here (submitted by @alexandrudima).

I removed the paging limit on a local VSCode build, but this makes the editor unresponsive even with relatively small files (~1000 lines). Until the underlying Chromium issue is fixed, I don't see any way around this.

[dranov]

I've (re-)reported the underlying issue to the Chromium bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=868830

[Neurrone]

Thanks @dranov. Based on the Chromium ticket, it should hopefully be fixed soon.

[dranov]

Update from the Chromium ticket:

1. There is a performance issue related to text metrics ('Enables support for querying line breaks and the bounding box of arbitrary character ranges'). I believe this is what @alexandrudima originally reported and what motivated the introduction of text paging to VSCode. This has not been fixed.

2. Separate from this, there was a recent regression (4 weeks ago) in <textarea> scrolling performance when accessibility support is turned on. This regression, which has only affected pre-release versions of Chromium, has been rolled back (and won't affect Chrome 69 stable, due to be released September 4th), but is completely orthogonal to the VSCode issue.

To recap: we've prevented a performance regression from making it into Chrome stable, but the issue which affected VSCode is still there.

I've reported steps to reproduce the underlying issue (which I've also reproduced on Chromium 61.0.3163.0, the version which VSCode uses internally), so hopefully it will get some attention now.

[dranov]

Good news! The text metrics performance issue is now fixed in Chromium. The relevant commit is here. It might take a few months until the fix makes it into Chromium stable and then Electron.

@alexandrudima, is there some way to run VSCode with a particular version of Chromium, so we can make sure this fixed the issue and text paging can now be removed?

[alexdima]

@dranov There is no easy way to run VSCode, as that requires that there exists an Electron version containing that Chromium version. The closest way to try this would be to run the monaco editor from sources (same source as VS Code)

https://github.com/Microsoft/monaco-editor/blob/master/CONTRIBUTING.md#running-the-editor-from-source

[dranov]

@alexandrudima, I've just tried it on a local build with text paging removed, and the Chromium fix definitely seems to improve things for Monaco as well.

On Chromium 61.0.3163.0 (currently used by VS Code), the editor becomes visibly slow on files ~1k lines long. By contrast, Chromium 70.0.3530.0 starts showing similar slowness at ~10k lines. It does handle larger files (e.g. BigHTML in the Monaco tests, 24k lines), but at that point it's annoying to use.

It's not ideal, but it might be good enough.