28297 - Page doesn't reload properly

Status: VERIFIED DUPLICATE of bug 29370

(Core :: DOM: Core & HTML, defect, P3)

Description

[Paul MacQuiddy]

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.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 2

[Warren Harris]

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).

Comment 3

[Myk Melez [:myk] [@mykmelez]]

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).

Comment 4

[vidur (gone)]

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

Comment 5

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 6

[Paul MacQuiddy]

I think you are correct - marking as a duplicate.

*** This bug has been marked as a duplicate of 29370 ***

Comment 7

[Paul MacQuiddy]

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

Comment 8

[Prashant Desale]

Dup per paulmac.