IDLGenerators: Fix Exposed extended attribute codegen for interface parts
Hey this pr improves the IDL codegen a bit. I've added support for the Exposed extended attributes with the Window value for interface functions, attributes and stringifier items. This is used for example in the DOMMatrix and DOMMatrixReadonly interfaces. This fixes the following WPT tests:
- http://wpt.live/css/geometry/DOMMatrix-css-string.worker.html
- http://wpt.live/css/geometry/idlharness.any.worker.html
- And probably some more IDL harness tests
I've also moved some ExposedTo parsing code to LibIDL this is quite an ugly place to put that code but I can't put it in LibWeb because of circular dependencies.
Also are these changes quite limitted because it only extends for Window only exposed items that are explicitly not in the Worker global interface. But searching for [Exposed= this is currently in our codebase the only specific Exposed case.
Hope you like it :^)
Quick pre-review comment: Is this going to be straightforward to extend to functions/partial interfaces marked [SecureContext] ?
Quick pre-review comment: Is this going to be straightforward to extend to functions/partial interfaces marked
[SecureContext]?
Good point, I think we could you similar methods in the native objects initializers for secure contexts. The only big change needed is then to upcast the global object and get that secure context state information, don't know if that currently already exists in those objects.
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!
Nice work, this is also a requirement to make Workers not crash on WhatsApp, as it tries to access properties of performance.timing if it sees it exists, which is not valid in a Worker context. (Note that [Exposed=Window] haven't been added to these properties yet)
The main functional comment I have is that this needs to also be implemented for the default implementation of toJSON. For example, the timing and navigation properties shouldn't appear if JSON.stringify(performance) is ran in a Worker.
Thanks for the reminder that I've still this open pr. I will add the toJSON stuff you mentioned