Created attachment 560537 [details] trav2.html User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Build ID: 20110902133214 Steps to reproduce: I was testing functions and some alerts appears twice. Then I built a minimal bug proof All the addons had been disabled for the test. Actual results: if the script grows with few chars ( add some = ) , the alert is called twice. I the script goes under 1024 bytes approximatively the alert is normally called one time. The test needs the presence of one international char , here the not encoded one in the place of X in paramXtres Expected results: The alert must be called one time
The test html is not specified charset. so browser parsed twice to detect char encoding.
(In reply to Alice0775 White from comment #1) > The test html is not specified charset. > so browser parsed twice to detect char encoding. You are right. But other navigators run this kind of pages only one time. This unexpected second run might have bad consequences in certain cases.
> But other navigators run this kind of pages only one time. It really depends on the page and the heuristics used. In general, pages that don't include a charset declaration and end up being autodetected _will_ be executed twice in browsers....
Considering that the only texts calculated before the 1st international char are ascii , I don't know if it is useful to run the page again. Even if some texts needs to be converted, they are directly accessible through the first dom tree being built If there is a second not explicite charset , there is no general issue even when reloading.
This page isn't parsed twice with the default settings of Firefox for the French locale (the page contains some French in a comment) or English. It may end up parsed twice with the default settings for CJK or Cyrillic locales. There are various conflicting considerations here. There are tradeoffs. They have been carefully considered. If you are the Web author responsible for the page, the short answer is that you should declare the character encoding in the HTTP header or in a <meta> within the first 1024 bytes to avoid issues like this.
I use a standard installation of windows 7 and firefox for France. In fact, this doesn't affect me while I use headers. It was just a feedback bacause other browsers don't run twice. Thanks.
(In reply to sav123 from comment #6) > I use a standard installation of windows 7 and firefox for France. Are you sure you haven't enabled character encoding auto-detection yourself? The fr locale ships with it off by default: http://mxr.mozilla.org/l10n-central/source/fr/toolkit/chrome/global/intl.properties
There are the datas : general.useragent.locale=fr - pluralRule=2 - intl.accept_languages=fr, fr-fr, en-us, en - intl.charsetmenu.browser.static=ISO-8859-1, UTF-8 - intl.charset.default=ISO-8859-1 - intl.charset.detector= is mailedit used ? - intl.charsetmenu.mailedit=ISO-8859-1, ISO-8859-15, ISO-8859-6, armscii-8, geostd8, ISO-8859-13, ISO-8859-14, ISO-8859-2, GB2312, GB18030, Big5, KOI8-R, windows-1251, KOI8-U, ISO-8859-7, ISO-8859-8-I, windows-1255, ISO-2022-JP, EUC-KR, ISO-8859-10, ISO-8859-3, TIS-620, ISO-8859-9, UTF-8, VISCII
(In reply to sav123 from comment #8) > - intl.charset.detector= Is this what about:config shows you?
(In reply to sav123 from comment #8) > is mailedit used ? It shouldn't be relevant to the behavior here.
yes detector is empty
(In reply to sav123 from comment #11) > yes detector is empty Interesting. In that case, I'd be interested in more specific steps to reproduce. The reparsing is only supposed to be able to happen if there's a late <meta> (which the test case doesn't have) or if the detector is enabled.