Theme Font & Size Changer for Thunderbird 64.6 fixes (#E6F4)

Yeah, f*ck me, why am I doing this.

Okay, so after a few requests and complaints about issues with TB 60.2.1 and 63b1, I spent the last hours digging deeper. That’s a mess, and not only on the code side of this addon, but also in terms of Mozilla. Well, who would have thought.

64.6 was just uploaded to the TB repository, could take a week to get that approved. Took care of zoom field and fonts list, also updated some more stuff that got disabled already or will get disabled in the near future.

Zoom. Not as in the Mazda cars, but as in layout.css.devPixelsPerPx. That actually was set to an oncommand on the text box itself, which, after I finally got it to break in 60.2.1, never again worked in previous versions. Easy fix: Remove the oncommand stuff and slap in a button that does the same, like with the font size a few rows below.
Remarks: The textbox was set to increment="0.05" min="1.00" max="2.75" decimalplaces="2". Hilarious. The textbox is saved as integer, so fuck everything non-int. Furthermore, increment is disregarded in both ways: It does not change the integer value because it just rounds down, and increment is itself an int, so it cannot even be 0.05. Oh, and decimalplaces…in an int field. What did these guys smoke when designing those textbox attributes? Is that even legal anywhere in the world? Lazy man fix: Now everything is in percent (without saying so…), so now very strange zoom values are possible. increment seems still broken, that’s going up 1% per step, not 5% as set. Whatever.

Font list. The addon pulls a language preference first and then populates the list of available fonts, probably omitting those that do not fit your non-western language setting. This was done the following way:

var prefs = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService);
var branch = prefs.getBranch("font.language.");
var langGroupPref = branch.getStringPref("group").data;


Okay, so prefs works, branch works, langGroupPref breaks. branch only has one child attribute (array?) “group”, and I am not able to extract the value that my Thunderbird says is active. I get undefined, “undefined”, some chrome link (which apparently says “user did not override stuff”, but never “x-western”. So after two hours of fiddling around, I made a try{} statement, if that fails, you get defaulted to x-western before breaking everything that follows. Easy as that. If anyone know how to friggen extract the correct string, I’m glad to push another version that fixes this.

MacCheck. That’s, as far as I understand, closely related to the zoom feature which could break loose hell on OSX, so there’s a little warning box for those users. I cannot test this on Apple hardware as I do not own such repair-proof hardware, but I kinda see how the original author did this. There are quite a lot of constants set with important paths, like the user desktop dir, OS dir and so on. Some of these are specific to one or more operating systems, and “UsrDsk” is apparently OSX-only. So whatever
var dirService = Components.classes["@mozilla.org/file/directory_service;1"].
getService(Components.interfaces.nsIProperties);
dir = dirService.get("UsrDsk", Components.interfaces.nsIFile);

does, we’ll be able to tell if there’s a Mac involved or not. Unfortunately, it took me quite some time to realize this was intended behaviour and the guy knowingly went straight into an (catched) exception in order to determine the OS. Guess there should be an easier way to do that, but that’s for another update. Heck, why do I update this stuff, this should be core functionality in TB…

And last but not least, the catastrophic failure in TB63b1 seems to be a problem of TB, not the addon. Apparently XPCOMUtils.generateQI is broken in both Firefox and Thunderbird nightlies, and that beta seems affected as well. See https://github.com/mozilla/tls-canary/issues/171 , other guys already had fun with it. I will not implement fixes for broken TB versions, just wait for stable versions that do not break more than absolutely necessary.

Well, that’s it, no time to write the blog post about the next step in ESP8266 kitchen monitoring. But I got this one AND a new addon version, so today was still a productive day.

Addon is attached for those of you that want to test it before it gets approval from the Mozilla guys. Everybody else gets a notification and can upgrade as soon as it’s live.

See you next time!