Closed (fixed)
Project:
Drupal core
Version:
9.4.x-dev
Component:
ckeditor5.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
8 Mar 2022 at 14:56 UTC
Updated:
25 Mar 2022 at 16:49 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
lauriiiComment #3
wim leersOhhhh — so it used to fail mostly because the modal dialog didn't ever appear, and hence the other selector surely cannot exist either?
But … how is that different than just using the original selector? 🤔
Ah … we could've kept the original selector too. The key thing is that we first check that the element exists and only then
click()it.@lauriii chose to just first assert to wait for the modal, because that is conceptually easier to understand: it documents in the test what we are waiting for. 👍
Comment #4
lauriiiMy theory is that it's a problem with the dialog resizing and positioning dynamically. Basically right now we're waiting for the element to exist, and it exists before the dialog has had a chance to resize and position, and therefore the click fails. I don't think what I have there is 100% solid, but I think it should be solid enough to not fail within realistic constraints.
Comment #5
wim leersOhhhh, I hadn't even thought about repositioning potentially causing clicks to fail! 🤯
Comment #6
wim leersTo clarify: definitely RTBC now! 🚀
This undoes one of the skips in #3268070: Temporarily skip even more failing tests.
Comment #7
xjmWe need to run this many more times, and compare it to the baseline each time. I will post patches that do that.
Comment #8
xjmComment #9
xjmSo the baseline isn't failing under current conditions. We should retest these when there are more jobs (around when there are commits pushed or RTBC retesting is happening), or come up with a 100% fail patch that proves a race condition that is fixed by the fix.
Comment #10
lauriiiThis should be a 100% solid solution which would pass also against the changes that make the 100% failing patch fail but requires changes outside of that specific failure. I think this is a better approach - #2 was basically just trying to remain consistent which probably shouldn't be a priority over fixing the random fail in the most robust possible way.
Comment #13
lauriiiBaseline is same as in #10.
Comment #14
xjmUnfortunately the fails above are:
....Whereas the fail we expect from the random fail is:
So, I'll try queuing more of #8 in a few hours.
Comment #15
lauriiiThe fails for the 100% failing patch won't be the same because there are other cases in the tests that are prone to the same race condition. That's why I proposed first the pragmatic solution which would have just made all of the cases where dialog is being opened consistent, since the failures were happening in this one case where we were waiting for the dialog being opened differently.
I'm fine with the solution in #13, it just needs more changes that are not directly related to the random failure.
Comment #19
xjmThanks @lauriii, that makes sense. This is also an identical fix to the one we've used for other race conditions in the past, so hopefully it will harden this test against other failures in the future.
Committed to 10.0.x, and cherry-picked to 9.4.x and 9.3.x. Thanks!
Comment #20
wim leersComment #21
xjmForgot to mention that this one doesn't get 9.2.x backport because no CKE5 in 9.2.x. :)