Skip to content
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

What is the right way of handling web handles? #151

Open
notgull opened this issue Sep 3, 2023 · 2 comments
Open

What is the right way of handling web handles? #151

notgull opened this issue Sep 3, 2023 · 2 comments

Comments

@notgull
Copy link
Member

notgull commented Sep 3, 2023

I just merged #134, which adds a new web handle type based on references to a JsValue. I opted to merge it now so we can migrate bikeshedding to a new thread.

Three strategies were proposed of having wasm-bindgen-based handles without using the data attribute ID hack:

  • Storing the internal idx u32 field that the JsValue is a wrapper around. While this approach is dependency free and compatible with the current WASM ABI, concerns were voiced that the new API introduced too many footguns, especially for smaller-scale use cases.
  • Storing the JsValue inline. This adds an optional dependency on wasm-bindgen and makes it so window handles can no longer be Copy.
  • Current: Store a pointer that is said to point to a JsValue through a reference. This, again, requires an optional dependency on wasm-bindgen, but makes the handles Copy.

Which strategy should we use to store web handles?

cc @madsmtm @grovesNL @daxpedda

@daxpedda
Copy link
Member

daxpedda commented Sep 3, 2023

As I mentioned before, I'm not familiar with RWH, but option 1. seems to me to contain no more footguns then all the other handles.

Generally speaking, unlike other handles, these Web handles will only work with wasm-bindgen, so I think it makes sense to depend on wasm-bindgen. The data attribute ID is the only wasm-bindgen independent handle I can think of (or any other attribute).

@grovesNL
Copy link
Contributor

grovesNL commented Sep 3, 2023

JsValue is the least surprising option for both producers and consumers, and matched what people are already doing when they pass canvases to graphics APIs. The original goal of raw-window-handle was to make it easier to pass window handles between crates, so trying to match natural usage patterns seems like the pragmatic solution.

Using WasmAbi or pointers adds complexity and requires unsafe implementations, so it's easier for people to make mistakes. We could obviously document requirements but these may fail in subtle ways when the canvas is attempted to be used by the graphics API (e.g. use-after-free), so it adds extra friction for people getting started.

We already agreed that Copy is probably not necessary for window handles, so it shouldn't be a strong argument in favour of either option.

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

No branches or pull requests

3 participants