New issue
Advanced search Search tips

Issue 900060 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
yosin@chromium.org
editing-dev@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Selection.modify('move', 'forward', 'word') crosses word boundary

Project Member Reported by xiaoche...@chromium.org, Oct 30 
Chrome Version: Stable 70.0.3538.77 (Official Build) (64-bit)
OS: Linux

What steps will reproduce the problem?
(1) Open http://jsfiddle.net/42s56r0z/
(2) Observe

What is the expected result?

Caret should end up in the "editable" span inside uneditable table

What happens instead?

Caret ends up in the "editable" node after uneditable table

This is a regression introduced after we changed the implementation of NextWordPosition() to use TextOffsetMapping.

Or should we think the current behavior is the correct behavior?

Comment 1 by yosin@chromium.org, Oct 30 

Here is other browser's behaviors:

Chrome: "\n  editable"@3
 * At start of next word 
Edge: Doesn't have Selection#modify()
Firefox: "\n  editable"@11
 * At end of next word 
Safari: "editable"@8
 * At end of editable

I'm not sure which is right behavior...

Comment 2 by yosin@chromium.org, Oct 31 

FYI: When using TextSegments for PreviousWordPosition() and stopping at editing boundary, I introduced ClampWordStartToEditingBoundary()[1]


[1] https://chromium-review.googlesource.com/c/chromium/src/+/1018756/16/third_party/blink/renderer/core/editing/visible_units_word.cc
Project Member

Comment 3 by bugdroid1@chromium.org, Oct 31 

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

commit 350228ed5cd0e43c4ce2a5a04fe58eb86f5270e8
Author: Xiaocheng Hu <xiaochengh@chromium.org>
Date: Wed Oct 31 04:31:59 2018

Make PreviousWordPosition() utilitize TextSegments class

This patch changes |PreviousWordPosition()| to utilize |TextSegments|
class to make |PreviousWordPosition()| work with LayoutNG.

This patch also reveals an existing bug (or feature?) in editing
boundary adjustments, as shown in the changed layout test.

Bug: 778507, 900060
Change-Id: Ic797c960715576dc85a946a7b34b0be568c19805
Reviewed-on: https://chromium-review.googlesource.com/c/1307056
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604152}
[modify] https://crrev.com/350228ed5cd0e43c4ce2a5a04fe58eb86f5270e8/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/350228ed5cd0e43c4ce2a5a04fe58eb86f5270e8/third_party/WebKit/LayoutTests/editing/selection/mixed-editability-8.html
[modify] https://crrev.com/350228ed5cd0e43c4ce2a5a04fe58eb86f5270e8/third_party/blink/renderer/core/editing/text_segments.cc
[modify] https://crrev.com/350228ed5cd0e43c4ce2a5a04fe58eb86f5270e8/third_party/blink/renderer/core/editing/text_segments.h
[modify] https://crrev.com/350228ed5cd0e43c4ce2a5a04fe58eb86f5270e8/third_party/blink/renderer/core/editing/visible_units_word.cc
[modify] https://crrev.com/350228ed5cd0e43c4ce2a5a04fe58eb86f5270e8/third_party/blink/renderer/core/editing/visible_units_word_test.cc
►

Sign in to add a comment