-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Use browser extension Port objects instead of hacky comlink string channel #10302
Conversation
Codecov Report
@@ Coverage Diff @@
## master #10302 +/- ##
=======================================
Coverage 44.38% 44.38%
=======================================
Files 1410 1410
Lines 77432 77432
Branches 6938 6938
=======================================
Hits 34372 34372
Misses 39839 39839
Partials 3221 3221
|
bb8ec17
to
149b202
Compare
401bcc3
to
a0e8ede
Compare
browserPortToMessagePort is called for both expose and proxy and needs to ignore the other, respectively.
a0e8ede
to
c462407
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good. Also tested locally, and works like a charm 🙂
I hope I am not forgetting a reason why we didn't do this in the first place (besides saving effort)
We didn't go down this route at the time because the string message adapter in comlink v3 didn't require it, so there was no reason to spend the effort 🙂
Co-authored-by: Loïc Guychard <loic@sourcegraph.com>
Co-authored-by: Loïc Guychard <loic@sourcegraph.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look good!
🎉 |
Comlink relies on creating
MessagePort
s for each proxied object and transferring those withpostMessage()
. But browser extensionPort
objects don't support transferringMessagePort
s (or anything really).Because of this, we used a hacky adapter that channeled every
MessagePort
through a singlePort
using string IDs (and serializing everything to a string, although that's not required).This string message adapter was a hacky addition to comlink v3 that "should have never made it to master" according to its creator, and is missing in v4. There is an experimental one in v4, but it is broken, and actually broke our browser extension (I thought I had tested this, but I must have made a mistake, maybe I had a prod browser extension running? 🤷♂️ Really wish we had tests for this in CI).
Because I couldn't get it fixed, I instead rethought our approach and worked on a solution that doesn't use a string wrapper. While
Port
s don't support transferables, it is possible to open multiple connections. How it works with this PR:Port
connections and map them by their name.MessagePort
in a message to be sent, we open aPort
to the other side with a UUID name.Port
the UUID and path at which theMessagePort
appeared.Port
up to aMessagePort
, and splice thatMessagePort
back into the message at the path it appeared.@lguychard I hope I am not forgetting a reason why we didn't do this in the first place (besides saving effort) 😅
Also would like to source the swarm intelligence to figure out where we need to add ensure resources are cleaned up and not leaked. Although I'm relatively sure we were leaking before - we're only using the new v4
[releaseProxy]()
as of this PR.Tested: