** Observed with 4/28/99 Win32 build ** ftang enabled View | Character Set menu as of this new build. However, there is a big problem which prevents us from using this menu. This menu is primarily meant for pages which bear no meta tag charset info. 1. Got to the above URL. (You need to have a Japanese font on your system for this check.) 2. See that the page does not show in Japanese. 3. So, you try to change the menu to Japanese (iso-2022-jp). 4. Nothing changes and it is still unreadable as Japanese. In the command prompt window you see this error message: "error loading URL http://kaze:8000/jisnometa.html" This makes the use of Browser encoding menu pretty much useless. This is a promised internaitonal feature for M5.

If you like a Japanese font to see this problem, you can pick it up here: http://rocknroll/users/momoi/publish/Fonts/IEFonts/ the name of the font: ie3lpkja.exe Run this executable in your Windows and restart the system. 5.0 will know how to use it witthout you doing anything else to it.

Steve, figure out what's going on here and whose bug this really is ...

Putting on QA Blocker radar.

Since Steve is kind of busy ... can you look into this Bill?

Let me add a few more facts. 1. The failure to reload seems to happen on pages which generate an error of some kind. For example, the URL mentioned above has an image link but the image is missing from the server. I have another page which is otherwise identical to the problem URL, but this one does have all the images on the server and they load without an error. http://kaze:20020/jisnometa.html 2. We found another type of page: http://directory.netscape.com/World/Japanese Here the page has a meta tag with EUC-JP indication, but the font face says "Helvetica". For some reason this page causes a re-loading error also. So if it did not display correctly in Japanese upon first try, it will not display in Japanese no matter how times you try re-loading or encoding menu switch. It may be that we are not just reloading for a number of different error types. The effect of this, however, is that the encoding menu switch becomes non-functional on such pages. I have a feeling that there are quite a few pages which cause this type of errors.

I was unable to reproduce the problem with today's build (04/30). I installed the font, restarted, opened the page in apprunner, changed to the indicated charset/encoding, and it displayed properly (as best I can tell, since I don't read Japanese). You can view a screen shot of the resulting window at http://law.mcom.com/bug5665.jpg

I see that the page is loaded correctly from the picture. Using the same 4/30 build, I continue to have the same problem. One difference between your environment and mine (NT4) is that I have some additional fonts on my system, e.g. Bitstream Cyberbit 2.0. I'll eliminate that font from the list and see if that has any effect on the reload behavior.

I'm continuing to have this problem on my 2 NT4 machines with the latest build even after I removed Bitstream fonts. I may have a slightly different sets of fonts on my machines than law's, but nonetheless I get errors when I try to re-load. I have to re-open this. I'll be happy to show you the problem on my machines or I can come look at yours.

There are clearly certain machines which don't have this problem. erik was not able to reproduce this problem on his NT4-US, either. I'll look at other machines in our area if the problem is observed in them.

This is just a suggestion, but when I looked at the bug on momoi's machine, there was an error message like "Error loading URL". However, it didn't really say what was wrong. One approach to solve this problem might be to improve the error message so that you can see what went wrong.

As additional facts, I discovered that on my NT4-Japaese o where I have this problem, a very simple HTML page with no errors or even Japanese in it (just English sentences) fails to reload. For example, A. http://kaze:8000/reloaderror3e.html This page is a simple English page containing only several lines of text. This page fails to reload. I also found that the error message: error loading URL http://... appears on some pages like the Netscape English home page on reload ( i.e. click on the reload button or CR in the location window) while it does not fail on the Yahoo Enligsh home page. B. http://home.netscape.com/ C. http://www.yahoo,com/ However,the Netscape home page seems to load in reality even though there is this error message. For example, after you go to the Netscape Home Page (B), then load the Yahoo page (C), and then try to load the Netscape Home Page again, it succeeds or at least the Netscape page does get displayed. On the other hand, if you go to the page A above, then to Yahoo (C), and tries to load A again, it fails and the page displayed is still teh Yahoo page. I agree with erik that the error message is detailed enough.

What I meant above is that the current error message is not detailed enough for this type of problem.

OK, this is not an Apprunner-specific problem. Bill says that if it's dying the way you describe, then it's a problem somewhere inside netlib or gecko. We don't know and we don't really have the expertise to find out, especially when none of us can reproduce the problem.

I'm going to send this over to dp following don's suggestion that this could be a NetLib problem. I initially thought the bug had something to do with HTML errors (such as images referenced in the document not being there). But I have now seen other pages which have no discernible errors and still will not reload. Here's what I know in summary at this point. 1. Go to the URL above (corrected from the original). And once you load this page, try reloading by clicking on the reload button, placing the cursor in the location window and pressing the CR keyu, or changing the View | Character Set menu. If you're on a machine which has this problem, it will fail to reload the page. One clear way to see this problem is go to another page and try to come back to the above URL. This will fail because it refues to reload. By the way, this page has no error and contains several lines of English text. That's it. 2. Of the 3 Windows machines in my cube, I have this problem in 2 of them (Windows Nt4-US and Windows NT4-Japanese) I tried 2 machine in the Intl Lab and found one of them to have this problem and while the other one does not. 3. As far as I know this problem seems to occur under NT4 mostly. 4. So far I have not found a developer machine which has this problem. All the machines where I found this problem is a non-developer machine. 4. I'll be happy to demo this problem on my machines if youn want to look at it.

Layout may be a better place to start for this problem. I am thinking that error handling on the pages along with encoding is somehow confusing layout/parser.

DP -- Please ask your netlib team to take a look. The history of this bug is that no one is willing to take the time to track it down, and I don't think layout should be the dumping ground for such issues. If you find any layout related issues, I'm happy to intervene.

If I adopt the same approach that netlib wont be the dumping ground, just imagine where this bug will go. Rickg, I dont think you are adopting the right attitude. It bothers me when you think we are dumping bugs on layout. In your expert opinion, if you thought layout wont be the best place for this bug to start, I would agree. Nevertheless, I will asssume the later and we will give our best shot at this one.

Update on this bug: (with the 5/13/99 Win32 build) I'm continuing to have the reload problem on my 2 NT machines, one for US OS and the other for Japanese OS. I had a problem demoing certain features of ours for 2 groups already due to this problem, one for the Seamonkey Engineering group the other day and the other time for visiting IBM people, just a couple of days ago. This really is a test blocker for me. It's embarrassing that you go to a page and doesn't show right because it's in a different encoding and then when you try to switch to another encoding, the menu doesn't work because of the reload problem here.

dp, if you want to see this problem in action, please give me a call any time you like. I'll be happy to go over this with you.

Well, I tried to track down the source of the error, and I got as far as line 1453 in nsNetService.cpp: /* * If the connection is still marked as active, then * notify the Data Consumer that the Binding has completed... * Since the connection is still active, the stream was never * closed (or possibly created). So, the binding has failed... */ if ((nsConnectionActive == pConn->mStatus) && (nsnull != pConn->pConsumer)) { nsAutoString status; pConn->pConsumer->OnStopBinding(pConn->pURL, NS_BINDING_FAILED, NS_RELEASE(pConn->pConsumer); } It is returning the NS_BINDING_FAILED error, but I don't understand the comment above that code. Perhaps one of the netlib guys could explain this?

Warren, the new netlib manager gets this.

Rick, Can you explain the comment below to Erik and hand this bug off. QA: Can we live with this for a few more weeks until necko is ready? Thanks.

I'll be waiting to see this problem get resolved or addressed in the new NetLib. Will review it then. Please indicate in this report when you are ready for us to re-check the status.

Well from erik's description in the bug log, this is what's happening... Netlib has called NET_StreamBuilder(...) which called NET_NGLayoutConverter(...) to create a NET_Stream and nsConnectionInfo structures... I believe that the stream creation failed due to OnStartBinding(...) failing - see nsStubContext.cpp line 953. If I remember correctly, this was the only (?) case where you could end up in the URL exit routine without having called OnStopBinding(...). Try setting a breakpoint in the code that handles the failure of the OnStartBinding(...) call and see if that's what's happening :-) I'm not sure why OnStartBinding(...) would fail, but after looking at the code (in mozilla/webshell/src/nsDocLoader.cpp line 1374) my best bet is that the binding is being aborted and returning NS_BINDING_ABORTED. This would mean that Stop() had been called on the doc loader - which happens each time a page is loaded. So, maybe the page had not finished being loaded when it was interrupted and reloaded?? This is just my wild ass guess without being able to step through the code... Let me know if you find out more... -- rick

From many encounters with this problem on my machines, I can say that typical instances of this problem is that I got get a page and it finishes loading. Then I find that the page does not display correctly because the document's charset does not match what I chose for the Charset menu. So, I switch to another Character set. That's when I get this loading error. I don't think I'm interrupting loading when I engage the menu switch which leads to a re-loading attempt.

moving this to M7. still not enough to go on to hold the M6 release for this. we may need to wait until necko lands

necko first landing is M8

To test rick's hypothesis, can we modify the test page so that it will load very slowly and give us time to reliably hit reload before it finishes loading?

so, do you have a workaround here, or is this still blocking M9?

I cannot reproduce this in 8-16 Win32, Mac, and Linux build.

I move this to M10. Kat, please test this again.

Jan, this needs to be fully re-tested on my 2 machines to assess where we are on this since many changes have occurred since this bug was originally filed. Teruko's tests results are encouraging sign that things probably changed quite a bit since I filed this bug. I'm going to remove QA blocker tag and also downgrade the severity.

Is this still a problem now that necko has landed?

marking fixed. m11. please test and reopen if there still is a problem.

** Checked with 10/7/99 Win32 M 11 build ** This has been fixed. I haven't seen this problem for some time now and M10 final candidate (10/6/99) doesn't have this problem, either. Marking it verified fixed.