User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 The summary says it all, actually. See example URL. Same behavior on the following systems: Mozilla 1.4.3 Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.4.3) Gecko/20040909 Firefox 1.0 MOzilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Mozilla 1.7.1 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616 Reproducible: Always Steps to Reproduce: Visit the example URL. Actual Results: Unicode BOM (displayed as ï»¿) is shown on the page. Expected Results: The BOM should not be displayed.
On second thought, probably the problem is on my end -- Firefox doesn't recognize the document as UTF-8 although it is specified in <meta>, when encoding is changed manually the BOM disappears. Maybe Apache serves conflicting document encoding? Anyway this is not a Mozilla bug, marking as WORKSFORME.
(In reply to comment #1) > Maybe Apache serves conflicting document encoding? Yes it looks like it, the server is sending: Content-Type: text/html; charset=ISO-8859-1 Which overrules the meta.
For the time being, the server for that page does not send out any HTTP header that includes encoding information. Hence, Firefox relies 100% on the UTF-8 Byte order mark. (In reply to comment #1) For the encoding, then the BOM should take have higher priority than the HTTP header. See: http://malform.no/testing/html5/bom/ http://www.w3.org/Bugs/Public/show_bug.cgi?id=12897 http://www.w3.org/TR/xml/#sec-guessing-with-ext-info Therefore, you were originally correct when you complained: the BOM should not be displayed!