ladybird icon indicating copy to clipboard operation
ladybird copied to clipboard

IDLGenerators: Fix Exposed extended attribute codegen for interface parts

Open bplaat opened this issue 10 months ago • 3 comments

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 :^)

bplaat avatar Apr 30 '25 15:04 bplaat

Quick pre-review comment: Is this going to be straightforward to extend to functions/partial interfaces marked [SecureContext] ?

ADKaster avatar Apr 30 '25 16:04 ADKaster

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.

bplaat avatar Apr 30 '25 17:04 bplaat

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!

github-actions[bot] avatar May 27 '25 02:05 github-actions[bot]

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.

Lubrsi avatar Jun 12 '25 13:06 Lubrsi

Thanks for the reminder that I've still this open pr. I will add the toJSON stuff you mentioned

bplaat avatar Jun 12 '25 19:06 bplaat