twice page calculation in certain conditions.




HTML: Parser
6 years ago
6 years ago


(Reporter: sav123, Unassigned)


6 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
Created attachment 560537 [details]

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

Comment 1

6 years ago
The test html is not specified charset.
so browser parsed twice to detect char encoding.
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → parser

Comment 2

6 years ago
(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....

Comment 4

6 years ago
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.
Attachment #560537 - Attachment mime type: text/plain → text/html
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.
Last Resolved: 6 years ago
Resolution: --- → WONTFIX

Comment 6

6 years ago
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:

Comment 8

6 years ago
There are the datas :
- 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.

Comment 11

6 years ago
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.
You need to log in before you can comment on or make changes to this bug.