Revert "Enable LayoutNGFullPositionForPoint Blink runtime feature."
This reverts commit b2cf6bb4. Reason for revert: We are worried about use-after-free bugs (long-lived HitTestResult keeping a NGPhysicalBoxFragment reference, which may point to a dead LayoutObject) with this solution; see crbug.com/1152696 Original change's description: > 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} TBR=yosin@chromium.org,kojii@chromium.org,ikilpatrick@chromium.org,mstensho@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 1150362 Bug: 829028 Change-Id: I6a6fc96c11acd379a01060f105f861e70f320ea2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2584855Reviewed-by:Morten Stenshorne <mstensho@chromium.org> Reviewed-by:
Koji Ishii <kojii@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#836235}
Showing
Please register or sign in to comment