PDT+ Netscape French Home page keeps on loading without finishing

VERIFIED FIXED in mozilla0.9.3



18 years ago
18 years ago


(Reporter: momoi, Assigned: shanjian)


Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+], URL)


(1 attachment)



18 years ago
** 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.


18 years ago
Keywords: nsBranch

Comment 1

18 years ago
Daniel, has your team seen this problem?

Comment 2

18 years ago
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

Comment 3

18 years ago
Hmmm... I can't reproduce this in a windows 2K build from about an hour back.

Comment 4

18 years ago
It seems that when JavaScript is turned off for Navigator,
the problem does not happen.

Comment 5

18 years ago
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.

Comment 6

18 years ago
Have javascript switched on, flushed out the cache but still no reproduce.

Comment 7

18 years ago
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.

Comment 8

18 years ago
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

Comment 9

18 years ago
Maybe this is a known bug?

Comment 10

18 years ago
yikes! this encoding thing is biting us in more than one ways... ccing vidur.

Comment 11

18 years ago
Changed component to i18n.
Component: Layout → Internationalization

Comment 12

18 years ago
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.

Comment 13

18 years ago
Maybe this is related to Bug 81253?

Comment 14

18 years ago
There is also bug 84707 where bugzilla bug list reloads forever when auto
charset detection is set.

Comment 15

18 years ago
>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.

Comment 16

18 years ago
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 ***
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 17

18 years ago
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. 
Resolution: DUPLICATE → ---

Comment 18

18 years ago
*** Bug 84704 has been marked as a duplicate of this bug. ***

Comment 19

18 years ago
It could be related to my check in (for rpotts) at 6/21 for bug 82244. 

Comment 20

18 years ago
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.

Comment 21

18 years ago
I am rebuild my build and will debug it ASAP
Target Milestone: --- → mozilla0.9.3
This would be a stop ship in my book.
Keywords: nsbeta1

Comment 23

18 years ago
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.

Comment 24

18 years ago
on Linux: WORKSFORME on my 2001-06-28 build

Comment 25

18 years ago
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.

Comment 26

18 years ago
change to P1
Priority: -- → P1

Comment 27

18 years ago
need to back out 78229 to fix this. 
Whiteboard: back out 78229 can fix this.

Comment 28

18 years ago
I bake out 78229, but I can still reproduce this problem

Comment 29

18 years ago
>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

Comment 30

18 years ago
PDT+ per pdt meeting.
Summary: Netscape French Home page keeps on loading without finishing → PDT+ Netscape French Home page keeps on loading without finishing

Comment 31

18 years ago
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
Whiteboard: back out 78229 can fix this.

Comment 32

18 years ago
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?

Comment 33

18 years ago
Tested on the branch July 2nd builds under Mac OS 9 (2001070203) and Windows ME
(2001070203). Page appears to load fine without problems.

Comment 34

18 years ago
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?

Comment 35

18 years ago
marking pdt+ as per Friday's PDT meeting
Whiteboard: [PDT+]

Comment 36

18 years ago
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)
 599 jaggernaut 1.535         
 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(), 
 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
Whiteboard: [PDT+]

Comment 37

18 years ago
>I back out 78229, it still not working.

I made some mistake while back out your 78229. I will try again now.

Comment 38

18 years ago
Put [PDT+] back to whiteboard. I accidentally remove it in my previous comment. 
Whiteboard: [PDT+]

Comment 39

18 years ago
shanjian- is your origional change in LoadDocument or ReloadDocument
It seem your 1.530 check in is in ReloadDocument (see
) 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.

Comment 40

18 years ago
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.

Comment 41

18 years ago
Created attachment 40948 [details] [diff] [review]
patch which back out 78229

Comment 42

18 years ago

Comment 43

18 years ago

Comment 44

18 years ago
checked into both branch and trunk. mark it closed.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 45

18 years ago
Marking verified in the 20010716 Branch builds. Tested Linux RedHat 7.1, Mac OS
9, and Windows ME.
You need to log in before you can comment on or make changes to this bug.