153600 - ProcessScriptElement should use successvalue as indicator

Status: RESOLVED FIXED

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

Description

[larrybird]

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

[Markus Långström]

WFM, 2002061712 Win 98.
Reporter, please always specify which Build ID you're using when filing a bug.

Comment 2

[Matthias Versen [:Matti]]

wfm with win2k build 20020621..

Comment 3

[R.K.Aa.]

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

Comment 4

[Andrew Schultz]

confirmed with linux build 2002062204.  works fine with build 2002062021.

marking NEW
==> Http

Comment 5

[Andrew Schultz]

Attachment: NSPR nsHttp logs for builds 20020620 and 20020622

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

Comment 6

[Jeremy M. Dolan]

Finishes displaying in 2002062004 linux, but status bar still says "Transfering
data from ...". I get that on quite a few sites... news.bbc.co.uk especially.

Comment 7

[Andrew Schultz]

Jeremy: regression occurred after your build...

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

Comment 8

[Andrew Schultz]

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

[Cees T.]

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

Comment 10

[Andrew Schultz]

Attachment: testcase

this has nothing to do with networking...

Comment 11

[Andrew Schultz]

regression from bug 26790

Comment 12

[Henrik Gemal]

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:
http://nyhedsgrupper.opasia.dk/
which refuses to render...

Comment 13

[Jeremy M. Dolan]

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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

got a patch to fix this, will attach asap

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: 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
children.

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.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

bz, got time to review this?

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Johnny Stenback (:jst)]

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

Comment 21

[John Unruh]

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

Comment 22

[Bernard Alleysson]

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

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 24

[Christopher Aillon (sabbatical, not receiving bugmail)]

Jonas, I'd suggest filing that as a separate bug.

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

changing this bug to reflect the remaining work needed

Comment 26

[larrybird]

Hi, 

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:

http://www.cbot.com/cbot/quotes/futures_volume_detail/0,1589,12+410+415+9,00.html

which still displays incorrectly.  

Comment 27

[Andrew Schultz]

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.

Comment 28

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Jonas, are you still planning to do anything in this bug?

Comment 29

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

No, it appears that we've cleaned things up enough that there's nothing left here to do.