Closed Bug 22203 Opened 25 years ago Closed 24 years ago

Refreshing page after set Auto-detect

Categories

(Core :: Internationalization, defect, P3)

defect

Tracking

()

VERIFIED WONTFIX

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?
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.
Status: NEW → ASSIGNED
Target Milestone: M13
Target Milestone: M13 → M14
move to M14.
*** Bug 23979 has been marked as a duplicate of this bug. ***
I put beta1 because this would constitute a bad user experience.
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
I am not sure what I should do for this bug.
Whiteboard: [PDT+] → [PDT+]No estimation yet. Danger
*** Bug 25077 has been marked as a duplicate of this bug. ***
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.
This is annoying. But does this annoying enough that we have to stop the beta ?
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.
bobj- ignore whatever the difficult I told you Friday. I find a good fix for average cases.
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.
fix and check in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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 → ---
Works for me using build 2000022308 on US Win95.
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.
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.
Putting on PDT- radar
Whiteboard: [PDT-]
Target Milestone: M14 → M15
M18
Target Milestone: M15 → M18
I don't think we can do anything about this. reassign to shanjian for now anyway
Assignee: ftang → shanjian
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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 ago24 years ago
Resolution: --- → WONTFIX
Verified as wonfix.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.