461249 - Cannot load Javascript, menu freezes.

Status: NEW

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

Description

[clrbugzilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081019 SeaMonkey/2.0a2pre
Build Identifier:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081019 SeaMonkey/2.0a2pre

While on blueletterbible.com and trying to open the concordance panel. the application froze and refused to load. It showed after refreshing the page. This problem is not in Firefox3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1) or Internet Explorer 7. 

Reproducible: Always

Steps to Reproduce:
1.Go to supplied web page. 
2.Choose a bible verse and click on the "C" block
3.
Actual Results:  
The page displayed a loading message and did not load but would show after refreshing.

Expected Results:  
Loaded the concordance pane.

Comment 1

[Ria Klaassen (not reading all bugmail)]

A wide regression range is 2008081310 - 2008081508. See if I can find a smaller range when I can reach my other computer.

Comment 2

[Ria Klaassen (not reading all bugmail)]

You need to repeat reporter's step 2 in order to see the bug; it doesn't fail the first time. In a flash you can see that it tries to load the panel but it fails to bring it on the screen.
Smaller regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-14+02%3A00%3A00&enddate=2008-08-14+06%3A00%3A00
I don't know which one could be the cause.  
Ben, could it be Bug 441930?

Comment 3

[Johnny Stenback (:jst)]

This seems to work for me. Can someone re-test?

Comment 4

[Ria Klaassen (not reading all bugmail)]

Still failing on Windows XP.

Comment 5

[Johnny Stenback (:jst)]

Over to Ben Newman who will investigate.

Comment 6

[Ben Newman (:bnewman) (:benjamn)]

Problem occurs because a Loading interval event fires after the desired content has been inserted, clobbering the inserted content.

Hypothesis: loadingInterval changes before it can be cleared
Experiment: hijack setInterval to enforce the clearInterval discipline

(function(si) {
    window.setInterval = function() {
        clearInterval(loadingInterval);
        return si.apply(this, arguments);
    };
})(setInterval);

After evaluating this code, the problem goes away, which confirms my hypothesis.  The question remains what we are now doing differently such that loadingInterval gets clobbered before it can be cleared.  Might be a bug, might not.  I'll report back.

Comment 7

[Ben Newman (:bnewman) (:benjamn)]

As far as I can tell, all that's changed is the ordering/timing of asynchronous events, which isn't guaranteed.  The client site can fix the problem fairly simply, so I'm inclined to mark this bug invalid.  Objections?

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.