Note: There are a few cases of duplicates in user autocompletion which are being worked on.

ProcessScriptElement should use successvalue as indicator




DOM: Core & HTML
15 years ago
6 years ago


(Reporter: larrybird, Assigned: sicking)


({regression, testcase})

regression, testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments, 1 obsolete attachment)



15 years ago
This page loads immediately in IE, but hangs indefinitely in mozilla.  I'm 
not adept at HTML so I have no idea why.

Comment 1

15 years ago
WFM, 2002061712 Win 98.
Reporter, please always specify which Build ID you're using when filing a bug.
wfm with win2k build 20020621..

Comment 3

15 years ago
spins forever on a current CVS, linux - nothing loads.
Tried all possible combos of proxies and pipeline settings - no go.

Comment 4

15 years ago
confirmed with linux build 2002062204.  works fine with build 2002062021.

marking NEW
==> Http
Assignee: Matti99 → darin
Component: Browser-General → Networking: HTTP
Keywords: regression
OS: Windows 2000 → All
QA Contact: imajes-qa → tever

Comment 5

15 years ago
Created attachment 88826 [details]
NSPR nsHttp logs for builds 20020620 and 20020622

produced with diff --side-by-side (trivial differences manually ignored)

Comment 6

15 years ago
Finishes displaying in 2002062004 linux, but status bar still says "Transfering
data from ...". I get that on quite a few sites... especially.

Comment 7

15 years ago
Jeremy: regression occurred after your build...

marking NEW for real.
sniffit showed the document fully transferred and view->source displayed it just
fine...  ???
Ever confirmed: true

Comment 8

15 years ago
this seems to be working with build 20020622 now.  A new http log shows only
minor differences with build 20020620.

if someone can't just look at the logs I attached and know what's going on, this
is worksforme.

Comment 9

15 years ago
Still occurs with trunk 2002062304 on Windows ME.
View Source does show the code..

Comment 10

15 years ago
Created attachment 88891 [details]

this has nothing to do with networking...

Comment 11

15 years ago
regression from bug 26790
Assignee: darin → sicking
Severity: normal → major
Component: Networking: HTTP → DOM HTML
QA Contact: tever → desale


15 years ago
Keywords: testcase
Summary: will not load in mozilla, will in IE → empty <script> tag prevents continued loading of page

Comment 12

15 years ago
this is a blocker, since people are unable to load pages with mozilla...

it seems like:
<script language="javascript" type="text/javascript">printHeader();</script>
will also prevent a page from loading.

at least that's what I'm seeing on:
which refuses to render...
Severity: major → blocker
Hardware: PC → All

Comment 13

15 years ago
I've had issues loading BBC News lately too. In their source:

<script src="/nol/shared/js/nol.js" language="JavaScript"></script>
<SCRIPT LANGUAGE="JavaScript" src="/javascript/avmega.js"></SCRIPT>

But there were occasionally problems even before this more consistent one.
There's another bug I filed before on it only being loadable once per browser run.


15 years ago
Depends on: 26790

Comment 14

15 years ago
*** Bug 154108 has been marked as a duplicate of this bug. ***
got a patch to fix this, will attach asap
Created attachment 89164 [details] [diff] [review]
patch to fix

this fixes the problem but it's not as beautiful as it should be. What we might
end up doing is call ScriptAvailable/ScriptEvaluated more then once if you
first insert an empty <script> and then set the src-attribute or give it

This can never happen during parsing since we always add all
attributes/children to a <script> before adding it to the document tree.
However it can happen during DOM manipulation. We'll still never evaluate a
script more then once though.
bz, got time to review this?

Comment 18

15 years ago
*** Bug 154157 has been marked as a duplicate of this bug. ***

Comment 19

15 years ago
Comment on attachment 89164 [details] [diff] [review]
patch to fix

r=bzbarsky, but it'd be nice to make the return value from
ProcessScriptElement() be a success value that says "script evaluated" or a
success value that says "nothing to evaluate".

Then we could just check that return value and set mIsEvaluated accordingly....
Attachment #89164 - Flags: review+
Comment on attachment 89164 [details] [diff] [review]
patch to fix

sr=jst, lets get this in and leave the bug open if we want to tweak things more
Attachment #89164 - Flags: superreview+

Comment 21

15 years ago
*** Bug 154164 has been marked as a duplicate of this bug. ***

Comment 22

15 years ago
*** Bug 154428 has been marked as a duplicate of this bug. ***
Comment on attachment 89164 [details] [diff] [review]
patch to fix

this one has landed so all problems should be fixed. However i'm keeping this
bug open to fix the suggestion from Boris
Attachment #89164 - Attachment is obsolete: true
Jonas, I'd suggest filing that as a separate bug.


15 years ago
QA Contact: desale → stummala
changing this bug to reflect the remaining work needed
Severity: blocker → normal
Summary: empty <script> tag prevents continued loading of page → ProcessScriptElement should use successvalue as indicator
Target Milestone: --- → Future

Comment 26

14 years ago

I'm the original submitter. I'm not certain, but I think you believe this bug
is resolved, but its not as you can see at:,1589,12+410+415+9,00.html

which still displays incorrectly.  

Comment 27

14 years ago
this bug (originally) concerned Mozilla hanging when trying to load a page with
a particular <sciprt> syntax.  A display problem (which I do see) on a different
page is a different bug.


14 years ago
Depends on: 214081


9 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
Jonas, are you still planning to do anything in this bug?
No, it appears that we've cleaned things up enough that there's nothing left here to do.
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.