This URL: http://www.cnn.com/ELECTION/2008/results/president/ Has results loaded after the page is loaded. In trunk version: Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081107 Minefield/3.1b2pre It never finishes loading. Works in Firefox 3.0.3 on the mac.

On error console I'm getting: Error: illegal character Source File: http://i.cdn.turner.com/cnn/z/.e/js/2.0/election/packages/president_static-511.js Line: 467, Column: 3 but I'm not sure if it's related (I don't have 3.0.3 to check if the exception is thrown there as well). Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081107 Minefield/3.1b2pre

Interesting. I don't get any errors on the error console at all. And there doesn't appear to be anything obvious in the file at that line.

Do you have javascript.options.showInConsole = true? Otherwise nothing shows. That line 467 has an eval() statement and I suppose invalid character is in the variable. The variable is: ([{\k\e\y:"us\e\r\_\t\o\p\i\c\s",\v\a\l\u\e:{\v\i\s\i\t\s:15,\t\w\_\a\r\r\a\y:[{\k\e\y:"\A\i\r\_\D\i\s\a\s\t\e\r\s",\w\e\i\g\h\t:2.2696356501000006},{\k\e\y:"\W\o\r\l\d\_\P\o\l\i\t\i\c\s",\w\e\i\g\h\t:1.5112310850900004},{\k\e\y:"\A\c\c\i\d\e\n\t\s\_\a\n\ Green arrow under the line points to first backslash (4th character).

I do have that set, yes. Weird.

Still getting it with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1b2pre) Gecko/20081124 Minefield/3.1b2pre

Regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-30+19%3A00%3A00&enddate=2008-08-31+13%3A00%3A00 so this seems to be caused by bug 407216.

I think this should block.

We can't reproduce this anymore - perhaps fixed by another TraceMonkey fix? Please re-open if you can reproduce on latest branch or trunk nightly.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090128 Minefield/3.2a1pre The movie still doesn't load here with the latest hourly.

Ria: can you hunt down a regression range on this for us? Might go back a bit.

I can't reproduce this on Vista with: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090203 Minefield/3.2a1pre (.NET CLR 3.5.30729)

Mysterious that some people see the flash and others don't.

WFM in B3Pre on Mac. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090210 Shiretoko/3.1b3pre Also WFM on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090210 Shiretoko/3.1b3pre Maybe another fix corrected this or the page was changed. Do we still need qawanted and regressionwindow-wanted?

Still fails for me, still the same javascript esxception thrown as explained in comment 3 I volunteer to find regression window but in ~6 hours. If someone's faster, go ahead.

Alright, I was bored so I did that sooner. Works: 20080930093007 http://hg.mozilla.org/mozilla-central/rev/99cd24b71102 Fails: 20081001 http://hg.mozilla.org/mozilla-central/rev/63b0791327ab Before you point out the most obvious, no, the change in UA string length was not the cause. I checked by faking the "working" UA string. There exists a major obvious difference when tracing http headers. When it works: firefox asks www.cnn.com: GET /ELECTION/2008/json/US/national.html? HTTP/1.1 www.cnn.com responds: HTTP/1.x 302 Found Location: http://edition.cnn.com/ELECTION/2008/json/US/national.html? firefox asks edition.cnn.com: GET /ELECTION/2008/json/US/national.html? HTTP/1.1 edition.cnn.com responds: HTTP/1.x 200 OK So, normal get - redirect - get - success. When it fails: firefox asks www.cnn.com: OPTIONS /ELECTION/2008/json/US/national.html HTTP/1.1 www.cnn.com responds: HTTP/1.x 405 Method Not Allowed .... so the very first "ask" is for OPTIONS instead of GET. Also note lack of question mark at the end of URL. Moreover, json seems to be involved. Finally, the javascript exception form comment 3 was something specific to my profile, please ignore it.

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-30+09%3A30&enddate=2008-10-01+05%3A00 Lots of changes... there's no hourly archive from back then is there.

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-30+07%3A30&enddate=2008-10-01+05%3A00 Better list because it includes both changesets. Apologies for the bugspam.

i can reproduce the problem with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090212 Shiretoko/3.1b3pre and latest flash version - i don't see the results and it keeps loading - also no errors in the error console.

There is now a regression range (thanks Radek!) and a few more examples of which configurations pass and fail (thanks tomcat!). I am removing qawanted and regressionwindow-wanted. Feel free to add qawanted bac on if there is anything else we can help with!

Do we still have a working testcase for this? I can't reproduce with TM tip, but I couldn't reproduce before either. I am tempted to close this again WFM. Objections? Can anyone still reproduce this?

note, i also see the problem in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6 - page never finishes loading !

The flash doesn't load for me in a current SM branch nighly and also with Firefox 3.0.6 (!) with flash 10 U22. I'm sure that this worked before and it still works in IE. tomcat got the same issue with FF3.0.6

I'm going to mark this wanted for 1.9.0.x since it's blocking 1.9.1, but we won't push on it to get fixed or mark it blocking until there's a clear reproducible case (seems to go back and forth) and/or a fix ready for m-c and 1.9.1.

Taking and investigating...

I can't reproduce this either.

Still can't reproduce. If someone else can, please reopen -- but do note that I don't think a bug in a page of such temporal utility should block in any case. :-)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090421 Minefield/3.6a1pre I can still reproduce it easily. Maybe location related? But I doubt indeed if it is useful to reopen.

Bug still reproducible here, too. I think it should remain open until there is at least a definite explanation for this bug and, more importantly, if it is due to the site or to firefox. The latter would undoubtly require fixing. Just imagine something like this would happen again on such a popular site soon after the next major update to firefox is released...

Re-opening as it is clearly reproducible. Frosch- Please give your user agent string like Ria did so we know exactly what platform and build you are using. 5 People have seen this and/or repro'ed it and 3 can't repro it. We have a regression range (c7, c16)

My user agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090421 Minefield/3.6a1pre Btw., I have another Minefield running on Windows Vista at work and the bug occurs there as well.

Moving back to nominated status, I don't actually think this should block per comment 27... The location-based wrinkle might be relevant here, but I'm not sure of a way for me to verify that theory. :-\

Anyone tried reducing a saved version of the site content to minimize the testcase? How about eyeballing the code, as this could be a DOM bug, not a JS bug. /be

Yeah, ok I see now: on the top panel you need to make a choice between the CNN International Edition (in that case you don't see the flash), but with CNN US edition you can always see it. This choice is stored in a cookie.

I see in post bug 407216 builds while loading the choice changes from "US" to "International". The bullet in the radio button goes to "International" while loading. And "International" does not get the flash. That seems to be the bug :/

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090421 Minefield/3.6a1pre Confirmed. Changing the Edition to "CNN U.S." makes the flash work again. Changing it back "CNN International" will make it fail to load.

I can reproduce the bug now.

This happens with JIT off as well. Could someone confirm? (about:config and disable jit for content).

Works with Safari.

Yeah, fails with JIT off (and Flashblock disabled for edition.cnn.com, stupid site)...

Did anyone try capturing the international version of the page? That might reproduce offline.

offline testcase doesn't work in safari either

offline testcase doesn't work due to document.domain mucking which fails a security check in the offline case

I can't find any indication that this is JS related. I works in 3.0.8 and Safari. We probably need a bisect to get somewhere with this.

I will see that i can find a regression range for this ! - Tomcat

I verified and got exactly the same result, Bug 407216. If the bug still is that it doesn't load the flash with the "International" cookie.

(In reply to comment #46) > I will see that i can find a regression range for this ! You mean something different than comment #16?

Confirming in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090422 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090422044118 changing to US loads, switching to international fails

In case someone would want http logs for comparison between a correctly working and a failing build, I have them here. They are large to attach.

I can get this to never finish loading on Firefox2, Firefox3.0.x, Shiretoko, and Trunk.

There is a problem in downloading the whole pages. Firefox states that the source file cannot be read?! Is someone able to grab all the files?

I think there are actually two issues going on here. First, there was a regression caused by bug 407216 ("setting a property that has only a getter") which has since been fixed, though I haven't tracked down what changeset fixed it. After that regression was fixed, this bug was no longer reproducible, so it was closed. Sometime later, a second regression popped up that was only reproducible when using the "international edition". International edition changes the domain to edition.cnn.com, so the XHR for http://www.cnn.com/ELECTION/2008/json/US/national.html is cross-site. So it seems likely that this bug in its current form is the same as bug 485704. Moving to Tech Evangelism...

(In reply to comment #53) > First, there was a regression caused by bug 407216 ("setting a property that > has only a getter") which has since been fixed, though I haven't tracked down > what changeset fixed it. After that regression was fixed, this bug was no > longer reproducible, so it was closed. This was fixed the day after bug 407216 landed, so this bug is really all about cross-site XHR. The 2008-08-31 regression window was a red herring.

Whee! Michael, you are awesome.

wow, nice work Michael.

As of today this is still an issue. There is an infinite loading wheel into Firefox Aurora version 31. In Opera 21, we get the results. Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.76 Safari/537.36 OPR/21.0.1432.31 (Edition Next) In Safari Version 7.0.4 (9537.76.4), we get the results. Moving to Desktop Component.

"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://www.cnn.com/ELECTION/2008/json/US/national.html. This can be fixed by moving the resource to the same domain or enabling CORS." If you send an OPTIONS request for http://www.cnn.com/ELECTION/2008/json/US/national.html the site returns a redirect! :-o OPTIONS http://www.cnn.com/ELECTION/2008/json/US/national.html HTTP/1.1 Host: www.cnn.com User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Origin: http://edition.cnn.com Access-Control-Request-Method: GET Access-Control-Request-Headers: x-prototype-version,x-requested-with Connection: keep-alive Pragma: no-cache HTTP/1.1 302 Moved Temporarily Server: nginx Date: Wed, 11 Jun 2014 09:42:43 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive Set-Cookie: CG=NO:01:Nesoddtangen; path=/ Cache-Control: no-cache Vary: * Location: http://edition.cnn.com/ELECTION/2008/json/US/national.html So that's why. Chrome permits a CORS request that redirects back to a same-origin URL to succeed, Firefox looks at the lack of CORS headers in the response and terminates.. Which behaviour is right per spec?

Firefox is correct: http://fetch.spec.whatwg.org/#cors-preflight-fetch (if status is not in the range 200 to 299 a network error is returned). Once there is a preflight in play, redirects are banned. What does Chrome do exactly? Does it do another OPTIONS against the new URL? Where does it do the actual GET/POST against?

Ah, in Chrome it's a GET request, not OPTIONS - no CORS involved, it loads content with an IFRAME. So the code that caused bug 485704 is indeed striking again.

Contacted someone from CNN today about it.

Recontacted the person from CNN, but the email is not working anymore > Google tried to deliver your message, but it was rejected by the server for the recipient domain turner.com by atlmail3.turner.com. [157.166.168.181]. So I guess the personal is not working there anymore. We need to find a new contact.

(Since this CNN page is about an old election - however historic and exciting - we might at some point decide to give up making them fix it. But what's up with Chrome getting the IFRAME-based branch - does it still throw the exception we should not throw anymore?)

I don't ever see CNN ever fixing this, thus I will close it as Wontfix.