Closed Bug 87413 Opened 23 years ago Closed 23 years ago

PDT+ Netscape French Home page keeps on loading without finishing

Categories

(Core :: Internationalization, defect, P1)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: momoi, Assigned: shanjian)

References

()

Details

(Whiteboard: [PDT+])

Attachments

(1 file)

** 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: 23 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: 23 years ago23 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: