Closed
Bug 22203
Opened 25 years ago
Closed 24 years ago
Refreshing page after set Auto-detect
Categories
(Core :: Internationalization, defect, P3)
Core
Internationalization
Tracking
()
VERIFIED
WONTFIX
M18
People
(Reporter: teruko, Assigned: shanjian)
References
()
Details
(Whiteboard: [PDT-])
When you set Auto-detect menu and go to the non-meta or non-http charset page,
the page will be displayed as garbage at the first time then it will be reloaded
the page as correct character set.
Steps of reproduce
1. Launch Browser
2. Set Auto-detect to Japanese
3. Go to above URL
At the first time the page will be displayed as garbage. Then, it will be
reloaded. The user does not need to do anything.
Tested 121710 Linux, MAC and, 121712 Win32 build.
Summary: Refreshing page after set Auto-detect → Refreshing page after set Auto-detect
What seems to be happening: A beginning (small) portion of a page shows up very
briefly upon initial page loading and the charset is detected, reset and the page
gets reloaded with that to completion. If this is the way it's supposed to be,
this may be a correct behavior. ftang?
Yes, parser and layout will incrementally start laying out the page using the
current default. When the auto-detect determines the charset and it's
different from the default, it will cause the page to be reloaded. But unlike
4.x, will not need for the entire page to be loaded before doing a reload.
Frank, is this last part working now?
Comment 3•25 years ago
|
||
We should take this kind of bug more seriously. The process itself
may be an improvement over 4.x but on a slower connection, the effect
is that we show unreadble garbage to the user -- sometimes for a period
of longer than 2-3 seconds. I think this would constitute a bad user
experience.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M13
Updated•25 years ago
|
Target Milestone: M13 → M14
Comment 4•25 years ago
|
||
move to M14.
Reporter | ||
Comment 6•25 years ago
|
||
I put beta1 because this would constitute a bad user experience.
Keywords: beta1
Comment 8•25 years ago
|
||
I am not sure what I should do for this bug.
Whiteboard: [PDT+] → [PDT+]No estimation yet. Danger
Comment 10•25 years ago
|
||
When I had a chat with 14 Mozilla Users Japan members last
Sat., this phenomenon was raised as an annoying problem by
one of the participants.
Comment 11•25 years ago
|
||
This is annoying. But does this annoying enough that we have to stop the beta ?
Comment 12•25 years ago
|
||
I found a way to elimate the reload if the detection can conclude in the first
block it receive. I need to change
mozilla/htmlparser/src/nsParser.cpp (small changes. ask harishd review the
chanages post in http://warp/u/ftang/tmp/parserdiff.txt
mozilla/intl/chardet/public/nsICharsetDetectonAdaptor.h
mozilla/intl/chardet/src/nsDetectionAdaptor.cpp
mozilla/layout/html/document/src/nsHTMLDocument.cpp
I will ask nhotta to review the rest 3 files and check in Monday night.
Whiteboard: [PDT+]No estimation yet. Danger → [PDT+]fix in local tree. wait for code review.
Comment 13•25 years ago
|
||
bobj- ignore whatever the difficult I told you Friday. I find a good fix for
average cases.
Comment 14•25 years ago
|
||
Thanks for thinking about this and trying something different.
I looked at Win, Mac and Linux builds today. The severity
of th eproblem depends on the platform. The worst seems to be
Mac. The reloading stops a little bit after garbage shows
and then loads it correctly. But this is much more noticeable
on Mac right now -- probabyl because Mac is slower in general
in loading.
I looked at 4.7 and IE4.5 on the very same page (Yahoo Japan)
with the auro-detect on the same machine and the same network
connection, I did not see any garbage display though they both
seem to do a slight reload -- not all that noticeable.
So the noticeability of this problem seems to be Mozilla specific
though the reload code may be similar.
Comment 15•25 years ago
|
||
fix and check in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 16•25 years ago
|
||
I tested this in 2000022309 Win32, 2000022308 Mac and Linux build.
When I tested the above URL, http://www.yahoo.co.jp/, the page is not refreshed.
However, when I tested this in http://www.zdnet.co.jp, the page will be refresed.
steps of reproduce
1. Go to http://home.netscape.com/
2. Select menu View | Character Coding -> Auto Detect off
3. Select menu View | Character Coding -> Auto Detect (Japanese)
4. Go to http://www.zdnet.co.jp
The page is loaded top part of the page, but is displayed as garbage. It will be reloaded, then the page is displayed correctly.
I reopen this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 17•25 years ago
|
||
Works for me using build 2000022308 on US Win95.
Comment 18•25 years ago
|
||
I tried steps 1 to 4.
And also tried stesp 1 to 3 and then went to http://www.yahoo.co.jp/
Both cases worked for me.
Comment 19•25 years ago
|
||
I didn't complete fix the bug so it won't reload. I only fix it so it won't
reload if the detector figure out in the first block. We cannot completely
remove the reload code since it is possible all the text in a 20M byte document
is in ASCII except the last line. Mark this assing but I don't think the
remaining issue is PDT+
remove PDT+ from the status window since the scope of the bug change now.
Status: REOPENED → ASSIGNED
Whiteboard: [PDT+]fix in local tree. wait for code review.
Updated•25 years ago
|
Target Milestone: M14 → M15
Comment 22•24 years ago
|
||
I don't think we can do anything about this. reassign to shanjian for now anyway
Assignee: ftang → shanjian
Status: ASSIGNED → NEW
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 23•24 years ago
|
||
I do not think we can do anything about this. A better charset
detection module will reduce the chance of this from happening.
We will continue to improve the charset detection module.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•