Closed Bug 461724 Opened 16 years ago Closed 16 years ago

last.fm loads, but then goes blank and is stuck loading

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: justinthomas85, Unassigned)

References

(
URL
)

Details

(Keywords: top500)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 I don't know how long this has been going on, but It seems to be a problem specifically with the 3.1b1 release. 3.0.3 works fine in this regard. Anywho, when visiting last.fm, the site loads normally, then it all disappears and a white blank page shows. Sometimes it doesn't even load at first. After thinking it might be an extension compatibility issue, I disabled every add-on and used the default theme, but the problem persists. I disabled the new tracemonkey javascript engine (which I enabled at first), but still nothing changed. Reproducible: Always Steps to Reproduce: 1.type last.fm in address bar 2.watch as page initially loads 3.watch further as white blank page instantly appears Actual Results: watch as page initially loads watch further as white blank page instantly appears Expected Results: last.fm loads normally.
Version: unspecified → 3.0 Branch
I have no problem with last.fm using a recent Seamonkey trunk build on vista (TM is enabled). Did you restart Firefox after disabling the extensions ? You might want to use the safemode instead of disabling all the extensions: http://support.mozilla.com/en-US/kb/Safe+Mode
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081028 Minefield/3.1b2pre I get the same issue. When I visit last.fm all I get is a blank page. Steps to Reproduce: 1. Type last.fm in address bar. 2. Watch the page appear (the full page seems to appear for a moment. 3. The page disappears and is replace. Expected Results: Last.fm loads normally. Actual Results: Blank white page replaces last.fm Notes: Firebug shows only a <head> section with a script (http://ipinvite.iperceptions.com/Invitations/Javascripts/Layer_Global.js) for the source of the page. Firebug's script tab however does display the entire contents of the HTML page source as a script. Looks CONFIRMED to me.
Also, I tried using Safe Mode as well and had the same result. (In reply to comment #2) > Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) > Gecko/20081028 Minefield/3.1b2pre > > I get the same issue. When I visit last.fm all I get is a blank page. > > Steps to Reproduce: > 1. Type last.fm in address bar. > 2. Watch the page appear (the full page seems to appear for a moment. > 3. The page disappears and is replace. > > Expected Results: Last.fm loads normally. > Actual Results: Blank white page replaces last.fm > > Notes: Firebug shows only a <head> section with a script > (http://ipinvite.iperceptions.com/Invitations/Javascripts/Layer_Global.js) for > the source of the page. Firebug's script tab however does display the entire > contents of the HTML page source as a script. > > Looks CONFIRMED to me.
I'm seeing it, too. This should really be a blocker for 3.1. Last.fm is a very popular site which, with this bug, you can't access at all.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre Same here. Also triggers an assertion added in bug 444322: ###!!! ASSERTION: Too many calls to ScriptDidExecute: 'mScriptsExecuting > 0', file /Users/jruderman/central/parser/htmlparser/src/nsParser.cpp, line 1810
Component: General → DOM
Keywords: testcase-wanted, top500
Product: Firefox → Core
QA Contact: general → general
Summary: Page loads, but then goes blank and is stuck loading → last.fm loads, but then goes blank and is stuck loading
Version: 3.0 Branch → Trunk
Flags: blocking1.9.1?
OK, this works in a 2008-12-01-02 Mac build but fails in 2008-12-02-02. Pushlog with 2 hours on each side: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-12-01+00%3A00%3A00&enddate=2008-12-02+04%3A00%3A00
In that log, bug 461563 is the most likely culprit, in my opinion. That said, I can't back the patch out cleanly, so I can't confirm that quite yet.
OK, scratch that. The changeset that introduced this issue is <http://hg.mozilla.org/mozilla-central/rev/2ad9a0f79e7d>. Here's the checkin comment: Version bump mozilla-central to 3.2a1pre/1.9.2a1pre. CLOSED TREE So given that: 1) Is this actually a problem with 3.1 builds? The initial comments here say yes, but I'm not seeing that. Perhaps the site fixed its browser-sniffing somewhat? 2) Someone want to figure out exactly where the broken browser-sniffing is so we can evangelize the site? 3) Can we get a separate bug filed on the assertion, preferably with testcase? I should note that I tried setting my general.useragent.override to an older version, and it didn't seem to help much, but maybe I messed it up. Or maybe they're sniffing something else.
OK. So the relevant document.write call is in http://group11.iperceptions.com/Invitations/Javascripts/ip_Layer_Invitation_529.js on line 64. Here's what lines 62-65 look like: if (localSwitch) { var GJS = "http://ipinvite.iperceptions.com/Invitations/Javascripts/Layer_Global.js"; if (! browser.isIE) { var vJS2= "<script type='text/javascript' src='" + GJS + "'></script>"; document.write(vJS2); } else lScript(GJS); } Looking at that file, isIE is certainly false. That said, here's where this script is added to the DOM: if (navigator.userAgent.search('Minefield/3.1b') == -1 && navigator.userAgent.search('Firefox/3.1b') == -1) { document.write('<scr' + 'ipt defer="defer" src="http://group11.iperceptions.com/Invitations/Javascripts/ip_Layer_Invitation_529.js"><\/script>'); } Which explains why the version bump broke it. I bet they used to not have the conditional, which is why the bug was present in b1 when first reported.
OK, this is a bug in the site. It's doing a document.write from a deferred script, but only in browsers that are not IE. As long as IE was the only browser that supported defer, this worked: The script ran immediately, the write happened, and life was good. Now that we support defer, the script runs after parse completion, which means the document.write blows away the document. That's exactly what it would do in IE if that code were allowed to execute there. The funny part is that if they just used the lScript codepath they use for IE, things would Just Work in Gecko. If you're a user of this site, please contact them about the problem. Feel free to point them to this bug report and such. Note that the UA sniffing in this JS file is pretty broken, by the way: this.isMozilla= (this.isGecko && ua.indexOf('gecko/') + 14 == ua.length); this.isFirefox= (ua.indexOf('firefox') != -1); } Those are both false in most modern Gecko-based browsers (everything except Firefox releases, in fact).
Assignee: nobody → english-us
Status: UNCONFIRMED → NEW
Component: DOM → English US
Ever confirmed: true
Flags: blocking1.9.1?
OS: Mac OS X → All
Product: Core → Tech Evangelism
QA Contact: general → english-us
Hardware: Macintosh → All
Version: Trunk → unspecified
I don't know how to track an evang bug for the 1.9.1 release, unfortunately. :(
Keywords: testcase-wanted
I've made a reference to this bug here: http://www.last.fm/forum/21713/_/484526 I'm not sure what better ways to contact them. Let's hope they notice.
The patch in bug 461555 should fix this.
Depends on: 461555
It should fix the blanking, at least. Depending on what the script document.writes, it still might not do what the site owner intends.
It's worth mentioning that the JS in question comes from iPerceptions (http://www.iperceptions.com/) and not us directly. It might be worth nagging them as it will likely show up on other sites. Anyhow, we're aware.
Russ, we'll see what we can do to nag them. I assume you guys will contact them on your end too, right? They're sending some pretty weird stuff there.
I filed bug 469769 about the assertion failure.
I sent this message to iPerceptions' technical support email address: Hello, The web application you provide to last.fm contains a bug that makes it impossible to use last.fm in the latest Firefox 3.1 beta release. Many users are experiencing this problem. In fact, when you google for "ipinvite.iperceptions.com", eight of the top ten search results are references to the problem. Mozilla is tracking the problem in bug report 461724 [link]. Boris Zbarsky has identified the bug and how to fix it in comment #11 of that report [link]. Please fix the bug at your earliest convenience so the many thousands of users of Firefox 3.1 betas (and many millions of users of Firefox 3.1 final, when it is released) will be able to access last.fm and other web sites that use your web application. Regards, Myk Melez (last.fm user and Mozilla contributor)
We've been informed by iPerceptions that they've fixed this problem on their end. I'd appreciate it if you could confirm that :).
(In reply to comment #20) > We've been informed by iPerceptions that they've fixed this problem on their > end. I'd appreciate it if you could confirm that :). Confirmed. last.fm now works fine in recent nightlies on Mac and Linux. Yay!
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Verified FIXED using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20081225 Shiretoko/3.1b3pre; this also fixed my Ford.com problem, which was using iPerceptions too.
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.