Skip to content

[css-paint-api] IDL for PaintWorkletGlobalScope is invalid #909

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lukebjerring opened this issue Jun 27, 2019 · 3 comments
Open

[css-paint-api] IDL for PaintWorkletGlobalScope is invalid #909

lukebjerring opened this issue Jun 27, 2019 · 3 comments

Comments

@lukebjerring
Copy link
Contributor

Related to #907

web-platform-tests/wpt#17551 introduces a test to catch this case, which causes /css/css-paint-api/idlharness.html in WPT to regress, e.g.
https://wpt.fyi/results/css/css-paint-api/idlharness.html?diff&filter=ADC&run_id=251400002&run_id=261060002

@majido
Copy link
Contributor

majido commented Jun 28, 2019

As far as I can tell and based on the follow up discussion in #907 the current PaintWorklet definition is correct.

[Exposed=Worklet]
interface WorkletGlobalScope {};

[Global=(Worklet,PaintWorklet),Exposed=PaintWorklet]
interface PaintWorkletGlobalScope : WorkletGlobalScope {}

This is because "Global" affects exposure sets which is what happens is these particular cases. See @tabatkins comment for more detail

You may want to adjust the idlharness test to make sure it does take this into account.

@lukebjerring
Copy link
Contributor Author

I think my confusion lies in the way that Worklet is used in idlharness; for Worker, it actually expands out into DedicatedWorker, ServiceWorker, etc.

https://github.com/web-platform-tests/wpt/blob/9e059910c901218756454b7979c6f95a6f306854/resources/idlharness.js#L704

@tabatkins Should we be doing the same thing with Worklet? Seems like the idlharness has a hard-coded list of the globals that are aliasing as Worker, which isn't very flexible, but I'm not sure how we would dynamically produce a list.

@tabatkins
Copy link
Member

Yes, it looks like this is a problem in the harness, where it's not using sufficient global knowledge to understand that PaintWorklet is a subset of Worklet.

The current structure of the Global attribute is... weird for its requirements. I think the correct way to tell is to globally collect all the things that advertise Global=PaintWorklet and all the things that advertise Global=Worklet, verify that the first is a subset of the second, and thus conclude that Exposed=PaintWorklet on a subclass is valid when the superclass is Exposed=Worklet.

(A better structure would probably be to have a more explicit "subclassing" of global names, so that you could declare, say, [Global=Worklet:Paint] and automatically be targeted by Exposed=Worklet and Exposed=Worklet:Paint, without having to do this global collection/intersection/etc. Different issue tho.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants