-
-
Notifications
You must be signed in to change notification settings - Fork 43
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
Bundling issues #27
Comments
I can imagine what's happening. Because each "bundle" per frame has it's own import of So this must also mean that each closure per frame is establishing a port connection with the background page under the same Before we look for a solution, can you confirm the latter thesis? |
Sorry, I ended up fixing this for myself by creating a separate bundle of only webext-bridge and injecting this bundle into each website. I will set up a new environment later today or tomorrow to debug this further |
I got the same issue here, And I think it should work only this way, no reason to include the library twice (or more). |
Just out of curiosity can you try installing |
I am experiencing this issue as well? @zikaari can you help me understand what a good solution might be? |
Hi vince, did you try |
@zikaari I did. I have a content script that gets injected from the manifest, which messages back to the bkg context to inject another content script. I see both ports connect in the logs of the bkg context but i still get the error:
If I do not inject the second script it works fine. It seems that once I inject the second content-scripts any reference or message to the original content-script breaks. I cannot message to it from the background context or other content scripts. It does still work if i message to itself. |
That is not a bundling issue. The reason you're seeing this error is that the second content script overrides the port registration with the background page, removing the bindings established by the previously loaded content script, which it appears does contain a listener for Unfortunately, I did not account for this scenario when I was designing the library, if you have ideas please feel free to share. |
@zikaari i'd have to dig into the internals of how ports get established and how it knows if a listener is on the other side. |
I finally updated my entire extension to use [email protected], and the problem is not solved. |
This is probably not an issue with the library itself, but maybe the issues described below can be solved at the library layer?
I currently use
webext-bridge
through vitesse-webext and I ran into some issues that took a few hours to get to the bottom of.At its core, the issue is that I have a manifest that looks like this:
All JS files mentioned above make use of
webext-bridge
and because I have a) a global bundle and b) per-website bundles, this causeswebext-bridge
to be present in two separate bundles. As a result, I was observing that I was running into scenarios where messages that were being sent by the background script would make it to the wrong bundle, which had no open transactions and thus led to the messages being dropped.Any elegant way to solve this at the library level? Or do I have to come up with some different bundling strategies to solve this?
The text was updated successfully, but these errors were encountered: