[iOS]: New test landed for https://trac.webkit.org/changeset/259762/webkit landed broken: editing/editable-region/hit-test-overlap.html --- /Volumes/Data/slave/ios-simulator-13-release-tests-wk2/build/layout-test-results/editing/editable-region/hit-test-overlap-expected.txt +++ /Volumes/Data/slave/ios-simulator-13-release-tests-wk2/build/layout-test-results/editing/editable-region/hit-test-overlap-actual.txt @@ -9,10 +9,11 @@ PASS (x = 281, y = 69, width = 249, height = 201) contains editable elements. Composited overlap: -PASS (x = 29, y = 343, width = 251, height = 201) does not contain editable elements. -PASS (x = 270, y = 400, width = 10, height = 10) does not contain editable elements. +FAIL (x = 29, y = 343, width = 251, height = 201) should not contain editable elements, but did. +FAIL (x = 270, y = 400, width = 10, height = 10) should not contain editable elements, but did. PASS (x = 281, y = 343, width = 249, height = 201) contains editable elements. PASS successfullyParsed is true +Some tests failed. TEST COMPLETE
<rdar://problem/61539886>
Test is expected to fail as written. There was some confusion (or I became confused) with regards to earlier revisions of the bug #209888 that had -_mayContainEditableElementsInRect only returning true if the frontmost layer didn't contain an editable element. I had coded the test with this behavior at the time, but it's not the final behavior I went with: -_mayContainEditableElementsInRect returns true if any hit layer contains an editable element. Thinking about it now, it may be possible to actually get what the test was trying to achieve....
(In reply to Daniel Bates from comment #2) > Thinking about it now, it may be possible to actually get what the test was > trying to achieve.... I'll achieve it in stages. First, for this bug, I'll just update the test to match the landed behavior. Then I will file a bug for new behavior.
Committed r259831: <https://trac.webkit.org/changeset/259831>