On Thu Apr 4 14:53:03 2024 +0000, Gabriel Ivăncescu wrote:
Yeah. It's for the mshtml objects that have "async" props, like sessionStorage. By "async" I mean that the underlying props can pop in and out of existence at any point during script execution (of course we have tests for this but it's logical anyway), and we only know this at the time of lookup. Other such objects are, for instance, window or document (accessing elements as props), though those probably not as important as there's other ways of implementing it there. But yes, we'll need it for normal named props too. That said, what basically needs to be done in most cases is to "hook" it in a few places and override the behavior:
- At the start of `prop_get`.
- At the start of `delete_prop`.
- In `ensure_prop_name` at the end (we override the "definition" of a
new prop). 4. Same as above, at the start of `jsdisp_define_property` to override the definition of a new prop. 5. There's a couple other areas that might need special casing (finding a prop by hash/name, or in get_prop, or when enumerating), but at least get_prop is workable without special casing it, by adding another method to the prop desc vtbl or the object's. It will require a bit more changes to the vtbl and how it works, I didn't put it in this MR because I tried to keep it as simple as possible. But in short, I plan to do something like: override every method above, including named props, and return a different vtbl with methods having the "override" hook at the beginning, and later forward to normal named prop method. At least it would be workable without adding checks for such objects in the code.
Yeah, MSHTML bindings make it a lot more interesting. In fact, I think we should concentrate on getting that right first. If we have a good enough solution for arbitrary properties, it should be good enough for typed arrays too. The same is not true the other way around.
If we introduce an interface with such capabilities, it sounds to me like it should be able to handle builtin MSHTML properties too. Should we plan for that to be the same interface?