24 Mar 2024 |
sideshowbarker | rather than wrapping the whole thing in one promise_test | 13:03:23 |
25 Mar 2024 |
Domenic | Wait this seems like it's working as intended? You're saying asssert_true(someElement), and someElement === true is false, so the assert is failing | 04:48:50 |
Domenic | I think you want instead assert_not_equals(someElement, null) | 04:49:07 |
sideshowbarker | Yeah I ended up kind of completely re-working it | 07:32:24 |
sideshowbarker | hang on, I’ll paste it in | 07:32:34 |
sideshowbarker | findStringInDetails = (id, contents) => {
let t = async_test(`auto-expand on find-in-page match: ${id}`);
document.body.insertAdjacentHTML("beforeend", `<details id=${id}>${contents}</details>`);
let details = document.getElementById(id);
details.ontoggle = t.step_func_done(function(e) {
details.remove();
assert_equals(e.newState, "open", `newState is “open”: ${id}`);
assert_equals(e.oldState, "closed", `oldState was “closed”: ${id}`);
assert_true(details.open, `details element is open: ${id}`);
});
testRunner.findInPage(id, []);
}
let target;
target = "details-simple"; findStringInDetails(target, target);
target = "details-in-p"; findStringInDetails(target, `<p>${target}</p>`);
target = "details-in-table"; findStringInDetails(target, `<table><tr><td>${target}</table>`);
target = "details-nested-simple"; findStringInDetails(target, `<details>${target}</details>`);
target = "details-nested-target-in-p"; findStringInDetails(target, `<details><p>${target}</p></details>`);
target = "details-nested-target-in-table"; findStringInDetails(target, `<details><table><tr><td>${target}</table></details>`);
| 07:33:36 |
sideshowbarker | * findStringInDetails = (id, contents) => {
let t = async_test(`auto-expand on find-in-page match: ${id}`);
document.body.insertAdjacentHTML("beforeend", `<details id=${id}>${contents}</details>`);
let details = document.getElementById(id);
details.ontoggle = t.step_func_done(function(e) {
details.remove();
assert_equals(e.newState, "open", `newState is “open”: ${id}`);
assert_equals(e.oldState, "closed", `oldState was “closed”: ${id}`);
assert_true(details.open, `details element is open: ${id}`);
});
testRunner.findInPage(id, []);
}
let target;
target = "details-simple"; findStringInDetails(target, target);
target = "details-in-p"; findStringInDetails(target, `<p>${target}</p>`);
target = "details-in-table"; findStringInDetails(target, `<table><tr><td>${target}</table>`);
target = "details-nested-simple"; findStringInDetails(target, `<details>${target}</details>`);
target = "details-nested-target-in-p"; findStringInDetails(target, `<details><p>${target}</p></details>`);
target = "details-nested-target-in-table"; findStringInDetails(target, `<details><table><tr><td>${target}</table></details>`);
(you’ll need to scroll to see the full script)
| 07:34:23 |
sideshowbarker | * findStringInDetails = (id, contents) => {
let t = async_test(`auto-expand on find-in-page match: ${id}`);
document.body.insertAdjacentHTML("beforeend", `<details id=${id}>${contents}</details>`);
let details = document.getElementById(id);
details.ontoggle = t.step_func_done(function(e) {
details.remove();
assert_equals(e.newState, "open", `newState is “open”: ${id}`);
assert_equals(e.oldState, "closed", `oldState was “closed”: ${id}`);
assert_true(details.open, `details element is open: ${id}`);
});
testRunner.findInPage(id, []);
}
let target;
target = "details-simple"; findStringInDetails(target, target);
target = "details-in-p"; findStringInDetails(target, `<p>${target}</p>`);
target = "details-in-table"; findStringInDetails(target, `<table><tr><td>${target}</table>`);
target = "details-nested-simple"; findStringInDetails(target, `<details>${target}</details>`);
target = "details-nested-target-in-p"; findStringInDetails(target, `<details><p>${target}</p></details>`);
target = "details-nested-target-in-table"; findStringInDetails(target, `<details><table><tr><td>${target}</table></details>`);
(you’ll need to scroll to see the full script — 19 lines)
| 07:34:41 |
| Eric Meyer changed their display name from Eric Meyer to Eric Meyer (holiday 25-26 March). | 14:40:03 |
| Sam Sneddon [:gsnedders] changed their display name from Sam Sneddon [:gsnedders] to Sam Sneddon [:gsnedders] [OOO]. | 17:07:27 |
26 Mar 2024 |
ErichDonGubler | jgraham: I'm trying to split up some WebGPU CTS test runs in Firefox CI based on --skip-implementation-status and/or --backlog . After looking through the implementation of wptrunner , I think I've found some conflicting information I was hoping to clarify. 🧵 | 20:25:14 |
ErichDonGubler | The Test Metadata page's section for implementation-status states that the set of values permitted are:
One of the values implementing , not-implementing or default .
| 20:25:26 |
ErichDonGubler | Looking back through chat here, it seems that the backlog is a Mozilla-specific addition (and I presume unsupported was renamed to not-implementing ). So, my guess is that the full set of values permitted for Mozilla's testing metadata is:
implementing : Something that is going to be implemented fully in an agent, but perhaps not yet?
not-implementing : Something that an agent does not intend to implement, usually in agent-specific metadata.
default : Something that is fully implemented in an agent.
backlog : Things that Firefox intends to ship…eventually.
| 20:25:35 |
ErichDonGubler | …but the definition I've associated with default has a conflict; it seems? Test.implementation_status returns implementing , not default , as the seeming default value. | 20:25:41 |
ErichDonGubler | My questions are these: | 20:25:45 |
ErichDonGubler |
- Is the above set of values and their definitions correct?
| 20:25:48 |
ErichDonGubler |
- Assuming the above, why is
implementing used as the default, and not default ? Is default an outdated status, maybe?
| 20:25:49 |
ErichDonGubler | Huh, wptrunner doesn't seem to accept the default status in its --skip-implementation-status array, either. 🤔 | 20:30:07 |
ErichDonGubler | * Huh, wptrunner doesn't seem to accept the default status in accepted values for --skip-implementation-status array, either. 🤔 | 20:30:17 |
| krosylight changed their display name from krosylight | pto until 2024-03-26 to krosylight. | 23:21:08 |
27 Mar 2024 |
ErichDonGubler | * Huh, wptrunner doesn't seem to include the default status in accepted values for --skip-implementation-status array, either. 🤔 | 02:22:29 |
| Eric Meyer changed their display name from Eric Meyer (holiday 25-26 March) to Eric Meyer. | 12:01:55 |
Samson | When passing --timeout-multiplier it should also multiply harness timeout, right? | 12:08:03 |
jgraham | Yes | 12:59:44 |
jgraham | So I think that the command line parsing is the only bit that actually validates the implementation-status values.
I also think you're correct that the docs are wrong to claim there's a "default" value; that should be "implementing", and "backlog" is missing.
| 15:07:51 |
jgraham | default just doesn't exist | 15:08:17 |
annevk | jgraham: could you r+ https://github.com/web-platform-tests/wpt/pull/45350 so when there's no objections by next week I can merge it and the spec change? | 15:47:02 |
ErichDonGubler | Okay, so, the actual set of values seems to be:
implementing : Anywhere from "is being implemented" to "we believe we have fully implemented this" for an agent; the intent is "yes please let's test this".
not-implementing : Agent is not planning on implementing this, please don't test it.
backlog : Seems like this shouldn't be Firefox-specific. Basically, it means, "we intend to implement this, but plz don't test it like implementing yet".
☝🏻 Sound fair?
| 16:01:52 |
ErichDonGubler | * jgraham: Okay, so, the actual set of values seems to be:
implementing : Anywhere from "is being implemented" to "we believe we have fully implemented this" for an agent; the intent is "yes please let's test this".
not-implementing : Agent is not planning on implementing this, please don't test it.
backlog : Seems like this shouldn't be Firefox-specific. Basically, it means, "we intend to implement this, but plz don't test it like implementing yet".
☝🏻 Sound fair?
| 16:01:59 |
annevk | jgraham: thanks, I guess I might also have to ask for admin merge when the time comes. Though maybe I should double check those CI results or try it again first... | 16:26:34 |