Closed
Bug 687047
Opened 15 years ago
Closed 15 years ago
twice page calculation in certain conditions.
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: sav123, Unassigned)
Details
Attachments
(1 file)
|
1.00 KB,
text/html
|
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•15 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
(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.
Comment 3•15 years ago
|
||
> 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.
Updated•15 years ago
|
Attachment #560537 -
Attachment mime type: text/plain → text/html
Comment 5•15 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
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.
Comment 7•15 years ago
|
||
(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
Comment 9•15 years ago
|
||
(In reply to sav123 from comment #8)
> - intl.charset.detector=
Is this what about:config shows you?
Comment 10•15 years ago
|
||
(In reply to sav123 from comment #8)
> is mailedit used ?
It shouldn't be relevant to the behavior here.
| Reporter | ||
Comment 11•15 years ago
|
||
yes detector is empty
Comment 12•15 years ago
|
||
(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.
Description
•