This issue came up while working on https://chromium-review.googlesource.com/c/chromium/src/+/879839 to fix  https://crbug.com/790777 .

If we have markup that looks like:

<div contenteditable='true'>
  <span contenteditable='false'>a</span>b
</div>

and we have a position inside the span element after the a (i.e. span@0) and call MostForwardCaretPosition() with kCanCrossEditingBoundary, I expected that the resulting position should be "b"@0. Instead, I got div@1. This is not the "most forward" visibly equivalent position.

I switched to using kCanSkipOverEditingBoundary and it fixed the issue. However, I think there may be cases when skipping over the editing boundary is not the desired behavior.

The issue is that in MostForwardCaretPosition(), we immediately return after crossing an editing boundary if it was passed kCanCrossEditingBoundary:

https://chromium.googlesource.com/chromium/src/+/e65d6289cd28260dcd05078ffd49ebdd8e8dbf77/third_party/WebKit/Source/core/editing/VisibleUnits.cpp#888
if (rule == kCanCrossEditingBoundary && boundary_crossed) {
  last_visible = current_pos;
  break;
}

I don't understand why the code does this. It seems incorrect.


 

This issue came up while working on https://chromium-review.googlesource.com/c/chromium/src/+/879839 to fix   https://crbug.com/790777  .

If we have markup that looks like:

<div contenteditable='true'>
  <span contenteditable='false'>a</span>b
</div>

and we have a position inside the span element after the a (i.e. span@0) and call MostForwardCaretPosition() with kCanCrossEditingBoundary, I expected that the resulting position should be "b"@0. Instead, I got div@1. This is not the "most forward" visibly equivalent position.

I switched to using kCanSkipOverEditingBoundary and it fixed the issue. However, I think there may be cases when skipping over the editing boundary is not the desired behavior.

The issue is that in MostForwardCaretPosition(), we immediately return after crossing an editing boundary if it was passed kCanCrossEditingBoundary:

https://chromium.googlesource.com/chromium/src/+/e65d6289cd28260dcd05078ffd49ebdd8e8dbf77/third_party/WebKit/Source/core/editing/VisibleUnits.cpp#1014

if (rule == kCanCrossEditingBoundary && boundary_crossed)
  return current_pos.DeprecatedComputePosition();

I don't understand why the code does this. It seems incorrect.


 

This issue came up while working on https://chromium-review.googlesource.com/c/chromium/src/+/879839 to fix    https://crbug.com/790777   .

If we have markup that looks like:

<div contenteditable='true'>
  <span contenteditable='false'>a</span>b
</div>

and we have a position inside the span element after the a (i.e. span@1) and call MostForwardCaretPosition() with kCanCrossEditingBoundary, I expected that the resulting position should be "b"@0. Instead, I got div@1. This is not the "most forward" visibly equivalent position.

I switched to using kCanSkipOverEditingBoundary and it fixed the issue. However, I think there may be cases when skipping over the editing boundary is not the desired behavior.

The issue is that in MostForwardCaretPosition(), we immediately return after crossing an editing boundary if it was passed kCanCrossEditingBoundary:

https://chromium.googlesource.com/chromium/src/+/e65d6289cd28260dcd05078ffd49ebdd8e8dbf77/third_party/WebKit/Source/core/editing/VisibleUnits.cpp#1014

if (rule == kCanCrossEditingBoundary && boundary_crossed)
  return current_pos.DeprecatedComputePosition();

I don't understand why the code does this. It seems incorrect.