Say all stops every 10th line in editors with NVDA

• VSCode Version: Code - Insiders 1.20.0-insider (2bab83a097135cf8c2a1ca1498bb8906f06d2cb3, 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

1. 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]

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.

[isidorn]

We will probably ship electron 6 in October, thus I will look into this in November once I am back from vacation. As @alexandrudima suggested If this still does not work, we can make this length of the content configurable so that users can easily change this. The downside would be the performance.