275496 - Very popular Turkish site reloads for some reason after showing page and halts there

Status: RESOLVED WORKSFORME

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

Description

[Cabbar D]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

hurriyet.com.tr is a very popular Turkish site (traffic rank#933 on alexa.com),
and it is acting a bit weird. When you navigate to the site, it shows the
contents for a few seconds, then reloads the page for some reason. At this
point, the page goes blank while it keeps saying loading page.

I tried this on various machines with both Windows and Linux and could not get
it to work.

Reproducible: Always

Steps to Reproduce:
1. Connect to www.hurriyet.com.tr
2.
3.

Actual Results:  
As explained in the details, it just displays a blank page.

Expected Results:  
It should have shown the page;) It displays the page on IE.

Comment 1

[Martijn Wargers (dead)]

They have this:
<script language="javascript" id="ad_float"></script>
When you are here the first time (you only see the bug on the first visit, they
use cookies for that), this is executed:
function loadreklam(){
document.all["ad_float"].src="http://Ad.e-kolay.net/getad.a2?target=hurriyetim_anasayfa_float";
}
And that is when you get the blank page in Mozilla. (silent document.all support
is supported only in recent Mozilla versions, so you won't find this bug in
older versions on that page).
That url is containing this: document.write('');

Comment 2

[Martijn Wargers (dead)]

Attachment: js file for testcase

Comment 3

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 4

[Martijn Wargers (dead)]

On first load, or refresh, IE6 gives an alert error:
"Internet Explorer cannot open the Internet site
http://martijn.heelveel.info/test/mozilla/275496_docwrite/275496_2_docwrite.htm

Operation aborted
"
and displays this as result:
text1
text2
text3

On pressing the 'Go' button it alerts two times and then shows:
text1
text2
test this text3

This isn't happening on the url testcase, so this testcase I attached is not
showing the complete picture.

Comment 5

[Martijn Wargers (dead)]

Attachment: Testcase2

This testcase is not giving an alert error in IE6.
It's the same as the first testcase, only I've added '<script></script>' after
the last script.

Comment 6

[Martijn Wargers (dead)]

And testcase2 is always showing this (and giving two alerts) in IE6:
text1
text2
test this text3

But this testcase2 is doing the same as IE6 in current Mozilla trunk. So again,
this testcase is not complete.

Comment 7

[Martijn Wargers (dead)]

Attachment: Testcase3

This is correctly reflecting the difference between IE6 and Mozilla.
On first load this testcase loads 'correctly' in IE6: you get 4 alerts and you
see this:
text1
text2
test this test this text3
But after a reload you get the alert error (which I described earlier) for the
second script.
The way the url testcase (http://www.hurriyet.com.tr/) is made, you only get
this similar situation like in testcase3 only on first load (not in reload),
they use cookies for that. So that's why you never see the alert error in IE6.

Mozilla is 'choking' again on the second script, like expected.

So maybe after all, this is a Tech Evangelsim issue (but I would still like a
DOM guy to take a look at this).

Comment 8

[Boris Zbarsky [:bzbarsky]]

So the page just does a document.write after onload has fired?  But why is
onload firing when there's still a script loading?

Martijn, why does your testcase have the alerts?  Does the site have them?

Comment 9

[Martijn Wargers (dead)]

(In reply to comment #8)
> So the page just does a document.write after onload has fired?  But why is
> onload firing when there's still a script loading?
No, there is no onload used. Basically this kind of stuff is used:
<script id="t2"></script>
<script>
document.getElementById('t2').src="https://bugzilla.mozilla.org/attachment.cgi?id=169275";
</script>
So the source of a script is changed during page load. This script then gets
executed, but it contains a document.write. 

> Martijn, why does your testcase have the alerts?  Does the site have them?
Well, with those alerts, I tried to make it a bit easier to understand what
happens. I can make a testcase without those alerts, if you like.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> No, there is no onload used.

I realize that.  But blanking out means that document.write happened after
parsing was done....

> I can make a testcase without those alerts

That would be helpful for debugging, yes.

Comment 11

[Martijn Wargers (dead)]

Attachment: Testcase4

Same as testcase3, but without using alerts.
The script src is a data uri and has this code inside:
document.write('--');

Comment 12

[Boris Zbarsky [:bzbarsky]]

Yeah, so the problem is that setting src doesn't block the parser and as a
result we end up doing a document.write after parsing is finished, which
clobbers the document.

Martijn, what does that last testcase render in IE?

Comment 13

[Martijn Wargers (dead)]

(In reply to comment #12)
> Martijn, what does that last testcase render in IE?
text1
text2
-- -- text3
(I altered testcase4 slightly, to make it work in IE, because IE doesn't support
data uri's)

Comment 14

[Boris Zbarsky [:bzbarsky]]

If you put some text between the two scripts that set src, does it appear
between the "--" strings?

Comment 15

[Martijn Wargers (dead)]

(In reply to comment #14)
> If you put some text between the two scripts that set src, does it appear
> between the "--" strings?
Yes.
I used this: http://martijn.heelveel.info/test/mozilla/275496_4_docwrite.htm
And in IE6 it results in this:
text1
text2
--2a2b -- text3

Comment 16

[Boris Zbarsky [:bzbarsky]]

So it sounds like in IE setting the src of an existing not-yet-executed script
blocks the parser just like it would if the script had been parsed....  That's
the only way I can explain the output in comment 15.

Comment 17

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

To do that might not actually be that hard. All we would need to do is to block
the parser the 'right way'. I.e. instead of letting the script return a special
nsresult that the sink detects and then blocks the parser, we should let the
script go directly to the parser and block it whenever it's loading an external
resource. This way we can also get rid of cruft in the contensink.

I do wonder though, if what IE does though is to load scripts syncronously
whenever you set the .src attribute.

Comment 18

[Boris Zbarsky [:bzbarsky]]

That's also possible....

Comment 19

[Selim Şumlu]

hurriyet.com.tr has been working perfectly fine with Firefox for years now.

Should we resolve this bug if no one is working on testcases or if they're not relevant anymore?

Comment 20

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Yeah.  We have a completely new parser these days anyways.