[Webkit-unassigned] [Bug 252269] Match upstream WPT semantics for testharness tests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=252269

Sam Sneddon [:gsnedders] <gsnedders at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |achristensen at apple.com,
                   |                            |cdumez at apple.com,
                   |                            |darin at apple.com

--- Comment #2 from Sam Sneddon [:gsnedders] <gsnedders at apple.com> ---
>From bug 161693, though all of these really relevant to the wider issue:

(In reply to Darin Adler from comment #5)
> I’m not going to say review+ because I am not sure this is the best solution.
> 
> The cost of this is that when a test does fail, we won’t be able to see
> which assertion failed. And if we turn the real failures back on then we
> will get failures because of expected files that expect the failure log to
> be disabled.
> 
> So is that cost worth the benefit of less flakiness? Is there some other way
> of achieving that goal? Maybe we can adjust things so that the code that
> compares the results with expected results can understand what may vary?

(In reply to Chris Dumez from comment #7)
> r=me with comments. For the record, I do think the best solution would be to
> avoid such flaky asserts upstream in web-platform-tests. However, based on
> feedback, I think this is unlikely to happen. As a result, I think this
> patch is the second best option and we can do this easily and quickly. This
> is MUCH better than skipping tests.

(In reply to Alex Christensen from comment #8)
> I think ideally we wouldn't need this because all the tests would always
> have deterministic output.  Since that isn't the case, we need something
> like this.  We should bring it up when we discuss this in a few weeks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230214/f0d03411/attachment.htm>