|
|
Created:
4 years ago by David Tseng Modified:
3 years, 7 months ago Reviewers:
dmazzoni CC:
chromium-reviews, alemate+watch_chromium.org, oshima+watch_chromium.org, aboxhall+watch_chromium.org, nektar+watch_chromium.org, yuzo+watch_chromium.org, je_julie, arv+watch_chromium.org, dtseng+watch_chromium.org, dmazzoni+watch_chromium.org Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
DescriptionImplement 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
Patch Set 1 #Patch Set 2 : More incremental changes #Patch Set 3 : Update with latest fixes. #
Total comments: 11
Patch Set 4 : Indent. #Patch Set 5 : Fix plain text line braille. #
Messages
Total messages: 20 (11 generated)
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 ==========
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 ==========
dtseng@chromium.org changed reviewers: + dmazzoni@chromium.org
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.
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.
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. ==========
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.
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?
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 ==========
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 ==========
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 ==========
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.
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.
Patchset #4 (id:60001) has been deleted
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
The CQ bit was checked by dtseng@chromium.org
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 100001, "attempt_start_ts": 1495036496257560, "parent_rev": "a7956aa916bca6ef95c851e08494cdf7466b5d3c", "commit_rev": "d4685bc5518470a729e001859d325000257e6b77"}
Message was sent while issue was closed.
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... ==========
Message was sent while issue was closed.
Committed patchset #5 (id:100001) as https://chromium.googlesource.com/chromium/src/+/d4685bc5518470a729e001859d32... |