jgraham
jgraham
FWIW the "hack" solution here would be to expose element screenshots via testdriver and then you could make a custom implementation of reftests in testharness tests.
Note that the file is `testing/geckodriver/.cargo/config.toml`, not `Cargo.toml`. The instructions worked as written for me.
https://github.com/jgraham/interop-results/tree/main/2024/results/revisions just has results per revision for every browser (in the product set we care about) for that revision. They are generated once i.e. it doesn't rescore ever past revision...
In theory the Rust-generated CSV files should be usable as a drop-in replacement for the current data, independent of new features. So I'd propose starting with that. There is one...
Just treating these like passes makes me nervous; it seems very misleading to claim that not supporting a feature amounts to passing tests for that feature (in particular for something...
> In the case of WebCodecs, the precondition contains calls to the WebCodecs API, so if the browser does not support WebCodecs, you'd get an error instead of PRECONDITION_FAILED. We...
Yes, sorry s/one/one or more/. I just mean that if the intersection of formats that all participants will implement is not null we should restrict the Interop-included tests to that...
> How can you get that without supporting the feature at all? If you don't support the feature at all, you'll get 0%, provided the tests fail for non-support of...
Yes. I don't think we can include tests for optional features in Interop without getting additional agreement on what all participants will actually implement, and targeting the tests specifically at...
Some initial feedback from Mozilla's point of view: * In future editions we should make sure to include features that have recently shipped in all browsers or recently become baseline....