628691 - Error accessing a tt-rss server in FF4b9

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Adam Williamson]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9) Gecko/20110121 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9) Gecko/20110121 Firefox/4.0b9

I've seen https://bugzilla.mozilla.org/show_bug.cgi?id=610236 , but that's a couple of months old and the error message isn't the same as mine; it's worth bearing in mind, though.

I run an instance of tt-rss on my web server for my own use, tt-rss 1.5.0. http://tt-rss.org/redmine . It's basically an RSS feed reader web application. Trying to log in to the server last night and this morning, it just gives me this error message:

Exception: Error, Could not load 'dijit.layout.TabContainer'; last tried '../dijit/layout/TabContainer.js'
Function: init()
Location: dojo.js:14

dojo/dijit is some javascript function library. I checked that TabContainer.js exists on the server and has sane attributes (root/root, 664). There's no errors in the Apache logs.

Key point: I can log in just fine if I run Midori on the exact same machine, or if I run Firefox 3.6 from the laptop next door. (Haven't tried FF 3.6 on this system yet, but I can). So it seems to be a Firefox issue. tt-rss punted me to Mozilla, with a note saying 'don't report bugs with beta browsers', so here I am.

I can give the server / login details to an interested developer by email if it will help debug; there's nothing secret in there, just RSS feeds, but I don't want to post the details here to avoid anyone thrashing my server or anything.

Reproducible: Always

Steps to Reproduce:
1. Go to the tt-rss login page
2. Login
3.
Actual Results:  
Error message

Expected Results:  
tt-rss works

Comment 1

[Boris Zbarsky [:bzbarsky]]

> I can give the server / login details to an interested developer by email

If you can mail me that, it would be much appreciated.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Adam, I just tried the login credentials you sent me with today's nightlies and the Jan 21 nightlies on both Mac and Linux...  I can log in fine in all of those.

Just to check, do you still see the problem with a clean profile?

Comment 3

[Adam Williamson]

yeah, that's the next thing I was going to check...hang on.

Comment 4

[Adam Williamson]

indeed looks like a profile issue: with a clean profile it works. Still, Firefox shouldn't be doing whatever it's doing with my current profile that breaks it! What should I look in the profile for?

Comment 5

[Adam Williamson]

hah. I think what's happening is that FF is caching the dojo stuff...so the relative paths in it don't work any more.

I grepped through my profile's Cache/ dir and found a cached copy of dojo.js . If I delete that, the error changes to 'dojo is not defined'. I'm guessing if I can weed all the dojo stuff out of the cache, it'll start working again.

So...FF shouldn't cache this stuff?

Comment 6

[Adam Williamson]

I just poked around a bit and it started working, but not exactly sure what made it work :/. I wiped the whole Cache dir, then disabled noscript (which involved restarting Firefox), and it worked. Then re-enabled noscript (thus restarting Firefox again) and it works still. I'll see if it breaks again...

Comment 7

[Boris Zbarsky [:bzbarsky]]

> So...FF shouldn't cache this stuff?

It depends on the headers the site is sending....  And even if it's cached, it shouldn't be a problem unless the site changes and expects a new version to be used, but the old version is cached and hence used.

In this case, the headers the site you sent me a link to sends for dojo.js are:

  http response [
    HTTP/1.1 200 OK
    Date: Tue, 25 Jan 2011 21:22:39 GMT
    Server: Apache/2.2.15 (Mandriva Linux/PREFORK-3.1mdv2010.1)
    Last-Modified: Tue, 21 Dec 2010 06:30:28 GMT
    Etag: "10890-160a5-497e5c5c26900"
    Accept-Ranges: bytes
    Content-Length: 90277
    Keep-Alive: timeout=5, max=100
    Connection: Keep-Alive
    Content-Type: application/javascript
  ]

No Expires header, no other cache headers of any kind.  Just a Last-Modified.  Which means we'll cache this script, and not try revalidating it until (now - Last-Modified)/10 time passes from when we cached it.  For the headers above, that would be about 8 hours right this second, but if the script doesn't change for a few months that time could end up being multiple days.

Comment 8

[Adam Williamson]

okay...well, I'll keep an eye on whether it breaks again and try and figure out what caused it, I guess :/

Comment 9

[Adam Williamson]

I haven't seen this happen again, it may be best just to close the bug.