The check for websocket transport fails

[jayarjo]

Describe the bug

This check returns false for me every time in the latest Chrome, which I suppose should have full support for websocket transport? I'm still not sure what exactly is happening 'cause it doesn't make any sense. When I run the same check manually in debug console of VScode or Chrome console it always returns true. But somehow it is always false when run by socket.io that is bundled into the app that I'm working on. I had hard time tracing it down, but even when I found a culprit I don't understand what is happening.

To Reproduce

To be honest I have no idea how to reproduce it. 'Cause when I'm creating a codesandbox out of it, it just works, so I believe it has something to do with my app that causes that, but I'm not sure what. Maybe you can suggest where to look?

What is this check checking for exactly?

  check() {
    return (
      !!WebSocket &&
      !("__initialize" in WebSocket && this.name === WS.prototype.name)
    );
  }

Engine.IO server version: 6.2.1

I'm attaching a recording, 'cause I wouldn't believe in this nonsense myself if I weren't witnessing it.

[jayarjo]

I've split the check into parts and it seems "__initialize" in WebSocket is the part that makes it fail by returning true, while from what I understand it is expected to return false.

Again what is this part checking for exactly?

[jayarjo]

By dropping that check, I can now confirm, that everything works fine - connection established, socket.io functioning - all fine. So 🤷

[jayarjo]

Is this where __initialize is coming from - flashsocket from dark ages of the web? I'd assume that you are keeping it for backward compatibility... but why would it be true in my env? And how it can be false when I check it manually from console?

[jayarjo]

The reason for it to be true seems that "__initialize" in WebSocket condition gets compiled to true by CRA, at least for a dev server:

I still have no idea though what might be causing this.

[darrachequesne]

Hi! @jayarjo thanks a lot for the detailed analysis 👍

You are right, it seems to be linked to flashsocket: dbc65f3

We should be able to simplify the check.

Related: socketio/socket.io-client#1537

[jayarjo]

@darrachequesne this is a very tricky problem - almost from the category of "aliens" or "cosmic rays". Not only the root cause is not obvious, but also with source maps enabled, it is basically invisible. One has to inspect compiled bundle to actually see it, which I bet not everybody would do, so majority of people would simply pass on socket.io instead. It has to be addressed somehow.

[darrachequesne]

This should be fixed by f158c8e, included in engine.io-client@6.2.2. Again, thanks a lot for your work on this ❤️