Does Firefox update despite being set to "never check for updates"? This might be why.

If, like me, you have set Firefox to "never check for updates" for some reason, and yet it does sometimes anyway, this could be your problem: the chrome debugger.

The chrome debugger uses a separate profile, with the preferences copied from your normal profile. But, if your prefs (such as app.update.enabled) have changed, they remain in the debugger profile as they were when you first opened the debugger.

App update can be started by any profile using the app, so the debugger profile sees the pref as it once was, and goes looking for updates.

Solution? Copy the app update prefs from the main profile to the debugger profile (mine was at ~/.cache/mozilla/firefox/31392shv.default/chrome_debugger_profile), or just destroy the debugger profile and have a new one created next time you use it.

Just thought you might like to know.

Can you imagine…

  • Posted: Aug. 18, 2015, 10:40 a.m.
  • Last updated: Aug. 18, 2015, 11:28 p.m.
  • Tags: frontpage mozilla

… an imaginary menagerie manager imagining managing an imaginary menagerie?

Just over two years ago, I posted about localizing Mozilla extensions. I'd made a website for translators, which automatically created GitHub pull requests. Well, I'm not here to say it's been an overwhelming success, but I think it did achieve my aim of simplifying the translation process.

Over the past month or so, I've rebuilt the website from scratch, to be much simpler, and much less fragile. Instead of having a Git clone on the webserver, and a working copy for every translation (which caused big headaches when it came time to update the clone), the website now stores translation data in a database, and when ready, creates files, commits, branches, and pull requests directly on GitHub. It also updates itself every time the original repo updates, by watching a particular branch. From a translator's point-of-view, not much has changed, although if they use GitHub to register, pull requests will be made using their account for better communication.

For reasons even I'm not really sure of, I called the original "Zoo". Now in a perfect storm of inspiration and originality, I've called this new website "Zoo2". Genius.

It's a little rough-around-the-edges, but it's ready to go. I'm looking for people to translate my extensions, obviously, but now I'm also looking for other extension writers willing to try things out. I have a few criteria, mostly around things I've yet to implement, but if your extension is on GitHub, open an issue and we'll talk. I'm also often in #developers on Mozilla IRC in the US evening/Asian day/European morning.

Edit: I'm hosting this thing on a free Heroku account, which means it must sleep for 6 hours a day (I'd get so much more done if I slept that little) and today's seen a lot of activity so it might be sleeping. I guess you get what you pay for, and I haven't paid anything yet.

Cookies are a Sometimes Food

There's been a lot of talk about HTTP cookies lately. I decided to take a look at my cookies database and these are some of the things I found:

  • There were 1298 cookies. This is probably fewer than most people have, because I have third-party cookies disabled. Also occasionally I delete cookies from domains I don't recognise.
  • 579 (45%) of them had expired.
  • 468 (36%) hadn't been used for 3 months. 31 hadn't been used for 6 months. 2 hadn't been used for over a year.
  • 401 (31%) expire more than a year from now. 296 (23%) expire more than 2 years from now. 236 (18%) expire more than 5 years from now.
  • 35 expire sometime in the year 2038. 50 expire after 2038.
  • 2 expire in the year 4751 (!!) and one expires sometime after the year 10000 (the value is so large Javascript and I have given up calculating it).

So what?

Firefox doesn't clear away expired cookies. No big deal for most people. You might think otherwise.

It's the expiry dates that get me. Is there really any reason for a website to store a cookie for 25 years? Is it really going to be useful to Dell, to know when I last visited (September 15th, apparently) 900 years from now? Does Bitbucket need to know what repos I recently viewed, until a few decades before the Mayan Calendar requires a sixth digit? (You remember the Mayans, right?)

Sooo, what?

Because I can, I made a small add-on to clean up some of this detritus from the cookies database. It can delete expired cookies, cookies you haven't used for a while (you get to set how long), and will alter the expiry date of remaining cookies so that they don't last until the Sun burns up the Earth. It will even do so automatically, when you take a break to watch Sesame Street.

You can use it now too. Here it is. I named it Cookie Time after a company that makes delicious real cookies (feel free to send me some).

Om nomnom nom nom.

Forked Lightning

I haven't done much lately but I haven't done absolutely nothing. Given that I look at my Lightning calendar every day, some things began to irritate me. I've started to fix them.

(Note that I don't actually plan to fork Lightning and release it, I'm just using the term for pun value.)

Things you can see here:

  • Moved the view controls to the toolbar for space-saving and prettiness reasons
  • Restyled the events to match the today pane
  • Used better colours for my calendars (that's just done with about:config, but I'd change the available colours in the picker)

Things you can't see:

  • Switched on a database option for the offline cache (massive performance win, woo!)
  • Switched to Philipp's javascript implementation of iCal, and made some other changes so that Lightning could be run without being unpackaged, and without version dependence
  • Stopped the month and multiweek views from refreshing all the time when it's unnecessary

All these things and a few more are available as-is on my c-c patch queue if you're interested in trying them. I've done the easy 80%, and I wish I could justify spending the time on the hard 20%, but I just need to look at the picture above to see the reminders of bills that need to be paid.

Rethinking add-on localization

  • Posted: July 28, 2013, 11:22 p.m.
  • Last updated: July 28, 2013, 11:31 p.m.
  • Tags: frontpage mozilla

As an add-on developer, I don't like doing localization. It's one of those hurdles I have to get over before I can release something. The thought process goes something like this: "I really want to release this new version for people to use and love and send me money for. Oh, I should probably get the translated strings up-to-date. Ugh."

What if localizing was as easy as merging a pull request?

There's a problem with that. Translators probably don't know git¹, and programmers are probably busy programming.

What if we took GitHub, and mushed it together with localization?

Ah, now that I can do, or rather, I can get a computer to do. Get the strings translated, turn the changes into a patch, upload to GitHub. Boom.

So that's what I've done. Introducing Zoo. Nothing really all that fancy, just a text box for each string, and some code to do all the complicated stuff. It's far from ready for the prime-time, but it should be good enough if you're a translator and want to muck around with something different. I've loaded up four of my add-ons there (they come with some existing translations which you won't be able to edit) as a starting point.

I'm nervous about posting this. Please don't break it.

(I'm often lurking in #developers on Mozilla IRC in the US evening/Asian day/European morning, come say hi.)

¹ But, I have had two translation pull requests this week. That makes a total of two, ever. It confirmed what I thought though, that this is a great way of doing things.