You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! I am using this great library in a chrome extension project which is going to support the chrome extension api manifest V3 soon as google is kinda enforcing it on all extension developers.
One of the main changes there is that instead of the current background service which runs in the background constantly and has access to the browser's window object, it is being replaced by a service worker API which has a limited window object (kinda like the window object but with less capabilities).
I think it would be great to think of other use cases in which you might consider limiting or somehow changing the use of window object.
Btw: I think that I might have a way to make it work and even kinda make it somewhat generic so it won't affect anyone who wants to use it as it is now.
Let me know if you would like me to open a PR with my idea 😀
Thanks!
The text was updated successfully, but these errors were encountered:
I like the idea, the code could simply check for the presence of a window object, and if not present, not try to do anything with it.
So, not sure if this can be handled without any alternative to the window object at all, cause we do need to use onunhandledrejection & onerror somehow.. Am I wrong?
What I'm proposing is maybe a little different. something in the form of: add another constructor signature which will have one argument, this will be the object that we would like to use as the replacement for the window object.
So for example, in my case when using service workers there is an object that is call globalThis which is like a "reduced" winodw object but with suffice attributes to be used in this case where we only use window for 2 events (onunhandledrejection & onerror) and the navigator & location attributes. so eventually it is up to the user of the library to pass the right override object for window.
And of course in the case there is nothing passed in the constructor arguments, it will result to the default object if it exists (the window).
Anyway, if you'd like to assign me this issue and I will submit a PR for review I would be glad to.
Hi! I am using this great library in a chrome extension project which is going to support the chrome extension api manifest V3 soon as google is kinda enforcing it on all extension developers.
One of the main changes there is that instead of the current background service which runs in the background constantly and has access to the browser's
window
object, it is being replaced by a service worker API which has a limited window object (kinda like thewindow
object but with less capabilities).I think it would be great to think of other use cases in which you might consider limiting or somehow changing the use of
window
object.Btw: I think that I might have a way to make it work and even kinda make it somewhat generic so it won't affect anyone who wants to use it as it is now.
Let me know if you would like me to open a PR with my idea 😀
Thanks!
The text was updated successfully, but these errors were encountered: