Last Comment Bug 87413 - PDT+ Netscape French Home page keeps on loading without finishing
: PDT+ Netscape French Home page keeps on loading without finishing
Status: VERIFIED FIXED
[PDT+]
:
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: x86 Windows 2000
: P1 critical (vote)
: mozilla0.9.3
Assigned To: Shanjian Li
: Chris Petersen
Mentors:
http://www.netscape.fr/
: 84704 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-23 01:55 PDT by Katsuhiko Momoi
Modified: 2001-07-16 14:27 PDT (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch which back out 78229 (868 bytes, patch)
2001-07-02 15:09 PDT, Frank Tang
no flags Details | Diff | Splinter Review

Description Katsuhiko Momoi 2001-06-23 01:55:44 PDT
** 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.
Comment 1 Katsuhiko Momoi 2001-06-23 02:00:22 PDT
Daniel, has your team seen this problem?
Comment 2 Junk_HbJ 2001-06-23 02:55:00 PDT
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 Gagan 2001-06-23 03:04:42 PDT
Hmmm... I can't reproduce this in a windows 2K build from about an hour back.
Comment 4 Katsuhiko Momoi 2001-06-23 03:08:09 PDT
It seems that when JavaScript is turned off for Navigator,
the problem does not happen.
Comment 5 Katsuhiko Momoi 2001-06-23 03:11:48 PDT
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 Gagan 2001-06-23 03:24:32 PDT
Have javascript switched on, flushed out the cache but still no reproduce.
Comment 7 Syd Logan 2001-06-23 03:27:32 PDT
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 Katsuhiko Momoi 2001-06-23 03:29:30 PDT
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.
Comment 9 Katsuhiko Momoi 2001-06-23 03:30:00 PDT
Maybe this is a known bug?
Comment 10 Gagan 2001-06-23 03:32:43 PDT
yikes! this encoding thing is biting us in more than one ways... ccing vidur.
Comment 11 Katsuhiko Momoi 2001-06-23 03:52:07 PDT
Changed component to i18n.
Comment 12 Katsuhiko Momoi 2001-06-23 04:04:02 PDT
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 Katsuhiko Momoi 2001-06-23 04:06:22 PDT
Maybe this is related to Bug 81253?
Comment 14 Gilles Durys 2001-06-23 11:51:28 PDT
There is also bug 84707 where bugzilla bug list reloads forever when auto
charset detection is set.
Comment 15 Katsuhiko Momoi 2001-06-23 12:46:30 PDT
>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 Mike Young 2001-06-23 12:59:06 PDT
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 ***
Comment 17 Katsuhiko Momoi 2001-06-23 13:33:24 PDT
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. 
Comment 18 Frank Tang 2001-06-25 12:23:48 PDT
*** Bug 84704 has been marked as a duplicate of this bug. ***
Comment 19 Frank Tang 2001-06-25 12:26:00 PDT
It could be related to my check in (for rpotts) at 6/21 for bug 82244. 
Comment 20 Katsuhiko Momoi 2001-06-25 12:30:26 PDT
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 Frank Tang 2001-06-25 12:31:34 PDT
I am rebuild my build and will debug it ASAP
Comment 22 Jaime Rodriguez, Jr. 2001-06-26 09:00:32 PDT
This would be a stop ship in my book.
Comment 23 Katsuhiko Momoi 2001-06-27 01:56:01 PDT
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 kill this account 2001-06-28 14:40:49 PDT
on Linux: WORKSFORME on my 2001-06-28 build
Comment 25 Shanjian Li 2001-06-28 14:45:55 PDT
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 Frank Tang 2001-06-28 15:04:08 PDT
change to P1
Comment 27 Frank Tang 2001-06-28 16:56:55 PDT
need to back out 78229 to fix this. 
Comment 28 Frank Tang 2001-06-29 15:19:11 PDT
I bake out 78229, but I can still reproduce this problem
Comment 29 Frank Tang 2001-06-29 15:21:03 PDT
>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.
Comment 30 Frank Tang 2001-06-29 16:41:30 PDT
PDT+ per pdt meeting.
Comment 31 Frank Tang 2001-06-29 17:19:09 PDT
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. 
Comment 32 Shanjian Li 2001-06-29 17:47:16 PDT
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 Chris Petersen 2001-07-02 11:35:04 PDT
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 Frank Tang 2001-07-02 14:02:56 PDT
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 msanz 2001-07-02 14:19:46 PDT
marking pdt+ as per Friday's PDT meeting
Comment 36 Shanjian Li 2001-07-02 14:33:16 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. 
Comment 37 Frank Tang 2001-07-02 14:35:41 PDT
>I back out 78229, it still not working.

I made some mistake while back out your 78229. I will try again now.
Comment 38 Shanjian Li 2001-07-02 14:36:10 PDT
Put [PDT+] back to whiteboard. I accidentally remove it in my previous comment. 
Comment 39 Frank Tang 2001-07-02 14:47:33 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.
Comment 40 Frank Tang 2001-07-02 14:50:25 PDT
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 Frank Tang 2001-07-02 15:09:38 PDT
Created attachment 40948 [details] [diff] [review]
patch which back out 78229
Comment 42 Shanjian Li 2001-07-02 15:12:45 PDT
r=shanjian@netscape.com
Comment 43 Simon Fraser 2001-07-02 15:22:15 PDT
sr=sfraser
Comment 44 Frank Tang 2001-07-02 15:40:18 PDT
checked into both branch and trunk. mark it closed.
Comment 45 Chris Petersen 2001-07-16 14:27:32 PDT
Marking verified in the 20010716 Branch builds. Tested Linux RedHat 7.1, Mac OS
9, and Windows ME.

Note You need to log in before you can comment on or make changes to this bug.