Many layout tests have become flaky since landing https://chromium-review.googlesource.com/c/chromium/src/+/1145692, but that CL is making a completely valid change to how incoming Mojo message dispatch operates. That is, none of Mojo bindings' guarantees are being violated.
This indicates that something fundamental in the layout test framework is probably broken. In my observation so far, every flaky case has been a matter of snapshot timing: the layout test actually does what's expected if run independently in content_shell, but the layout test runner is too eager about checking for its expected output and thus does so before the page state has stabilized.
The CL in question has taken several months to land due to the frequency and volume with which incorrect test code (general test code, not layout test code) is landed across the tree, so ideally this problem could be fixed quicklt without a revert.
Many web tests have become flaky since landing https://chromium-review.googlesource.com/c/chromium/src/+/1145692, but that CL is making a completely valid change to how incoming Mojo message dispatch operates. That is, none of Mojo bindings' guarantees are being violated.
This indicates that something fundamental in the web test framework is probably broken. In my observation so far, every flaky case has been a matter of snapshot timing: the web test actually does what's expected if run independently in content_shell, but the web test runner is too eager about checking for its expected output and thus does so before the page state has stabilized.
The CL in question has taken several months to land due to the frequency and volume with which incorrect test code (general test code, not web test code) is landed across the tree, so ideally this problem could be fixed quicklt without a revert.
Automatically applying components based on crash stacktrace and information from OWNERS files.
If this is incorrect, please apply the Test-Predator-Wrong-Components label.
Adding a few random Blink owners. Any idea who might be most familiar with the precise machinery that drives web tests and could help me sort this out ASAP?
FWIW, I took a brief look at one of the failures; mode-exclusive.tentative.https.any.js:
https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/web-locks/mode-exclusive.tentative.https.any.js
The flaky failure are for the assert on line 33:
FAIL Requests for distinct resources can be granted assert_array_equals: property 0, expected 2 but got 1
Based on this it seems likely web-locks is dependent on the old task coalescing behavior in mojo for its expected behavior. It doesn't look like a test runner problem.
Would it be possible to create a way for mojo interfaces to annotate whether they need the deprecated coalescing behavior? If so then you could opt out the problematic interfaces in order to land the new default. Then we could burn down the interfaces relying on the old behavior.
+jsbell for web-locks.
There is a way to annotate interfaces by the way. mojo::Binding::EnableBatchDispatch(). If we can find specific interfaces that rely on the behavior, I'm OK with them calling this. But we still need to fix them ASAP.
ClusterFuzz testcase 5075337419554816 is verified as fixed, so closing issue as verified.
If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
Comment 1 by rockot@google.com
, Jan 17 (5 days ago)