-
Notifications
You must be signed in to change notification settings - Fork 141
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
gloo-net: incorrect access of global when used in a worker #201
Comments
I have created a fairly ugly patch to make |
I wonder if a better solution would be to solve this at the wasm-bindgen level with a Alternatively we could have an enum Global {
Window(Window),
DedicatedWorkerGlobalScope(DedicatedWorkerGlobalScope),
ServiceWorkerGlobalScope(ServiceWorkerGlobalScope),
} which could again cover all the common APIs between these types. Perhaps @alexcrichton has some thoughts on this? |
Given how many contexts JS can run in I don't think that's a great idea for wasm-bindgen itself, but as a helper crate somewhere I think it definitely makes sense. |
Thanks for the attention to this issue. Perhaps a |
My intuition would be to say that it belongs to |
@cdata Thank you very much for your fork. I assume it's quite out of date now, but it still managed to resolve my issue. |
@Zageron I don't have time to look at it right now, but if you happen to rebase the change I will happily accept a PR from you 🍻 cheers! |
Describe the Bug
gloo-net
HTTP features cannot be used in a worker because the library always tries to access the Fetch API fromWindow
, which will fail when running in a worker:gloo/crates/net/src/http/mod.rs
Line 189 in 5fc0a8f
Steps to Reproduce
gloo-net
to make HTTP requestsExpected Behavior
Expected HTTP requests are made.
Actual Behavior
An error, as the library attempts to access the wrong kind of global.
Additional Context
In digging around, I noticed there is some relevant history from
gloo
contributors: rustwasm/wasm-bindgen#2148 (comment).Following that comment thread, I discovered that gloo previously incorporated a limited workaround for accessing global properties in a scope-agnostic way:
gloo/crates/timers/src/callback.rs
Lines 8 to 40 in 2c9e776
In some cases, it may feasible to take a simpler approach, such as this patch I applied to another crate that has this same issue: devashishdxt/rexie@8637e4e
The text was updated successfully, but these errors were encountered: