Sunday 26 July 2015

Chrome Native Messaging Sucks

So time for something more programming-y.

I've recently been working on a Chrome Native Messaging Host program to run for a client's chrome extension. This has proven to be a minefield of problems.

First of all, I could get it to output to the extension but not the correct output from the functions it was performing on the native host. Then, I could do half of each essentially. Now I'm in the wonderful spot of having fixed the functionality of the program but being unable to get it to send data to the plugin anymore. And I've come to a realisation about how I work as a result...

This is extremely annoying because there's no easy way for me to visualise the process.

As strange as it may sound, I visualise everything I do in order to get a grasp on what moving parts there need to be and what needs to interact with what - this is likely a more common thing than just myself I'm sure, but it strikes me as odd that I've ended up being a very visual person.

Essentially the process of Chrome Native Messaging is that you preface each message with a 4-byte representation of the message length, then the message itself. This was fine and easy to do, until now apparently. I'm not even sure I'm using the wrong code, but commenting out my entire application other than sending a test message still doesn't work, so I've been able to narrow the problem down to the actual sending message function, as below.

void SendReply(string messageToSend){    unsigned int messageSize = messageToSend.length();    cout << char(((messageSize>>0) & 0xFF));    cout << char(((messageSize>>8) & 0xFF));    cout << char(((messageSize>>16) & 0xFF));    cout << char(((messageSize>>24) & 0xFF));
    cout << messageToSend.c_str();

}
This is of course after setting
_setmode( _fileno( stdout ), _O_BINARY );

So it's giving the correct output format. Somehow, this just straight up doesn't send any messages to the Native Host, and I've got no idea why. Sending a message without the size bytes preceding it causes errors in the plugin, so the messages are being received when they're incorrect. "So this must be a lpugin error" I hear you say! Well I suppose it may be:

        port = chrome.runtime.connectNative('com.blinddevelopment.cobra');
        port.onMessage.addListener(function(msg) {
           alert("Received: " + JSON.stringify(msg));
});
        port.onDisconnect.addListener(function() {
            port = null;
            alert(chrome.runtime.lastError.message);
        });

I'm unsure if I could make it simpler if I tried. Now I'm sure this is going to end up being something obvious and easy to fix, and that's fine - one of the reasons I love programming in fact - I know for a fact this is my mistake and it's entirely on me to fix it and learn why it's broken. And I love doing that. But the frustration here doesn't come from the bug itself, it comes from the alck of visualisation.

I have no good way to know what's going on here, and why it's going wrong. If the end point isn't receiving a message to even display to me, and the start point is giving the message in binary format, that's one hell of a difficult task interpreting what I'm meant to be doing here and how I'm meant to fix it. Thereis no easy string output or variable checking - the program is running all of its functions correctly as they're menat to be run according the code, I'm just obviously not doing it correctly.

Back to work now I suppose, maybe it'll suddenly click and make sense to me. 

No comments:

Post a Comment