Closed Bug 225708 Opened 22 years ago Closed 20 years ago

external JavaScript isn't available

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 227976

People

(Reporter: traumwandler, Unassigned)

Details

Attachments

(2 obsolete files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.5) Gecko/20031007 I include two javascript files using <html> <script language="JavaScript" type="text/javascript" src="script1.js"></script> <script language="JavaScript" type="text/javascript" src="script2.js"></script> </html> both scripts are pretty big. Sometimes (i didn't evaluate the pattern) the functions defined in script1.js are not available (because it isn't loaded yet). I realized that this isn't so with small libraries because they are loaded too fast. Reproducible: Sometimes Steps to Reproduce: 1. Create two big javascript files 2. add both via <script>-tag to a html 3. use a function from the first script in the second script Actual Results: The function isn't available - JavaScript Error Expected Results: Excute the Function (because it was defined before the second script)
> because it isn't loaded yet That should have no effect, since we block further parsing while loading a <script>. Please point to a page showing this problem.
I am having a similar issue which may be related to this one. I get an 'x is undefined' error when calling x from a div's mouseover event handler, even though x is defined in an external .js file that is referenced in the head. Shouldn't all scripts in the head be parsed before the body? Testcase will follow shortly.
Attached file testcase 1 (1of2 html) (obsolete) —
Attached file testcase 1 (2of2 js) (obsolete) —
Attachment #163866 - Attachment mime type: application/octet-stream → application/x-javascript
Mike, if reload is involved in your steps to reproduce you're not seeing this bug. Note that comment 0 does not mention reload. The bug that you _are_ seeing is filed, but I don't have the number off the top of my head. Martin, could you please respond to my request for a testcase showing the problem? I can't reproduce it, so I may have to mark this bug worksforme if there is no response...
Attachment #163865 - Attachment is obsolete: true
Attachment #163866 - Attachment is obsolete: true
(In reply to comment #5) >...The bug that you _are_ seeing is filed, but I don't have the number off the top of my head... Thank-you, I believe the bug I was looking for is 252542.
That's right, I have the same problem and it is very annoying. For example in phpPgAdmin there's a function updateLinks() in an external file and in the page is <a href="javascript:updateLinks()">...</a>, sometimes it works, sometimes, it does not. I thought it might have something to do with my user profile, so I ran firefox as another user with the same result. I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4
ondrej@svetlik.info, can you point me to a testcase that shows the problem? Please test a current trunk build (eg the Deer Park Alpha 2 release we just shipped), not the over-a-year-old rendering engine in Firefox 1.0.x.
Ok, I have this problem at http://rvsnet.cz/sneberger/ There are two files: stm31.js and menumain.js, stm31 contains a code for the menu, menumain.js just uses this code to generate the menu. Right now it works, yesterday it didn't with absolutely no changes. I'll try this very new build, but it's quite difficult as the problem is very hard to predict or reproduce. I'll do my best.
Ok, Deer Park Alpha 2 seems to work fine, but it needs more intense testing. But, I think it is not a good idea to have a "stable" product with such annoying problem. I'm not sure, but the problem may have appeared after upgrading to ff-1.0.4. I'm going to test 1.0.3 and 1.0.5.
Yea, if this is actually a regression on the branch I'd like to know.... If it's been on the branch all along, then we just let it be.
Well, I think I've found the problem. It was so difficult to reproduce, because it is a bit server-specific. The whole problem seems to be in gzip encoding. I had the same web on two servers, one with mod_deflate enabled and one disabled. Without gzip, everything works fine, with gzip on, strange things appear. I also have to put this problem together with another one. On my web server firefox sometimes didn't load external styles. It is the same problem, when mod_deflate is off, no problem with styles appeared. I tested ff-1.0.3, 1.0.4 and 1.0.6 some from .tgz some from fc3 rpms. All with the same result. Deer Park a2 still seems to be all right.
Oh, ok. If the problem is gzip encoding and it's ok on trunk but not on branch, then this is bug 227976. *** This bug has been marked as a duplicate of 227976 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: