Implement rich editable line output

Implement rich editable line output

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and headings.

Given a previous and current text selection event:
1. handle the case where the selections are on the same node by taking a diff of their text content based on their plain text representation.
2. otherwise, output the line based on the selection's start

Limitations

- In 2, we use ChromeVox's line hueristic to compute the line (i.e. nodes falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving by character).

This support is currently enabled only as a runtime flag one sets via the console:
editing.useRichText = true;
within a background page context.

TEST=EditingTest.RichTextMoveByLine
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2540553002
Cr-Commit-Position: refs/heads/master@{#472523}
Committed: https://chromium.googlesource.com/chromium/src/+/d4685bc5518470a729e001859d325000257e6b77

[David Tseng, 2016-11-28 23:33:05]

Description was changed from

==========
Rich Editable Text Implementation

This doc serves to present important use cases in editable text for screen
readers and the current low level tree data observed after each use case.

Use Case: Review and selection

While editing a text field, a basic feature of most screen readers is the
ability to review data by issuing standard shortcuts provided by the browser.
In addition, adding 'shift' to any of the movement commands starts or continues
a selection.

With respect to tree data, after either of the above commands occurs, the only
tree data that changes is the root's anchor and focus data. No nodes get
destroyed or updated.

Here are all possible states. Let prev and cur be ranges where cur results from
a text or text selection event on prev

Text movement
prev.anchorObject == cur.anchorObject and
prev.focusObject == cur.focusObject and
anchorObject == focusObject

This is movement or selection within the text of a specific node. We can take
the diff of the node's contents by calling the base editable text diff state
machine.

Issue: if the node above is a static text node, it may contain multiple inline
textboxes.
Solution: ideally, the selection from Blink would be on the inline textboxes.
Alternatively, ChromeVox would need to "adjust" the selection downward. If we
choose to adjust, the state machine would need to have knowledge of the line
breaks within the static text node.

Text selection across nodes
(prev.anchorObject == cur.anchorObject and
prev.focusObject != cur.focusObject) or
(prev.anchorObject != cur.anchorObject and
prev.focusObject == cur.focusObject)

This is either a selection or unselection. Output
(prev.end, cur.end) or
(prev.start, cur.start)
followed by unselected or selected depending on the direction of the unequal
endpoints.

Unrecognized transition
prev.anchorObject != cur.anchorObject
prev.focusObject != cur.focusObject

There was a discontinuous selection or a move across nodes. Output |cur|. If
|cur| is collapsed, surround the enclosing line and output. If it is
uncollapsed, output the range as is.

Use Case: text manipulation

insertion/deletion
prev.anchorObject == cur.anchorObject == cur.focusObject and
prev.value != cur.value

Text content changed within a single node. Pass values up to base editable text
state machine.

Unrecognized transition
prev.anchorObject != cur.anchorObject and
prev.focusObject != cur.focusObject
There was a large insertion or deletion. Just describe the current selection or
summarize the current caret.

Other transitions
prev.start == cur.start and
prev.end.node == pcur.end.node and
prev.end.node.name != cur.end.node.name

This would be auto completion of some sort where an editor maintains some kind
of selection. In this case, describe the selection diff
prev.end, cur.end

Conclusions
Notice there are the following state transitions:
0. prev == cur
Nothing happened.
1. prev and cur share all nodes and all nodes are the same, but offsets might
differ
Diff the text content
2. prev and cur share one endpoint (e.g. prev.start.node == cur.start.node and
prev.start.index == cur.start.index).
There was a selection or contraction
3. prev and cur don't have anything in common
Describe the current line or context

BUG=
==========

to

==========
Rich Editable Text Implementation

This doc serves to present important use cases in editable text for screen
readers and the current low level tree data observed after each use case.

Use Case: Review and selection

While editing a text field, a basic feature of most screen readers is the
ability to review data by issuing standard shortcuts provided by the browser.
In addition, adding 'shift' to any of the movement commands starts or continues
a selection.

With respect to tree data, after either of the above commands occurs, the only
tree data that changes is the root's anchor and focus data. No nodes get
destroyed or updated.

Here are all possible states. Let prev and cur be ranges where cur results from
a text or text selection event on prev

Text movement
prev.anchorObject == cur.anchorObject and
prev.focusObject == cur.focusObject and
anchorObject == focusObject

This is movement or selection within the text of a specific node. We can take
the diff of the node's contents by calling the base editable text diff state
machine.

Issue: if the node above is a static text node, it may contain multiple inline
textboxes.
Solution: ideally, the selection from Blink would be on the inline textboxes.
Alternatively, ChromeVox would need to "adjust" the selection downward. If we
choose to adjust, the state machine would need to have knowledge of the line
breaks within the static text node.

Text selection across nodes
(prev.anchorObject == cur.anchorObject and
prev.focusObject != cur.focusObject) or
(prev.anchorObject != cur.anchorObject and
prev.focusObject == cur.focusObject)

This is either a selection or unselection. Output
(prev.end, cur.end) or
(prev.start, cur.start)
followed by unselected or selected depending on the direction of the unequal
endpoints.

Unrecognized transition
prev.anchorObject != cur.anchorObject
prev.focusObject != cur.focusObject

There was a discontinuous selection or a move across nodes. Output |cur|. If
|cur| is collapsed, surround the enclosing line and output. If it is
uncollapsed, output the range as is.

Use Case: text manipulation

insertion/deletion
prev.anchorObject == cur.anchorObject == cur.focusObject and
prev.value != cur.value

Text content changed within a single node. Pass values up to base editable text
state machine.

Unrecognized transition
prev.anchorObject != cur.anchorObject and
prev.focusObject != cur.focusObject
There was a large insertion or deletion. Just describe the current selection or
summarize the current caret.

Other transitions
prev.start == cur.start and
prev.end.node == pcur.end.node and
prev.end.node.name != cur.end.node.name

This would be auto completion of some sort where an editor maintains some kind
of selection. In this case, describe the selection diff
prev.end, cur.end

Conclusions
Notice there are the following state transitions:
0. prev == cur
Nothing happened.
1. prev and cur share all nodes and all nodes are the same, but offsets might
differ
Diff the text content
2. prev and cur share one endpoint (e.g. prev.start.node == cur.start.node and
prev.start.index == cur.start.index).
There was a selection or contraction
3. prev and cur don't have anything in common
Describe the current line or context

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[David Tseng, 2016-11-28 23:37:38]

Description was changed from

==========
Rich Editable Text Implementation

This doc serves to present important use cases in editable text for screen
readers and the current low level tree data observed after each use case.

Use Case: Review and selection

While editing a text field, a basic feature of most screen readers is the
ability to review data by issuing standard shortcuts provided by the browser.
In addition, adding 'shift' to any of the movement commands starts or continues
a selection.

With respect to tree data, after either of the above commands occurs, the only
tree data that changes is the root's anchor and focus data. No nodes get
destroyed or updated.

Here are all possible states. Let prev and cur be ranges where cur results from
a text or text selection event on prev

Text movement
prev.anchorObject == cur.anchorObject and
prev.focusObject == cur.focusObject and
anchorObject == focusObject

This is movement or selection within the text of a specific node. We can take
the diff of the node's contents by calling the base editable text diff state
machine.

Issue: if the node above is a static text node, it may contain multiple inline
textboxes.
Solution: ideally, the selection from Blink would be on the inline textboxes.
Alternatively, ChromeVox would need to "adjust" the selection downward. If we
choose to adjust, the state machine would need to have knowledge of the line
breaks within the static text node.

Text selection across nodes
(prev.anchorObject == cur.anchorObject and
prev.focusObject != cur.focusObject) or
(prev.anchorObject != cur.anchorObject and
prev.focusObject == cur.focusObject)

This is either a selection or unselection. Output
(prev.end, cur.end) or
(prev.start, cur.start)
followed by unselected or selected depending on the direction of the unequal
endpoints.

Unrecognized transition
prev.anchorObject != cur.anchorObject
prev.focusObject != cur.focusObject

There was a discontinuous selection or a move across nodes. Output |cur|. If
|cur| is collapsed, surround the enclosing line and output. If it is
uncollapsed, output the range as is.

Use Case: text manipulation

insertion/deletion
prev.anchorObject == cur.anchorObject == cur.focusObject and
prev.value != cur.value

Text content changed within a single node. Pass values up to base editable text
state machine.

Unrecognized transition
prev.anchorObject != cur.anchorObject and
prev.focusObject != cur.focusObject
There was a large insertion or deletion. Just describe the current selection or
summarize the current caret.

Other transitions
prev.start == cur.start and
prev.end.node == pcur.end.node and
prev.end.node.name != cur.end.node.name

This would be auto completion of some sort where an editor maintains some kind
of selection. In this case, describe the selection diff
prev.end, cur.end

Conclusions
Notice there are the following state transitions:
0. prev == cur
Nothing happened.
1. prev and cur share all nodes and all nodes are the same, but offsets might
differ
Diff the text content
2. prev and cur share one endpoint (e.g. prev.start.node == cur.start.node and
prev.start.index == cur.start.index).
There was a selection or contraction
3. prev and cur don't have anything in common
Describe the current line or context

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Rich Editable Text Implementation

This doc serves to present important use cases in editable text for screen
readers and the current low level tree data observed after each use case.

Use Case: Review and selection

While editing a text field, a basic feature of most screen readers is the
ability to review data by issuing standard shortcuts provided by the browser.
In addition, adding 'shift' to any of the movement commands starts or continues
a selection.

With respect to tree data, after either of the above commands occurs, the only
tree data that changes is the root's anchor and focus data. No nodes get
destroyed or updated.

Here are all possible states. Let prev and cur be ranges where cur results from
a text or text selection event on prev

Text movement
prev.anchorObject == cur.anchorObject and
prev.focusObject == cur.focusObject and
anchorObject == focusObject

This is movement or selection within the text of a specific node. We can take
the diff of the node's contents by calling the base editable text diff state
machine.

Issue: if the node above is a static text node, it may contain multiple inline
textboxes.
Solution: ideally, the selection from Blink would be on the inline textboxes.
Alternatively, ChromeVox would need to "adjust" the selection downward. If we
choose to adjust, the state machine would need to have knowledge of the line
breaks within the static text node.

Text selection across nodes
(prev.anchorObject == cur.anchorObject and
prev.focusObject != cur.focusObject) or
(prev.anchorObject != cur.anchorObject and
prev.focusObject == cur.focusObject)

This is either a selection or unselection. Output
(prev.end, cur.end) or
(prev.start, cur.start)
followed by unselected or selected depending on the direction of the unequal
endpoints.

Default transition
prev.anchorObject != cur.anchorObject
prev.focusObject != cur.focusObject

There was a discontinuous selection or a move across nodes. Output |cur|. If
|cur| is collapsed, surround the enclosing line and output. If it is
uncollapsed, output the range as is.

Issue:
In some cases, anchor and focus are placed around bogus positions e.g. on a div
with text offsets (the offset doesn't actually index into a child node). In this
patch, we simply say "blank" for positions we don't describe.

Use Case: text manipulation

insertion/deletion
prev.anchorObject == cur.anchorObject == cur.focusObject and
prev.value != cur.value

Text content changed within a single node. Pass values up to base editable text
state machine.

Unrecognized transition
prev.anchorObject != cur.anchorObject and
prev.focusObject != cur.focusObject
There was a large insertion or deletion. Just describe the current selection or
summarize the current caret.

Other transitions
prev.start == cur.start and
prev.end.node == pcur.end.node and
prev.end.node.name != cur.end.node.name

This would be auto completion of some sort where an editor maintains some kind
of selection. In this case, describe the selection diff
prev.end, cur.end

Conclusions
Notice there are the following state transitions:
0. prev == cur
Nothing happened.
1. prev and cur share all nodes and all nodes are the same, but offsets might
differ
Diff the text content
2. prev and cur share one endpoint (e.g. prev.start.node == cur.start.node and
prev.start.index == cur.start.index).
There was a selection or contraction
3. prev and cur don't have anything in common
Describe the current line or context

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[David Tseng, 2017-01-12 00:34:25]

dtseng@chromium.org changed reviewers:
+ dmazzoni@chromium.org

[David Tseng, 2017-01-12 00:34:26]

I think this is ready for some feedback.

I think we want to go this direction in general and perhaps flesh out some of
the cases where this won't work.

Some of the issues reveal limitations in Blink.

Please let me know what you think.

[dmazzoni, 2017-01-13 18:43:54]

Some comments inline below:

> Text movement
> prev.anchorObject == cur.anchorObject and
> prev.focusObject == cur.focusObject and anchorObject == focusObject
>
> This is movement or selection within the text of a specific node. We
> can take the diff of the node's contents by calling the base editable
> text diff state machine.
>
> Issue: if the node above is a static text node, it may contain
> multiple inline textboxes.  Solution: ideally, the selection from
> Blink would be on the inline textboxes. Alternatively, ChromeVox would
> need to "adjust" the selection downward. If we choose to adjust, the
> state machine would need to have knowledge of the line breaks within
> the static text node.

I like the idea of having Blink return the selection node and offset
for the text node and also for the inline text box. That seems ideal
to me since there are times when we need both.

> Text selection across nodes (prev.anchorObject == cur.anchorObject and
> prev.focusObject != cur.focusObject) or (prev.anchorObject !=
> cur.anchorObject and prev.focusObject == cur.focusObject)

> This is either a selection or unselection. Output (prev.end, cur.end)
> or (prev.start, cur.start) followed by unselected or selected
> depending on the direction of the unequal endpoints.

Sounds good. A rare corner case is that both change. This could happen
if the user has a partial selection and then they press Ctrl+A to
select all.

> insertion/deletion prev.anchorObject == cur.anchorObject ==
> cur.focusObject and prev.value != cur.value

> Text content changed within a single node. Pass values up to base
> editable text state machine.

I think the problem here is that we can't assume that the object
won't change when the value changes. We have to handle the possibility
that the object changes ids. I think the solution here is to handle
this case in the tree change callback.

[David Tseng, 2017-05-08 22:18:15]

Description was changed from

==========
Rich Editable Text Implementation

This doc serves to present important use cases in editable text for screen
readers and the current low level tree data observed after each use case.

Use Case: Review and selection

While editing a text field, a basic feature of most screen readers is the
ability to review data by issuing standard shortcuts provided by the browser.
In addition, adding 'shift' to any of the movement commands starts or continues
a selection.

With respect to tree data, after either of the above commands occurs, the only
tree data that changes is the root's anchor and focus data. No nodes get
destroyed or updated.

Here are all possible states. Let prev and cur be ranges where cur results from
a text or text selection event on prev

Text movement
prev.anchorObject == cur.anchorObject and
prev.focusObject == cur.focusObject and
anchorObject == focusObject

This is movement or selection within the text of a specific node. We can take
the diff of the node's contents by calling the base editable text diff state
machine.

Issue: if the node above is a static text node, it may contain multiple inline
textboxes.
Solution: ideally, the selection from Blink would be on the inline textboxes.
Alternatively, ChromeVox would need to "adjust" the selection downward. If we
choose to adjust, the state machine would need to have knowledge of the line
breaks within the static text node.

Text selection across nodes
(prev.anchorObject == cur.anchorObject and
prev.focusObject != cur.focusObject) or
(prev.anchorObject != cur.anchorObject and
prev.focusObject == cur.focusObject)

This is either a selection or unselection. Output
(prev.end, cur.end) or
(prev.start, cur.start)
followed by unselected or selected depending on the direction of the unequal
endpoints.

Default transition
prev.anchorObject != cur.anchorObject
prev.focusObject != cur.focusObject

There was a discontinuous selection or a move across nodes. Output |cur|. If
|cur| is collapsed, surround the enclosing line and output. If it is
uncollapsed, output the range as is.

Issue:
In some cases, anchor and focus are placed around bogus positions e.g. on a div
with text offsets (the offset doesn't actually index into a child node). In this
patch, we simply say "blank" for positions we don't describe.

Use Case: text manipulation

insertion/deletion
prev.anchorObject == cur.anchorObject == cur.focusObject and
prev.value != cur.value

Text content changed within a single node. Pass values up to base editable text
state machine.

Unrecognized transition
prev.anchorObject != cur.anchorObject and
prev.focusObject != cur.focusObject
There was a large insertion or deletion. Just describe the current selection or
summarize the current caret.

Other transitions
prev.start == cur.start and
prev.end.node == pcur.end.node and
prev.end.node.name != cur.end.node.name

This would be auto completion of some sort where an editor maintains some kind
of selection. In this case, describe the selection diff
prev.end, cur.end

Conclusions
Notice there are the following state transitions:
0. prev == cur
Nothing happened.
1. prev and cur share all nodes and all nodes are the same, but offsets might
differ
Diff the text content
2. prev and cur share one endpoint (e.g. prev.start.node == cur.start.node and
prev.start.index == cur.start.index).
There was a selection or contraction
3. prev and cur don't have anything in common
Describe the current line or context

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Implement rich editable output for ChromeVox

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
- first, we handle the case where the selections are on the same node by taking
a diff of their text content based on their plain text representation
- next, if the selections are on different nodes, we handle both selection (one
endpoint of the selection equals), or output of a line (neither endpoint
equals).

Limitations

- In the non-textual output path, we use ChromeVox's line hueristic to compute
the line (i.e. nodes falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only on builds from source using the current
Chrome channel.
==========

[David Tseng, 2017-05-08 22:19:25]

PTAL. Reviving this one.

I believe I've worked out at least the highest priority painpoints enough to
land for builds from source so that we can play with it.

[dmazzoni, 2017-05-09 04:49:47]

Thanks for doing this, having this around in parallel without
shipping it yet will be great.

I don't quite understand the "In the non-textual output path" comment,
can you clarify - do you mean speech or braille or things like
images or what?

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/cursors.js
(right):

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/cursors.js:412: get
deepEquivalent() {
Might be nice to have a unit test for this?

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/cursors.js:423:
break;
nit: indent

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js
(right):

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js:244: if
(prev.equals(cur))
What if the range stays the same but the contents changes?

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js:271: }
else if (cur.start.equals(prev.start)) {
Do you need a braille output rule for this case?

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js:279: }
else if (cur.end.equals(prev.end)) {
Same, this does this case need braille?

[David Tseng, 2017-05-09 21:54:30]

Description was changed from

==========
Implement rich editable output for ChromeVox

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
- first, we handle the case where the selections are on the same node by taking
a diff of their text content based on their plain text representation
- next, if the selections are on different nodes, we handle both selection (one
endpoint of the selection equals), or output of a line (neither endpoint
equals).

Limitations

- In the non-textual output path, we use ChromeVox's line hueristic to compute
the line (i.e. nodes falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only on builds from source using the current
Chrome channel.
==========

to

==========
Implement rich editable output for ChromeVox

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
1. handle the case where the selections are on the same node by taking a diff of
their text content based on their plain text representation.
2. otherwise, output the line based on the selection's start

Limitations

- In 2, we use ChromeVox's line hueristic to compute the line (i.e. nodes
falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only on builds from source using the current
Chrome channel.

TEST=EditingTest.RichTextMoveByLine
==========

[David Tseng, 2017-05-09 23:10:25]

Description was changed from

==========
Implement rich editable output for ChromeVox

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
1. handle the case where the selections are on the same node by taking a diff of
their text content based on their plain text representation.
2. otherwise, output the line based on the selection's start

Limitations

- In 2, we use ChromeVox's line hueristic to compute the line (i.e. nodes
falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only on builds from source using the current
Chrome channel.

TEST=EditingTest.RichTextMoveByLine
==========

to

==========
Implement rich editable output for ChromeVox

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
1. handle the case where the selections are on the same node by taking a diff of
their text content based on their plain text representation.
2. otherwise, output the line based on the selection's start

Limitations

- In 2, we use ChromeVox's line hueristic to compute the line (i.e. nodes
falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only on builds from source using the current
Chrome channel.

TEST=EditingTest.RichTextMoveByLine
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[David Tseng, 2017-05-09 23:12:27]

Description was changed from

==========
Implement rich editable output for ChromeVox

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
1. handle the case where the selections are on the same node by taking a diff of
their text content based on their plain text representation.
2. otherwise, output the line based on the selection's start

Limitations

- In 2, we use ChromeVox's line hueristic to compute the line (i.e. nodes
falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only on builds from source using the current
Chrome channel.

TEST=EditingTest.RichTextMoveByLine
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Implement rich editable line output

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
1. handle the case where the selections are on the same node by taking a diff of
their text content based on their plain text representation.
2. otherwise, output the line based on the selection's start

Limitations

- In 2, we use ChromeVox's line hueristic to compute the line (i.e. nodes
falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only as a runtime flag one sets via the
console:
editing.useRichText = true;
within a background page context.

TEST=EditingTest.RichTextMoveByLine
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[David Tseng, 2017-05-09 23:13:50]

PTAL. Let's start only with line output and get that working. Test add there.

Word and character output are not working properly especially when crossing
significant boundaries such as new lines, node boundaries, etc.

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js
(right):

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js:244: if
(prev.equals(cur))
On 2017/05/09 04:49:47, dmazzoni wrote:
> What if the range stays the same but the contents changes?

Done.

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js:271: }
else if (cur.start.equals(prev.start)) {
On 2017/05/09 04:49:47, dmazzoni wrote:
> Do you need a braille output rule for this case?

Removed.

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/editing.js:279: }
else if (cur.end.equals(prev.end)) {
On 2017/05/09 04:49:46, dmazzoni wrote:
> Same, this does this case need braille?

Removed.

[David Tseng, 2017-05-09 23:22:52]

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/cursors.js
(right):

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/cursors.js:412: get
deepEquivalent() {
On 2017/05/09 04:49:46, dmazzoni wrote:
> Might be nice to have a unit test for this?

Before we get there, do you have any comments on whether this resembles the
version found in Blink for positions/selections? I mostly wrote this to get
something working when trying to arrow through a content editable.

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/cursors.js:423:
break;
On 2017/05/09 04:49:46, dmazzoni wrote:
> nit: indent

Done.

[David Tseng, 2017-05-09 23:23:49]

Patchset #4 (id:60001) has been deleted

[dmazzoni, 2017-05-10 06:02:52]

lgtm

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
File chrome/browser/resources/chromeos/chromevox/cvox2/background/cursors.js
(right):

https://codereview.chromium.org/2540553002/diff/40001/chrome/browser/resource...
chrome/browser/resources/chromeos/chromevox/cvox2/background/cursors.js:412: get
deepEquivalent() {
On 2017/05/09 23:22:51, David Tseng wrote:
> On 2017/05/09 04:49:46, dmazzoni wrote:
> > Might be nice to have a unit test for this?
> 
> Before we get there, do you have any comments on whether this resembles the
> version found in Blink for positions/selections? I mostly wrote this to get
> something working when trying to arrow through a content editable.

I think so. Note that Nektarios has already implemented this
(AXPosition::AsLeafTextPosition), which is in ui/accessibility so we
could use it here. What would you think about adding native bindings
for AXPosition or some subset of it? If we find any bugs we'd only have
to fix them in one place

[David Tseng, 2017-05-17 15:54:56]

The CQ bit was checked by dtseng@chromium.org

[commit-bot: I haz the power, 2017-05-17 15:55:33]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-17 19:11:36]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1495036496257560,
"parent_rev": "a7956aa916bca6ef95c851e08494cdf7466b5d3c", "commit_rev":
"d4685bc5518470a729e001859d325000257e6b77"}

[commit-bot: I haz the power, 2017-05-17 19:11:47]

Description was changed from

==========
Implement rich editable line output

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
1. handle the case where the selections are on the same node by taking a diff of
their text content based on their plain text representation.
2. otherwise, output the line based on the selection's start

Limitations

- In 2, we use ChromeVox's line hueristic to compute the line (i.e. nodes
falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only as a runtime flag one sets via the
console:
editing.useRichText = true;
within a background page context.

TEST=EditingTest.RichTextMoveByLine
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Implement rich editable line output

Given:
- text selection change events (from accessibility)
- cvox.EditableTextBase module
- Output module

ChromeVox can provie rich text feedback for simple structures such as links and
headings.

Given a previous and current text selection event:
1. handle the case where the selections are on the same node by taking a diff of
their text content based on their plain text representation.
2. otherwise, output the line based on the selection's start

Limitations

- In 2, we use ChromeVox's line hueristic to compute the line (i.e. nodes
falling on the same y-coordinate).
- bugs with selection (e.g. selections falling on unexpected nodes when moving
by character).

This support is currently enabled only as a runtime flag one sets via the
console:
editing.useRichText = true;
within a background page context.

TEST=EditingTest.RichTextMoveByLine
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2540553002
Cr-Commit-Position: refs/heads/master@{#472523}
Committed:
https://chromium.googlesource.com/chromium/src/+/d4685bc5518470a729e001859d32...
==========

[commit-bot: I haz the power, 2017-05-17 19:11:48]

Committed patchset #5 (id:100001) as
https://chromium.googlesource.com/chromium/src/+/d4685bc5518470a729e001859d32...