Don't consider large static text nodes as objects

chrome/browser/resources/chromeos/chromevox/cvox2/background/constants.js

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 /**
  * @fileoverview Constants used throughout ChromeVox.
  */
 
 goog.provide('constants');
 
 /**
  * Possible directions to perform tree traversals.
  * @enum {string}
  */
 constants.Dir = {
   /** Search from left to right. */
   FORWARD: 'forward',
 
   /** Search from right to left. */
   BACKWARD: 'backward'
 };
+
+/**
+ * If a node contains more characters than this, it should not be treated
+ * as a leaf node.
+ *
+ * This number was determined by looking at the average number of
+ * characters in a paragraph:
+ * http://www.fullondesign.co.uk/design/usability/

[dmazzoni, 2016/12/07 06:40:51]

This link doesn't work for me. I tried appending the line below this one, it
just redirects no matter what I do.

[David Tseng, 2016/12/07 17:11:30]

Removed.

+ * 285-how-many-characters-per-a-page-is-normal.htm
+ * and then trying it out on a few popular websites (CNN, BBC,
+ * Google Search, etc.) and making sure it made sense.
+ * @type {number}
+ * @const
+ */
+constants.MAX_CHARCOUNT = 1500;

[dmazzoni, 2016/12/07 06:40:50]

How about constants.LEAF_MAX_CHARCOUNT just so it's more clear that this is the
max to be considered a leaf, not a hard max or something like that

BTW, I'd consider something significantly smaller like 300. I think navigating
by line should be the default for anything more than a couple of lines worth.
Basically I'd set this to be longer than the typical heading or list item, so
anything longer than that is considered a paragraph.

Up to you though. If you've tried it out and this makes sense to you that's
great.

[David Tseng, 2016/12/07 17:11:30]

This was taken pretty much verbatim from group util.js (cClassic).

It worked pretty well there so I'm not too inclined to change it. This cl
doesn't aim to get the right amount of text to listen to at one time, but to
prevent tts from choking on a huge utterance. We're also incurring significant
overhead in those cases by having the speech queue in js.