553795 - [HTML5] weer.nl - Blank page with html5.enable to true (Windows only)

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: Dutch, defect)

Description

[Ria Klaassen (not reading all bugmail)]

When I go to http://www.weer.nl/nl/home/weer/wereldweer/actueel_en_verwacht_weer.html?cityID=31X3965&tx_mgcityweatherstatic_pi1[cityIDuse]=31X3965 I get a blank page.

STR:
- set html5.enable to true
- go to URL

Comment 1

[Ria Klaassen (not reading all bugmail)]

Works 52d5ed462c9e
Fails 2396b886239d

Comment 2

[Ria Klaassen (not reading all bugmail)]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=52d5ed462c9e&tochange=2396b886239d

Comment 3

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

Attachment: Somewhat reduced testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

Sounds like a regression from bug 503473.

I assume that IE doesn't make the text disappear on that last testcase?  I wonder why not...

Comment 5

[Henri Sivonen (:hsivonen)]

WFM with my local patches applied. My guess is that this page does something timing-sensitive and the patch for bug 543458 hides the problem.

WFM in IE8, too.

Comment 6

[Martijn Wargers (dead)]

This is still an issue in current trunk build.
I can also see the problem at http://www.huffingtonpost.com/stephen-balkam/why-the-ipad-is-the-futur_b_532869.html

Comment 7

[Martijn Wargers (dead)]

I've also seen this a lot on http://frontpage.fok.nl/review/376698/1/1/100/dvd-alice.html

Comment 8

[Henri Sivonen (:hsivonen)]

On the latest trunk plus my local queue (which shouldn't have anything to do with document.write()),
http://www.weer.nl/nl/home/weer/wereldweer/actueel_en_verwacht_weer.html?cityID=31X3965&tx_mgcityweatherstatic_pi1[cityIDuse]=31X3965
http://www.huffingtonpost.com/stephen-balkam/why-the-ipad-is-the-futur_b_532869.html
and
http://frontpage.fok.nl/review/376698/1/1/100/dvd-alice.html
all work for me on Linux x86_64 with html5.enable set to true and with general.useragent.extra.firefox set to either Minefield/3.7a5pre or Firefox/3.7.1.

Comment 9

[Henri Sivonen (:hsivonen)]

(In reply to comment #8)
> On the latest trunk plus my local queue (which shouldn't have anything to do
> with document.write()),
> http://www.weer.nl/nl/home/weer/wereldweer/actueel_en_verwacht_weer.html?cityID=31X3965&tx_mgcityweatherstatic_pi1[cityIDuse]=31X3965
> http://www.huffingtonpost.com/stephen-balkam/why-the-ipad-is-the-futur_b_532869.html
> and
> http://frontpage.fok.nl/review/376698/1/1/100/dvd-alice.html
> all work for me on Linux x86_64 with html5.enable set to true and with
> general.useragent.extra.firefox set to either Minefield/3.7a5pre or
> Firefox/3.7.1.

All these pages load for me on Mac with general.useragent.extra.firefox spoofed to Firefox/3.5--both in 32-bit and 64-bit latest trunk nightlies (without any of my local patches).

Comment 10

[Martijn Wargers (dead)]

I can't reproduce this on my own place. I see this issue only at my parents place. I think their router is hacked or something. It probably means that some html code is dynamically added to those pages. I have to investigate further, when I'm there.

In the meantime, the url in the bug report still shows the issue for me. I'll try to make a minimized testcase, when time permits me.

Comment 11

[Henri Sivonen (:hsivonen)]

I still see the originally reported problem on Windows XP in a fresh nightly.

I don't see the problem on Windows XP with the Huffinton Post and fok.nl pages.

The HTML5 parser is *supposed* to take timing-sensitivity out of the blanking behavior (with the old parser, document.write from a timeout makes it timing-sensitive). I tried using general.useragent.override to claim to be a Mac version of Firefox, but the problem remained.

Comment 12

[Henri Sivonen (:hsivonen)]

The attached test case also shows me the problem. This suggests to me that http://smartbase.cdnservices.com/webads_smarttags.v2.js does something Windows-specific in a way that general.useragent.override doesn't affect.

Comment 13

[Henri Sivonen (:hsivonen)]

I looked into this some more. The script mentioned in comment 12 loads http://smartinit.webads.nl/Bin/SmartInit.dll?tbase=SITE=WEER/AREA=WEER_WERELDWEER&iframe=/fileadmin/templates/adlinks/webads_smarttags.v2.js.html&stir=weer_stir.htm&wl=weer/nederland&cc=TU/247/3670/13472&BannerPreSize=true by setting the .src DOM property of a newly created script node in Gecko and by document.writing in IE. That explains why the page isn't blanking in IE.

It doesn't explain why the page isn't blanking on Mac and Linux. Perhaps http://smartinit.webads.nl/Bin/SmartInit.dll?tbase=SITE=WEER/AREA=WEER_WERELDWEER&iframe=/fileadmin/templates/adlinks/webads_smarttags.v2.js.html&stir=weer_stir.htm&wl=weer/nederland&cc=TU/247/3670/13472&BannerPreSize=true never calls document.write on Mac and Linux. I didn't look that far.

Anyway, their wbds_Include function when called with an URL argument without a second argument "direct" uses a script inclusion mechanism that makes the included script blow away the document in IE and in any HTML5-compliant browser if the included script calls document.write.

Therefore, the ad script should use wbds_Include(url, "direct") in all browsers when the included script can call document.write. This could be achieved by running their IE code path in all browsers.

I'm reassigning this to evangelism, because we are adopting (via HTML5) a pre-existing IE behavior and IE gets the safe code path due to browser sniffing but we don't.

Comment 14

[Martijn Wargers (dead)]

Attachment: testcase

This works fine in IE8 and Gecko1.9.1.

Comment 15

[Brian Carpenter [:geeknik]]

URL is not blank with the 4/19 nightly build of Minefield.

Comment 16

[Martijn Wargers (dead)]

I filed bug 560256 on the testcase I attached here.

Comment 17

[Martijn Wargers (dead)]

Why shouldn't Mozilla be doing as what IE is doing?

Comment 18

[Henri Sivonen (:hsivonen)]

The landing of bug 560256 mitigates the user-visible problem so that it's not worthwhile to pursue contacting the site.