Some browsers like FireFox have a bug on the non-breaking space character (U+00A0, <b>&nbsp;</b> or <b>&#160;</b> or
<b>&#xA0;</b> in HTML).
They always convert the NBSP character to a normal space (U+0020, <b>&#x20;</b> in HTML) automatically in the following circumstances:
</p>
<ul>
<li>Copy text from the page</li>
<li>Use <b>innerHTML</b> to get the content of a certain element</li>
<li>Use <b>value</b> to get an <b>INPUT</b> element's value</li>
</ul>
<p>
You cannot read a real NBSP character from an <b>INPUT</b> element on these browsers. It causes issues when some formatting data in CLDR
contains an NBSP character. For example,
</p>
<ul>
<li>Many locales like French use an NBSP character as a group separator in numbers</li>
<li>French and Finnish use NBSP characters in their percentage and currency format patterns respectively</li>
<li>Russian uses NBSP characters in their date format pattern (see <ahref="test_validateDate.html">test_validateDate.html</a>)</li>
</ul>
<p>
So Dojo may generate formatted data with NBSP characters in it but cannot read NBSP charaters from user's input in some browser.
</p>
<h3class="testTitle"><aname="cmt_2">Issue #2<supstyle="color:blue">Fixed: the CLDR data generator should be fixed by adding code to convert U+200F to "\u200F" in nls JS files.</sup></a></h3>
<p>
Most Bidi currency symbols contain an LTR-MARK (U+200F) character at the very beginning.
But Firefox ignores it when it is not in any escaping form. This should be a bug of Firefox.
For example, click <ahref="javascript:alert(''.indexOf('\u200F'))"><code>alert(''.indexOf('\u+200F'))</code></a> (there is a U+200F in the empty-looking string):
</p>
<ul>
<li>In Firefox, shows "-1" -- no U+200F found</li>
<li>In IE & Opera, shows "0" -- the U+200F is found</li>
</ul>
<p>
But if the U+200F is in some escaping form, Firefox will work as well as other browsers.
Click <ahref="javascript:alert('\u200F'.indexOf('\u200F'))"><code>alert('\u200F'.indexOf('\u+200F'))</code></a> to see the same result both in Firefox and IE:
</p>
<h3class="testTitle"><aname="cmt_3">Issue #3<supstyle="color:blue">Fixed: added a "localeDigit" to the options</sup></a></h3>
<p>
Strictly speaking, the data conversion must support non-European number characters in some locales like Arabic and Hindi.
For example, ICU formats a number data into Indic number characters by default in the Arabic locale.
However, currently Dojo does not support this feature (Dojo uses the default number conversion of the browser).