Microsoft Edge does not receive callbacks while connection succeded

[Pedrozena]

Apparently, the event "connect" is never fired while using mqtt.js with microsoft Edge (25.10586.0.0).
From my tests, the broker states that the Microsoft Edge client is correctly connected, but this information does not get intercepted by the callback function attached to the event "connect" (as it correctly happen using Firefox or Chrome)

[mcollina]

You are possibly in the best position to fix this, I have access to a win
10 box, but I will have no time for the next 3 weeks :/. Maybe @sandro-k?
Il giorno lun 29 feb 2016 alle 13:38 Pedrozena notifications@github.com
ha scritto:

Apparently, the event "connect" is never fired while using mqtt.js with
microsoft Edge (25.10586.0.0).
From my tests, the broker states that the Microsoft Edge client is
correctly connected, but this information does not get intercepted by the
callback function attached to the event "connect" (as it correctly happen
using Firefox or Chrome)

—
Reply to this email directly or view it on GitHub
#389.

[sandro-k]

I can have a look, but I only have the issue on IE10, Edge works fine.

[Pedrozena]

@sandro-k I got it working properly in IE11..

[seriousme]

I have the same issue, it works fine in Chrome and IE11, but the "connect" event is not picked up by Edge (version 10586.0.0)
Broker (Mosca ;-)) shows the the client timing out:

{"name":"mosca","hostname":"Mypc","pid":1460,"client":"mqttjs_77d2c9cd", "level":30,"msg":"client connected","time":"2016-03-29T16:46:57.729Z","v":0}
{"name":"mosca","hostname":"Mypc","pid":1460,"client":"mqttjs_77d2c9cd","level":30,"msg":"keepalive timeout","time":"2016-03-29T16:47:12.731Z","v":0}
{"name":"mosca","hostname":"Mypc","pid":1460,"client":"mqttjs_77d2c9cd","level":30,"msg":"closed","time":"2016-03-29T16:47:12.731Z","v":0}

[RangerMauve]

Seems like it'd be an error in websocket-stream

[mcollina]

Might be. Can you reproduce just using websocket-stream?

[RangerMauve]

@mcollina We're currently looking into this on my end, will update when we figure out what's wrong. So far it looks like onReady in websocket-stream isn't being invoked for some reason.

[seriousme]

Just looked at the webtests of Edge and they only seem to support:

var events = ['open', 'message', 'error', 'close'];

Looking for the standard on the W3C site I end up here
Which also specifies exactly these 4 events.

edit: please ignore me, I was looking for the onready event, but onready is attached to the open event..

[mcollina]

So, have we got any clue?

[RangerMauve]

@mcollina Had to put this on hold for now because other stuff came up which was more urgent than supporting Edge. Will post here when we get back to it.

[seriousme]

FYI: I tested using the recommended client test of websocket stream and onReady is being called in Edge.

[seriousme]

Looking at Mosca's log it keeps on going through the same cycle:
connect, timeout, close, connect etc..

Tracing in my app shows that onReady is also being called over and over.
However in the this.connected = true; in mqttjs is never reached.

[seriousme]

The websocket session itself is still up, because when I shut mosca down I get an error in Edge that I don't get during the connection cycle. If people have ideas what to check I'm happy to test, but for now I'm a bit lost. It looks to me as if a handshake fails or a timer expires to soon. Btw: I'm using http and ws, no https nor wss.

[seriousme]

I have enabled debug in MQTT.js by providing console.log as debug function.
The result: after ondata Chrome receives its mqttclient connect event, but Edge just continues trying to read.

pipe count=%d opts=%j
resume
resume read 0
read
need readable
length less than watermark
do read
flow
read
need readable
length less than watermark
reading or ended
< onmessage received event >
ondata
<now Chrome receives mqttclient connect event, Edge does receive that event>
read
need readable
length less than watermark
do read
emitReadable
emit readable
flow
read
onend
onfinish
unpipe
onunpipe
cleanup
pipe count=%d opts=%j
<cycle starts again>

[seriousme]

Ok, seems we can rule readable stream out as causing the problem as readable stream is now certified on Edge

[seriousme]

By accident I stumbled across mows.
I installed mows using NPM and used browserify to build mows.js per instructions in the readme.md

Doing a comparison between mows and mqttjs using the script below shows that in Chrome both get a connection an in Edge only mows gets a connection.

