Add variants to exclude event timing targetSelector from Interop 2025

[canova]

This is related to: web-platform-tests/interop#1233
Corresponding WPT metadata change: web-platform-tests/wpt-metadata#8377

[canova]

cc @nt1m

[nt1m]

@canova I don't think that worked unfortunately, see the Firefox/Safari results at: https://github.com/web-platform-tests/wpt/pull/57039/checks?check_run_id=59674427618

I think the wildcard needs to be adjusted/removed, though I'm not sure how exactly.

[canova]

Oh welp, I just saw it. Lemme try some more things (I have to try in this PR, sorry about the pings in advance).

[mmocny]

I'll hold back the LGTM given that you are iterating, but I very much appreciate that you are helping get this resolved!

[canova]

Okay, after seeing both ?exclude=targetSelector and ?exclude=.*targetSelector.* didn't work, I was a suspicious and decided to do some local debugging. And found out that I was missing a script import for /common/subset-tests-by-key.js. Apparently this is the whole script that does the filtering. But even adding that didn't work, because apparently /common/subset-tests-by-key.js script only matches for the tests by their "key" and not the full test name string. So, for these tests, the keys are always PerformanceEventTiming, that's why we can't actually filter by targetSelector no matter what we put in the filter.

I guess we have a few options:

1. Update the /common/subset-tests-by-key.js script to also look at the full test string.
2. Add another script called subset-tests-by-name.js to match the test names.
3. ?? (I couldn't find another existing script in the repo, but there might be some solution that I couldn't see)
4. Just accept that it's not possible (without a lot of changes) and move on.

I would personally prefer option 2. I don't really like option 1 because it might be disruptive for the existing tests and I would prefer to keep the side-effects as minimal as possible. I'm happy to write a script that's similar to subset-tests-by-key.js that matches for the full test strings. But that's going to be a lot more changes. So I wanted to make sure you're also onboard with this.

cc @nt1m @mmocny

[mmocny]

I'd accept any solution. (1) seems least overhead/surprise long term TBH and just needs an audit that the changes don't do anything unexpected. I guess I defer the choices between (1) and (2) to others who understand the infra.

(I have no other suggestions for (3)).

---

As a last resort, what would (4) entail? Perhaps removing the idlharness from interop 2025 list or removing the IDL definition in the spec for a short while? Perhaps manually changing the idlharness test or just accepting that it looks like a fail in the dashboards?

[nt1m]

Maybe @jgraham, @gsnedders or @foolip have thoughts here