Avoid "x00" due to ShrinkSafe/browser bug #5027

[guest]

When doing a build, the compression step is inserting a null character [0x00] whenever it encounters x00 [0x5C 0x78 0x30 0x30].

This was found when doing a custom build that included the LinkDialog?.js, which includes the ValidationTextBox?.js. The ValidationTextBox?.js has "x00" in two places and in both places the character sequence [0x5C 0x78 0x30 0x30] is replaced with [0x00].

Manually removing the "x00" from ValidationTextBox?.js, performing the build, then manually adding the "x00" back to the compressed file works just fine.

This was not an issue in Dojo 0.9.0 and is new to 1.0.0.

http://download.dojotoolkit.org/release-1.0.0/dojo-release-1.0.0/dijit/form/ValidationTextBox.js

http://trac.dojotoolkit.org/browser/dijit/trunk/form/ValidationTextBox.js

This is quite repeatable as it was happening for tk on the dojotoolkit.org website.

[guest]

I should also note that the problem affects IE7 and probably all versions of IE. Firefox is smart enough to ignore the null characters.

[peller]

Looks like this may have been a regression caused by #4712. Just a wild guess, but replacing x00 with a null probably breaks certain browser impls which might use C-style zero terminated strings. Either way, it's probably best to avoid nulls in the middle of files?

Why x00 is used in that file is a separate question we need to address.

[doughays]

(In [11404]) References #5017. Change x00 to $_unset_$ for better compatibility with shrinksafe.

[peller]

(In [11416]) Remove null ref on 1.0 branch. Refs #5017

[peller]

So we should be clean now for 1.0.1, but should we also fix the tool to leave x00 alone?

[peller]

Made a new ticket to track the ShrinkSafe? issue: #5027

[bill]

(In [11857]) Fixes #5017: InlineEditBox? save button not disabled after pressing ESC to revert value

[bill]

Oops, above comment should have said #5107 for the bug number.