578706 - Script from scorecardresearch has error; lots of sites not loading

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Gervase Markham [:gerv]]

Lots of sites which include Technorati are not loading, with the status bar saying they are waiting for "b.scorecardresearch.com":
http://twitter.com/search?q=scorecardresearch

For example, loading:
http://opendotdotdot.blogspot.com/2010/07/richard-stallman-on-net-mono-and-dotgnu.html
in 4.0b1 leads to a JS error:

Error: COMSCORE is not defined
Source File: wyciwyg://59/http://blog.okfn.org/2010/07/02/the-open-spending-data-that-isnt/
Line: 1

blizzard's testing didn't show this as a problem in 3.6.6, which is why we are starting by suggesting this is a JS engine bug. 

However, some reports say it is:
https://support.mozilla.com/nl/forum/1/725177
so it could be a problem with the site. But it can't be showing up for everyone, otherwise tens of thousands of blogs would be inaccessible to millions of people.

Gerv

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is a bug in the site.  They must have changed their code so that now a document.write is racing with the end of the pageload.  Specifically, using http://dbaron.org/log/ as my testcase:

1)  I can always reproduce the bug on trunk.
2)  I can always reproduce the bug in Fx 3.6 if I enable the HTML5 parser.
3)  I can reproduce the bug in Fx 3.6 with the old parser if I shift-reload.

What happens is that the document.write happens after the page has loaded in case 3 above, or in a racy way period in cases 1 and 2 above, and blows away the document.

Comment 2

[Boris Zbarsky [:bzbarsky]]

And key here is that builds that were working just fine on dbaron's blog a month or two ago are failing now, and I know the bits on my hard drive in the nightly archive did not change.  So this was a site change.

I would fully expect this shows up for anyone using the HTML5 parser, and for some people with slow net connections using the old parser, on the tens of thousands of blogs mentioned in comment 0.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Has someone contacted Technorati yet?

Comment 4

[Gervase Markham [:gerv]]

bz: you are awesome.

Who would we contact at Technorati?

There's a form here:
http://technorati.com/contact-us/
but none of the subject options are technical issues.

There are email addresses here:
http://technorati.com/about-technorati/
but none of them are a technical contact. I guess we could spam them all.

Gerv

Comment 5

[Gervase Markham [:gerv]]

OK, I just talked to John Lilly and he's making some connections for us.

bz: are you able to be more specific about exactly which script has the bug? It could be one of Technorati's partners rather than them themselves, and it would probably help them to know who to pick up the phone to. Is it scorecardresearch? Or someone else?

Gerv

Comment 6

[Boris Zbarsky [:bzbarsky]]

> bz: are you able to be more specific about exactly which script has the bug?

Somewhat.  I can tell you which script is making the document.write call easily.  I'd have to dig to figure out who screws up loading that script.

For dbaron's blog and the blog you cite, the document.write call happens in http://ad-cdn.technoratimedia.com/ads/tm_pixel_gen.js

Comment 7

[Boris Zbarsky [:bzbarsky]]

Speaking of which, that tm_pixel_gen.js is included like so by http://scm-l3.technorati.com/scripts/widgets/tr_embed_t_js.js on dbaron's blog:

  var trTrackerURL = "http://ad-cdn.technoratimedia.com/ads/tm_pixel_gen.js";
  var trTracker = document.createElement("script");
  trTracker.setAttribute("type", "text/javascript");
  trTracker.setAttribute("src", trTrackerURL);
  trHead.appendChild(trTracker);

That's a classic example; that load will race with the parser and if the parser wins the race the document.write() calls in the pixel_gen script will blow away the document.  Note that the parser winning the race will blank the document in all currently shipping browsers; HTML5 just changes things so that inherently racy code like this always blows the document away so as to avoid exactly this sort of problem where code works or not depending on network speed.

Comment 8

[Christopher Blizzard (:blizzard)]

Would it be possible to add a JS warning about document.write() blowing away an existing document, once we've seen a <body> element?  (Is that even what's happening here?)

Comment 9

[Gervase Markham [:gerv]]

Another test URL just in case it's needed:
http://opendotdotdot.blogspot.com/2010/07/richard-stallman-on-net-mono-and-dotgnu.html

Gerv

Comment 10

[Boris Zbarsky [:bzbarsky]]

It's not once you've seen a <body>.  It's once parsing is done.  And it happens fairly often on purpose...

It might be possible to warn on document.write blowing away a document before onload has fired for that document, though.  That might work...

Note also that there are proposals for the HTML5 spec that would change the behavior back to the racy one here.

Comment 11

[Gervase Markham [:gerv]]

Technorati say, by email:

Gervaise,
We are going to remove offending code tomorrow until we can find a better solution.  Thanks to you and John for reaching out!

Best,
dave

Comment 12

[Henri Sivonen (:hsivonen)]

(In reply to comment #8)
> Would it be possible to add a JS warning about document.write() blowing away an
> existing document, once we've seen a <body> element?  (Is that even what's
> happening here?)

The fix for bug 560256 will mitigate this issue (with a console warning). Hixie's spec fix was different from what I proposed, so I need to re-check the patch on that bug before landing it.

Comment 13

[Gervase Markham [:gerv]]

Technorati have modified 
http://scm-l3.technorati.com/scripts/widgets/tr_embed_t_js.js
to remove the script load, and the blogs listed here now load fine for me in 4.0b1. Thanks very much to them for their quick response.

Resolving.

Gerv