It looks like jsbin is interjecting extra script tags and breaking the example. Please use this instead: http://www.steve-audio.net/BadChromeVoiceover.html

[mac triage] I'm having some trouble replicating this. Can you attach a screencast?
CC'ing ellyjones to see if she has any ideas

Attached is a screencast of me visiting http://www.steve-audio.net/BadChromeVoiceover.html in Chrome 53.0.2785.80 beta (64-bit) on OS X 10.11.6 (15G31) in incognito mode.

In the first segment of the video, I load the page with VoiceOver off, and the timer fires in 11 ms. In the second segment of the video, I activate VoiceOver and reload the page, and the timer fires in 1272ms.

The timer is essentially measuring how long it takes to render the frames following changing focus between the text areas.

Deleted: slow-chrome-voiceover.mov 6.7 MB

slow-chrome-voiceover.mov 6.7 MB Download

I also can't reproduce this.
I navigated to both URLs provided and tried moving around using tab and shift-tab, and ctrl-opt-left/right. No slowness was observed.
On the second page, I got a popup alert with some time measurement. Is that useful in some way? I thought the problem is navigating around the page after it loads.
I am running Canary on El Kapitan.

Yes, see comment 4. We have some cases where a much larger set of these 
types of elements can exist on our web application. Dozens, if not 
hundreds, of them can cause VO and Chrome to hang for upwards of 10 
seconds for each focus. During this time the computer is completely 
unresponsive. What is worse is that each focus appears to enter an event 
queue, so if you attempt moving quickly the end result is that the 
machine can become completely unresponsive for minutes at a stretch. 
Unfortunately this latter scenario isn't something we can easily 
demonstrate outside our company, hence the paired down example. If you 
modify the for loop in the code to run, say, 2000000 times instead of 
200, you should definitely see this problem worsen.

Okay, we do know that there is a potentially sizable performance hit when accessibility is on. This is due to the extra code that needs to run in order to build and maintain an accessibility tree.
chrome://profiler might help in figuring out where such performance bottlenecks are found.
Might be related to https://bugs.chromium.org/p/chromium/issues/detail?id=581647

We have observed that this problem is quadratic in nature. The original example page has been updated to demonstrate, and we have a graph of times here: https://www.desmos.com/calculator/zskaadg4wm

Thank you very much for creating this excellent benchmark demonstrating the problem. It made things much easier for us.

I took some time profiling it today and the good news is that a single function is responsible for all of the quadratic growth: blink::AXLayoutObject::lineBreaks - if I eliminate that function, the times immediately drop and growth is no longer quadratic.

Nektarios, I think you're already well along the way to rewriting the editable text handling code based on inline text boxes and not line breaks. Do you think you could prioritize eliminating AX_ATTR_LINE_BREAKS, even before finishing the cleaner rewrite using AXPosition?

One idea would be to write a browser-side function that computes the line breaks from inline text boxes. We could use it as a drop-in replacement for the various places we're accessing GetIntListAttribute(ui::AX_ATTR_LINE_BREAKS) now, as an incremental solution to improve performance.

Alternatively, I could write the incremental solution and you could focus on the cleaner fix.

Either way, let's see if we can get the incremental solution released soon, ideally M-54.

@c10, the original bug states that Chrome 50 worked fine. I don't recall the history of line breaks, but it's certainly been with us for some time.
Do we know why line breaks regressed in performance?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91926613c70561f2ddeb86896496e7306518c747

commit 91926613c70561f2ddeb86896496e7306518c747
Author: nektar <nektar@chromium.org>
Date: Sat Sep 24 01:24:59 2016

Get rid of AX_LINE_BREAKS attribute to improve performance and clarity.

1. Attribute renamed to line_start_offsets.
2. Now computed on browser side and cached.
3. Attribute should not be used directly but line start offsets should be retrieved via |AXNode::GetOrComputeLineStartOffsets|.
4. Should work on all kinds of text fields and both in automation and other platforms.
TESTED=Manually with Voiceover ChromeVox Jaws and NVDA, existing Windows browser tests, new Automation API tests, existing ChromeVox tests
R=dmazzoni@chromium.org, dtseng@chromium.org
BUG= 642337 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2301833005
Cr-Commit-Position: refs/heads/master@{#420807}

[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/browser/accessibility/accessibility_extension_api.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/browser/extensions/api/automation/automation_apitest.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/browser/resources/chromeos/chromevox/common/chrome_extension_externs.js
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/renderer/extensions/automation_internal_custom_bindings.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/renderer/resources/extensions/automation/automation_node.js
[add] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/test/data/extensions/api_test/automation/sites/line_start_offsets.html
[add] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/test/data/extensions/api_test/automation/tests/tabs/line_start_offsets.html
[add] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/chrome/test/data/extensions/api_test/automation/tests/tabs/line_start_offsets.js
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/content/browser/accessibility/browser_accessibility.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/content/browser/accessibility/browser_accessibility.h
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/content/browser/accessibility/browser_accessibility_cocoa.mm
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/content/browser/accessibility/browser_accessibility_win.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/content/browser/accessibility/browser_accessibility_win_unittest.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/content/renderer/accessibility/blink_ax_tree_source.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/ui/accessibility/ax_enums.idl
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/ui/accessibility/ax_node.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/ui/accessibility/ax_node.h
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/ui/accessibility/ax_node_data.cc
[modify] https://crrev.com/91926613c70561f2ddeb86896496e7306518c747/ui/accessibility/ax_tree_combiner.cc

This must be fixed.