Closed Bug 87413 Opened 24 years ago Closed 24 years ago

PDT+ Netscape French Home page keeps on loading without finishing

Categories

(Core :: Internationalization, defect, P1)

Product:
Core
Component:
Internationalization
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: momoi, Assigned: shanjian)

References

(
URL
)

Details

(Whiteboard: [PDT+])

Attachments

(1 file)

patch which back out 78229
868 bytes, patch
Details | Diff | Splinter Review
** Observed with 6/22/2001 Win 32 build, NS 6.1 PR1 build also ** When you visit the above page, Mozilla seems to reload the page again and again without finishing. This problem is not observed with NS 6.0 or NS 6.01. In terms of daily builds, last Win32 build I know of which does NOT have this problem is: 5/18/2001. The next build I have is from: 5/22/2001 and this build exhibits the same problem. I am not sure where this bug should go to. Maybe it belongs to networklib but I will begin with layout. I will begin with layout.
Keywords: nsBranch
Daniel, has your team seen this problem?
Wfm with 2001062204 / Win98SE and ISDN-Dialup-Connection. Disk + Memory cache disabled, Http-Pipelining disabled. "about:plugins" says: - Adobe Acrobat Plug-In Version 5.00 for Netscape - Default Plug-in
Hmmm... I can't reproduce this in a windows 2K build from about an hour back.
It seems that when JavaScript is turned off for Navigator, the problem does not happen.
Another thing I noticed is that even when JavaScript is turned on, if you somehow loaded the page before and if it still is not cleared from teh cache, it seems to load OK. But once you clear the cache, then the problme returns when JavaScript is on.
Have javascript switched on, flushed out the cache but still no reproduce.
Initial load works for me over a 56K dialup connection with the 6/23 21:57 Netscape commercial build. I'm also on Windows 2000.
Found the direct cause. This is probably an i18n problem. I have my Japanese encoding auto-detection on and that is when this problem occurs. View | Character Coding | Auto-Detect | Japanese When I turned it off, the problem disappeared. View | Character Coding | Auto-Detect | OFF I am sending this over to ftang.
Assignee: karnaze → ftang
Maybe this is a known bug?
yikes! this encoding thing is biting us in more than one ways... ccing vidur.
Changed component to i18n.
Component: Layout → Internationalization
Frank, this problem does not occur with 5/18 build even wit the JPN auto-detection on. The next build I have is from 5/22 and there the problem occurs. So loof for a change between these dates.
Maybe this is related to Bug 81253?
There is also bug 84707 where bugzilla bug list reloads forever when auto charset detection is set.
>There is also bug 84707 where bugzilla bug list > reloads forever when auto charset detection is set. I looked at this bug but I don't see any mention of Auto-Detect or Bugzilla list in it.
the bug from the comment above is 84704 and this bug is a duplicate of it. Marking as such... *** This bug has been marked as a duplicate of 84704 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
An outward symptom of Bug 84704 looks similar but there seem to be some differences. For example, this bug does not occur if Auto-Detect is set to ALL in Netscape NS 6.1 PR1. In the other bug, shanjian says that this occurs if auto-detect "anything" is set. The other bug involves one page handing over to another page. This one does not seem to though it has http meta-equiv "refresh" setting. These two may ultimately be due to the same cause, but for now I prefer to keep this one open until the cause is known precisely.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 84704 has been marked as a duplicate of this bug. ***
It could be related to my check in (for rpotts) at 6/21 for bug 82244.
I repeat my finding with past builds here: "Frank, this problem does not occur with 5/18 build even wit the JPN auto-detection on. The next build I have is from 5/22 and there the problem occurs. So loof for a change between these dates." The change which caus this problem occurred on or after 5/18/2001 and before 5/22/201.
I am rebuild my build and will debug it ASAP
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.3
This would be a stop ship in my book.
Keywords: nsbeta1
I should add a very interestig fact about this problem. I read in another bug report that location bar's manu URL entry + CR or Go button works if the history cache is cleared. 1. So I cleared Edit | Prefs | Navigator | History Cache. 2. Then I visited the French Home page with Japanese auto-detect ON and I had no problem! It loaded in one try. I tried this several more times and it loaded OK in one try. This is where it gets more interesting. 3. Since then I have been using the browser on and off for several hours -- presumably building history cache. I was not visiting the French Home page. 4. Now it is past midnight into the next day. So I try the French Home Page again. This time it takes 4-5 reloads to finish loading. I try a few more times each time re-starting browser but not clearing the cache or history cache. When I try more, I get the page to load again and again without finishing... These facts were observed with 6/26/2001 Win 32 Branch build.
on Linux: WORKSFORME on my 2001-06-28 build
I traced into the problem and found that this is a regression caused by my fix for bug 78229. In this page, meta tag also existing, but autodetection report the result first as win1252. Meta tag later marked this page as 8859, so 2nd reload is fired. However, somewhere else in the program things got screwed up and this charset hint is not passed to document loader. That leads to a endless loop. After I backed out that patch, bug 84704 also got fixed. Since our autodetection got improved, bug 78229 is not that serious anymore. We need to back out the patch and leave 78229 for future. Ftang, pls let me know what approval I need to backout the old patch from CVS. We probably want to do this for both trunk and branch if possible. This is really a serious problem.
change to P1
Priority: -- → P1
need to back out 78229 to fix this.
Whiteboard: back out 78229 can fix this.
I bake out 78229, but I can still reproduce this problem
>I bake out 78229, but I can still reproduce this problem I take this back. That is because the build get stop before I try it. I will try again.
PDT+ per pdt meeting.
Summary: Netscape French Home page keeps on loading without finishing → PDT+ Netscape French Home page keeps on loading without finishing
I back out 78229, it still not working. It keep looping. When you test, you need to clear out cache first. reassign back to shanjian. I already land 82244.
Assignee: ftang → shanjian
Status: ASSIGNED → NEW
Whiteboard: back out 78229 can fix this.
It works for me, I just tested. Before I backed out 78229, www.netscape.fr take several loop to finish. (It is not endless loop for me though. ) After I backed out 78229, it works without any loop. And testcase in 84704 is a endless loop before back out. That is a better testcase to indicate that changes in 7822g does make difference. Frank, could you ask someone else try it again?
Tested on the branch July 2nd builds under Mac OS 9 (2001070203) and Windows ME (2001070203). Page appears to load fine without problems.
shanjian, the code change a bit in that file nsWebShell.cpp I don't think there are a straight back out, can you post a diff to me?
marking pdt+ as per Friday's PDT meeting
Whiteboard: [PDT+]
chris, please also check Linux and win98. That seems the most problematic platforms for this bug. frank, I do not know who did the backout. The difference is either this line "if(eCharsetReloadRequested != mCharsetReloadState)" (line 601) in 599 jaggernaut 1.535 muDV->SetHintCharacterSet(NS_ConvertASCIItoUCS2(aCharset).get()); 600 buster 1.311 muDV->SetHintCharacterSetSource((PRInt32)aSource); 601 if(eCharsetReloadRequested != mCharsetReloadState) 602 { 603 mCharsetReloadState = eCharsetReloadRequested; 604 jaggernaut 1.535 LoadURI(NS_ConvertASCIItoUCS2(aURL).get(), LOAD_FLAGS_NONE); 605 buster 1.311 } 606 } exist or not. I checked both branch and trunk, and they all have been backed out. I could not find who did it in cvs log, It seems like my patch is suddenly missing.
Whiteboard: [PDT+]
>I back out 78229, it still not working. I made some mistake while back out your 78229. I will try again now.
Put [PDT+] back to whiteboard. I accidentally remove it in my previous comment.
Status: NEW → ASSIGNED
Whiteboard: [PDT+]
shanjian- is your origional change in LoadDocument or ReloadDocument It seem your 1.530 check in is in ReloadDocument (see http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=&subdir=mozilla/docshell/base&command=DIFF_FRAMESET&root=&file=nsWebShell.cpp&rev1=1.529&rev2=1.530 ) and what you copy past here is LoadDocument I do the correct backout of ReloadDocument, and it seems work fine. Also, we should be careful, the load flag changed.
Here is my reproduce procedure 1. open Mozilla or netscape 2. open preference, advance, cache 3. click both clear cache button twice to make sure cache is clear 4. select view:auto-detect to Japanese 5. in url bar, type "http://home.netscape.fr" and hit return you will see it keep reload You have clear out cache since we will remember charset in the cache. You have to set it to Japanese auto-detect (I am not sure about other value) This bug can only be reproduce while auto-detect is on.
sr=sfraser
checked into both branch and trunk. mark it closed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Marking verified in the 20010716 Branch builds. Tested Linux RedHat 7.1, Mac OS 9, and Windows ME.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: