Overview Description: The above URL loads fine, but loads blank if you hit the reload button and try to load again. Steps to Reproduce: 1) Goto my.netscape.com 2) Login 3) Clicking on the customize nose in the weather panel 4) Wait for page to load (successfully) 5) Hit Reload Actual Results: Blank page loads Expected Results: Weather customization screen should load. This is on all platforms using 2/17 builds Additional Information: It is interesting to note that if you load it the first time, then hit back to go back to my.netscape.com, then click on the weather nose again, it loads fine. Probably it is not using the cache in this instance, but I don't know.

I get this in Linux 2000-02-18-08. I created a test case for what I think is the problem, but I can't get it to reproduce reliably. The test case is an HTML file which includes two JavaScript files via <script type="" src="">. A third snippet of JavaScript code in the HTML file calls a function in one of the two included files, and that function calls another function in the second included file. Similarly to the description of this bug, the page loads successfully on first load but generates a "function not found" error on subsequent loads for the first function call as if it never parsed the first included file. Here's the url for my test case along with the urls for the two included files: http://www.zapogee.com/~myk/tc29.html http://www.zapogee.com/~myk/tc29.js http://www.zapogee.com/~myk/tc29b.js A simpler test case with only one included file also reproduces this problem, but less reliably. I found the probability of encountering this bug also varied by web server; the web server in the urls above demonstrated it less frequently than the web server on my development machine. Finally, deleting my '.mozilla' directory and creating a new blank profile made the problem go away (note that the prefs.js file was empty for that profile), but migrating my NS4.7 profile (including some cache settings) brought it back.

I tried this test on NT and it seemed to load and run the js each time, printing "some text". Is this what is supposed to happen? I tried the my.netscape.com thing too and it seemed to work fine on NT (except the Weather panel is off the right side of the page, and you don't get a scrollbar). Reloading worked each time. Nonetheless, this doesn't seem like a cache bug. Assigning to DOM component (for js problems).

I created a simpler and more understandable test case: http://www.zapogee.com/~myk/tc30.html http://www.zapogee.com/~myk/tc30.js Note, however, that I am still having a lot of difficulty reproducing this bug. Here are the steps I took to reproduce it: 1. Downloaded today's nightly build (2000-02-22-12 Linux). 2. Deleted ~/.mozilla 3. Ran Mozilla and went through Create New Profile dialog boxes. 4. Loaded new test case from web server on my workstation and from zapogee.com. Couldn't reproduce the bug in either case. 5. Quit and restarted. Went through the Create New Profile dialog boxes again (not sure why, I think it's a new bug). 6. Once again couldn't reproduce bug when loading test case from either server. 7. Quit and restarted. This time no Create New Profile dialog boxes appeared. 8. Reproduced bug when loading test case from local server. Failed to reproduce bug when loading test case from zapogee.com. The speed at which I reloaded also affected reproducibility, but not reproducibly: When I reloaded as fast as possible (several times a second since I loaded from my local server), the bug did not reproduce. When I reloaded once a second, the bug reproduced. When I reloaded once every ten seconds, the bug did not reproduce. But then I tried again after I finished writing up this bug report, and now I can reproduce the bug when I reload after ten seconds but not when I load every one second or faster. I realize this isn't a lot to go on, but it's the best I have been able to come up with. Note that this is not a JavaScript error as far as I can tell, unless the JavaScript component is responsible for loading JS files in addition to parsing them. The problem here is not that JavaScript is being parsed incorrectly, it's that JavaScript files included with the SCRIPT SRC tag aren't being parsed at all. That's what happens in my test case (in which a variable defined in the included JS file is not found by JS code in the HTML page), and that's what happens on the page this bug was originally filed on (in which JS files build the page content, resulting in a blank page when those files aren't parsed).

Both the original report and the reduced test case seems to work for me. Prashant, could you confirm that this is a WORKSFORME?

I think this is a duplicate of bug 29370. Although that bug is about external CSS files not loading and this one is about external JS files not loading, the descriptions are otherwise very similar. Both problems involve external files sourced into the HTML page, both problems go away when the memory cache is disabled, both problems are hard to reproduce for some people but easy for others, and both problems have test cases that work consistently when someone is running a web server on the same workstation on which they are running Mozilla.

I think you are correct - marking as a duplicate. *** This bug has been marked as a duplicate of 29370 ***

*** Bug 32277 has been marked as a duplicate of this bug. ***

Dup per paulmac.