Enable LayoutNGFullPositionForPoint Blink runtime feature.
Had to change some tests because of this: WebFrameTest.SmartClipData and WebFrameTest.SmartClipDataWithPinchZoom: Force Android editing behavior, or else it would fail on Mac and UNIX. CL:2552591 copied behavior from LayoutBlock::PositionForPoint(), where we'd consider non-hit-test candidates if there were no actual hit-test candidates. We now do this consistently, while in legacy layout we'll only do it for block children. The test here has only floated children (which means that ChildrenInline() will return true). (Adding an empty regular block next to the floats would change the behavior completely (since we'd then get the "block children behavior"), which is bogus). Since the point is below the float, on Mac and UNIX the start offset will now be at the end position inside the float that's just above the rectangle (because the caret is moved to the element boundary), rather than including the entire (parent) container. On Android and Windows this doesn't happen (since the caret isn't moved to the element boundary, and the caret happens to be exactly at offset 0, because of the x position of the point). editing/selection/click-on-block-image.html: Since NG PositionForPoint() finds what actually is the closest box (rather than doing it inaccurately in some cases, like legacy), we'll hit the line boxes in the test more than before. Test a bit further down to keep the test passing. Note that the manual version of the test passes anyway (i.e. the caret is placed on the correct side of the image, even when we hit the line boxes instead of the image). editing/selection/continuations-with-move-caret-to-boundary.html: Again, we now find the box that's actually the closest one, so aim better. editing/selection/offset-from-point.html: Remove workaround for vertical writing modes, since it would make us fail now. fast/writing-mode/positionForPoint.html: We now hit what's actually the closest box. This test is part of https://bugs.webkit.org/show_bug.cgi?id=92202 , and there's nothing that suggests that we depend on the old behavior. Bug: 1150362, 829028 Change-Id: I733b154ef473ab3d8064554213dde2e9b948e040 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2553547 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by:Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by:
Koji Ishii <kojii@chromium.org> Reviewed-by:
Yoshifumi Inoue <yosin@chromium.org> Cr-Commit-Position: refs/heads/master@{#831049}
Showing
Please register or sign in to comment