@mcollina do you have any clue ?

var mowsClient = mows.createClient("ws://test.mosquitto.org:8080/mqtt");
var mqttClient = mqtt.connect("ws://test.mosquitto.org:8080/mqtt");

// setup the MQTT listener for connect messages
mowsClient.on("connect", function(){
    console.log("MOWS received connect");
});

mqttClient.on("connect", function(){
    console.log("MQTT received connect");
});

[mcollina]

So, Mows uses a different version of MQTT.js and websocket-stream. So the
problem is between these two modules
Il giorno ven 8 apr 2016 alle 20:15 Hans Klunder notifications@github.com
ha scritto:

By accident I stumbled across mows https://github.com/mcollina/mows.
I installed mows using NPM and used browserify to build mows.js per
instructions in the readme.md

Doing a comparison between mows and mqttjs using the script below shows
that in Chrome both get a connection an in Edge only mows gets a connection.

@mcollina https://github.com/mcollina do you have any clue ?

var mowsClient = mows.createClient("ws://test.mosquitto.org:8080/mqtt");
var mqttClient = mqtt.connect("ws://test.mosquitto.org:8080/mqtt");

// setup the MQTT listener for connect messages
mowsClient.on("connect", function(){
console.log("MOWS received connect");
});

mqttClient.on("connect", function(){
console.log("MQTT received connect");
});

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#389 (comment)

[seriousme]

Can't say that is a surprise to me.
I was hoping that the difference in approach between the old and the newer version of mqtt.js would have triggered any light bulbs, but apparently not.

While debugging I get a bit lost in all the streams fluf, so a little guidance or help would be much appreciated.

[mcollina]

Ahum, the browser unit tests are passing on Edge without issues (just tested). What can it be?

[seriousme]

I might be way off here, but I used Esprima to add tracing for all calls and then diffed the result.

The difference starts after the "data" event has been emitted and ondata has been called.
First difference is Buffer.prototype.slice which behaves apparently different in Edge and Chrome.
(typedbuffer support as far as I can see)

Then Buffer._augment is being called.
Chrome calls _augment with a single byte (arr == "0":32) first and then adds more data later, Edge calls _augment with 4 bytes at once (arr == {"0":32,"1":2,"2":0,"3":0} )
Then in _parseLength Chrome ends up with this.packet.length == 2 where Edge ends with this.packet.length == 32 which might explain why Edge is waiting for more data.

Edit: I have put the relevant parts of the traces in a gist

[seriousme]

Ok, I think I got it:
In parseHeader the first byte should be sliced from the buffer.
So when the buffer is [32,2,0,0] then after the parseHeader the buffer should be [2,0,0] which it is in Chrome, however in edge its still [32,2,0,0] :-(.

The problem can be reduced to Buffer.prototype.slice.
Before and after the slice the buffer still holds the same data.

Must be a bug in typed array handling using the subarray function.
I'll try to isolate the issue later tonight.

[seriousme]

Got the answer: feross/buffer#86
Its a weird combination of buffers, typed arrays, browserify and edge.

The quick fix for me is to define globally:

var TYPED_ARRAY_SUPPORT=false;

Which ensures Buffers won't use typed arrays.

[seriousme]

Hm, too quick..
With var TYPED_ARRAY_SUPPORT=false; the connect works, but the subscribe fails (even in Chrome :-( )

It ain't over till the fat lady sings..

[mcollina]

Regarding the issue above, which version of browserify did you use to create the bundle?

[RangerMauve]

@mcollina I've got it happening on 10.2.6

[seriousme]

Just reinstalled browserify 13 and after that rebuild my node_modules of the app that uses mosca.

[mcollina]

I've just run the browser unit tests on Edge, and they pass using the latest zuul (which uses Browserify 13).
Does that build work for you? Is it an issue with Mosca (requires a browserify bump?)

[RangerMauve]

I'm not using Mosca for this, so I'm assuming it's a client-side problem. Sadly, can't test the new browserify version just yet.

[seriousme]

Works !
I rebuild node_modules/mosca/public/mqtt.js using :

browserify mqtt.js --standalone mqtt > ../mosca/public/mqtt.js

and the app subscribes to queues and is picking up published messages, even in Edge ;-)

Thanks for all the fine work !

[mcollina]

Happy we cracked this!