GM_log and GM_xhr truncates at NULL byte

[xobofni]

Strings with NULL bytes are truncated at the NULL byte. In the script below, the output of GM_log is truncated but alert() is not.

// ==UserScript==
// @name GM_log stops on null byte
// @namespace http://a.www.com
// @description GM_log does not display parts of a string after a null byte.
// @include *
// ==/UserScript==

// only "null byte here" shows up in the log
GM_log("null byte here\0words after");

// the full text "null byte herewords after" shows up
alert("null byte here\0words after");

I'm also seeing this with GM_xmlhttpRequest when trying to POST binary data.

edit: This is with GM 0.8.20090920.2 and Firefox 3.5.5

[arantius]

I'd love to see an example of what you're talking about with XHR like with log.

[erikvold]

here is a patch to fix the issue for GM_log..

[erikvold]

I'm not sure this should be changed for GM_xhr, the string received from the userscript is passed along to a standard component, why should GM mess with the string and not the userscript?

[tim-smart]

If you look at the C++ source this behavior is expected. logStringMessage implements a nsConsoleMessage which is just a pointer to a unsigned short array ( http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsConsoleMessage.cpp#51 ). Throwing a null byte in your string will obviously be interpreted directly as a memory allocation delimiter.

I'm not sure if we want to protect the user from this or not, but I agree it is inconsistent with other ECMAScript API's. Maybe this should be filed upstream as well?

I suspect it is a similar case for GM_xmlhttpRequest... Does XMLHttpRequest follow suit?

[erikvold]

I suspect it is a similar case for GM_xmlhttpRequest... Does XMLHttpRequest follow suit?

GM_xhr is just feeding the values thru to XMLHttpRequest w/ a chrome principle, which I imagine works the same as w/ a page principle .