Created attachment 454543 [details] Patch

(In reply to Wenson Hsieh from comment #1) > Created attachment 454543 [details] > Patch Waiting for a single runloop after calling `resetText` apparently causes Mac WK1 to fail...

This only modified the test, is there any way to fix or detect the issue in the harness?

(In reply to Alexey Proskuryakov from comment #3) > This only modified the test, is there any way to fix or detect the issue in > the harness? It's surely detectable with a `UIHelper.isWebKit2()` check, but I was hoping to avoid a workaround of that kind. Though, maybe it's worth going that route if it means we can stabilize EWS in the short term?

What I mean is that it's difficult to isolate problems of the kind where a test makes subsequent tests fail, so it's important to prevent such situations. Improving one test that does something wrong does nothing to prevent other tests from having the same problem in the future. Either clearing the state between tests, or detecting the issue and failing eagerly with a RELEASE_ASSERT would be a permanent solution for the problem. I do not have a suggestion on how to fix WK2 without breaking WK1, as I don't understand what causes that.

(In reply to Alexey Proskuryakov from comment #5) > What I mean is that it's difficult to isolate problems of the kind where a > test makes subsequent tests fail, so it's important to prevent such > situations. Improving one test that does something wrong does nothing to > prevent other tests from having the same problem in the future. Either > clearing the state between tests, or detecting the issue and failing eagerly > with a RELEASE_ASSERT would be a permanent solution for the problem. > AFAIK, the intent of that release assertion is to catch instances like this where tests end before UI-script callbacks are invoked, so I think we would expect crashes in the case where there are dangling callbacks. It is, however, quite unfortunate that it surfaces as a failure in the _subsequent_ layout test, which makes the true failing test a lot more difficult to pin down. > I do not have a suggestion on how to fix WK2 without breaking WK1, as I > don't understand what causes that.

Exactly. I'm not talking about that RELEASE_ASSERT, but about adding a new one that would catch the issue in time.

(In reply to Alexey Proskuryakov from comment #7) > Exactly. I'm not talking about that RELEASE_ASSERT, but about adding a new > one that would catch the issue in time. Yeah, this sounds like a good area to explore ("attribute the failure to the correct layout test"). I think that refactoring this code so that we can just log a warning and continue (without impacting the correctness of the subsequent test) would also be viable option. I think that both the above, as well as fixing this particular layout test are items we should investigate at some point; either would be sufficient to deal with the flaky test failure tracked in this Bugzilla bug.

<rdar://problem/90529903>

r291709 Marking expectations to help EWS queue.

Skipping editing-word-with-marker-1.html in bug 238767.

Pull request: https://github.com/WebKit/WebKit/pull/2803

Committed 252963@main (e456d22e637f): <https://commits.webkit.org/252963@main> Reviewed commits have been landed. Closing PR #2803 and removing active labels.