Fetch adapter

[AvivonCtrl]

Fetch instead of XHR for ServiceWorker compatibility

[gmuresan]

It looks like mixpanel no longer works in service workers for v3 chrome extensions. XHR has been deprecated/removed and fetch is now required. Are there any plan to migrate to fetch, or is there a workaround for service workers?

[juanfer0002]

Does anyone have an update about this?

[juanfer0002]

For whoever came here looking for answers, and found none, feel free to use this code.

I implemented fetch provisionally, while there's an official answer. I tested in development, and it is working so far.

[lukafilipov]

Thank you @juanfer0002 for adding this! It's funny how the library just silently stops working with manifest v3. @tdumitrescu any idea if/when the PR juanfer created will be reviewed and merged?

[juanfer0002]

@lukafilipov Since you're using this with the manifest v3, I have to warn you to be extremely careful when reporting to Mixpanel as service workers get shutdown by Chrome every five minutes.

This means that if you have identified a user, all events will be associated to them, but after 5m this identification will be lost, making every event not being correctly associated.

We had to implement a system to handle this situation, you may end up in a similar one.

[lukafilipov]

@juanfer0002 Got it, thanks for the heads up! And thanks again for the fix, I've tested it and it just works out of the box. I have referenced your branch directly from package.json like this:
"mixpanel-browser": "juanfer0002/mixpanel-js-mv3#fetch-support-for-mv3-extensions",

[spookyuser]

@juanfer0002 I love you

[aamirv]

Thank you for working on this @juanfer0002. I am wondering if you have encountered these issues (happy to talk privately -what's the best way to do that?):

1. you mentioned that this can get running with a service worker, but it will shut down. YES, and that causes Mixpanel to see the result as different users as a result, like you said. So I thought the best practice would be to send a message back to background.js and talk to mixpanel there. Is that right?
2. related to this idea - how are you getting it into background.js? I see references to document and window, so that doesn't work.

I get this error right now: "Uncaught TypeError: Cannot set property navigator of # which has only a getter". I can comment out the line, but not sure what that is really doing.

Did you consider shifting to the HTTP API? I'm wondering if using mixpanel is worth it.

For those working on Chrome extensions.... how are you doing user tracking to learn how they are using product?

(I kind of doubt this will get merged into the main - is that right @tdumitrescu or anyone at mixpanel?)

[spookyuser]

Take a look at this class @aamirv it helped me a lot, I don't think you have to run it in the background but idk, on plasmo I just made this class and imported it and everything's working so might be running in the background actually.

[juanfer0002]

@aamirv You can just import files in the background js with normal JS syntax, and then use it as an object. LMK if you need a more precise example, I am responding from my phone.

Regarding the other issue, when the SW shuts down, be aware that the callbacks and events are still being fired by Chrome when the port closes, in such a case I Just retry the connection with the service worker.

[rahulbansal16]

"mixpanel-browser": "juanfer0002/mixpanel-js-mv3#fetch-support-for-mv3-extensions",

so just updating the package.json file will work? No other code change require?

[gigabrain-kabir]

Is this expected to be added to a mixpanel-js release?

[neecto]

any updates on this? It's tagged as "enhancement" but it's really a bug that makes mixpanel-browser unusable in chrome extensions

[NorbertBodziony]

Seems like real issue right now