One reason why Mozilla doesn’t use platform libraries

Tags: , , , , , — Jeff @ 14:02

Every so often (okay, ALL THE TIME) someone (Linux users, of course ๐Ÿ™‚ ) wonders why Mozilla doesn’t use platform libraries for things like networking code. One commonly-argued reason is that it gives us the flexibility to fix security problems without waiting on those upstream libraries to make the fix themselves — we control the code, and we can make the fixes ourselves.

Another reason not to use platform libraries occurred to me while reading Planet WebKit today, specifically the recent WebKit’s week – #7 post. Quoting from that post, added emphasis mine:

HttpOnly Cookie (38566)

An Internet Explorer extension (added in Firefox and Opera since) will soon be supported by WebKit based browsers. This restricts the access to certain cookies. They are only available for an HTTP request and so not from JavaScript. This is an important functionality to restrict the damages of an XSS vulnerability. This is not available in the nightlies because you need some updated Apple proprietary libraries (CFNetwork).

As noted, Firefox supports HTTPOnly cookies; after the patch to add this support was committed, you could download nightly builds which included the fix, and HTTPOnly would Just Work. No mess of upgrading platform libraries to make it happen, no separate-package updating, no waiting on Apple to update their platform libraries. (Incidentally, will Apple make those updates for 10.4 users as well, assuming they even decide to release a browser upgrade for a, er, “dying” OS release? Maybe, maybe not, who can say; “Apple does not comment on future products.”) Just download the build, build it from source yourself if you like building from source or if you’re a Gentoo ricer, and you have a working browser with the fix.

There are tradeoffs to be made rolling your own code when you could use something provided by the OS or by a third-party library. However, it should be equally clear that there are tradeoffs to be made going the other way, at least if you truly care about being cross-platform.

(On an almost entirely unrelated note, I was pleased to discover while writing this post that HTML5‘s outline-generation algorithm properly handles headings inside blockquote elements. Yay for specs anticipating my concerns! ๐Ÿ˜€ )


The twelve days of Christmas

An amusing video via my favorite economist, even if it’s obviously not true to real life:

As a computer scientist my first thought is that it’s a very good thing there are only twelve days; imagine the cost if it were O(n2) rather than O(1)! (There’s a very large constant in this video’s case, of course, but as it’s not intended to accurately reflect reality there’s no reason to optimize. ๐Ÿ˜€ )


California: a bastion of sanity

(Pre-emptive snarky notice: nothing Mozilla-related here, so if that’s all you care about, scram. ๐Ÿ™‚ However, if you’re a non-Californian who enjoys the occasional dash of schadenfreude, even moreso if your local political unit is fiscally responsible, read on.)

Two quick news stories in California crossed my field of view in the past few days which I found, er, interesting, to say the least.

First, if you ever happen to visit California and I happen to be in a car crash while you’re present, do not under any circumstances move me out of the car if you think the car might explode. If you did, you’re liable for any harm that might cause me, and I might be able to find a convenient excuse to sue you for lots and lots of money. The relevant section of law (1799.102) is below:

1799.102. No person who in good faith, and not for compensation, renders emergency care at the scene of an emergency shall be liable for any civil damages resulting from any act or omission. The scene of an emergency shall not include emergency departments and other places where medical care is usually offered.

The California Supreme Court case is S152360; I don’t know enough about the California Supreme Court to know how the case is to be officially and permanently cited. (Anyone who does know should comment and inform me on this, please. ๐Ÿ™‚ ) The opinon, released on the 19th, ruled 4-3 that moving an injured person from a believed-dangerous location at the scene of an emergency (judged so by the mover, although at odds with the judgments of others at the scene) does not constitute emergency medical care; thus Torti, who in this case moved her (presumably now former) friend Van Horn from such a location is liable for civil damages resulting from moving her. Where did the term medical come from? According to the California Supreme Court:

While section 1799.102 is certainly susceptible of Torti’s plain language interpretation, a “[l]iteral construction should not prevail if it is contrary to the legislative intent apparent in the statute. The intent prevails over the letter, and the letter will, if possible, be so read as to conform to the spirit of the act.” (Lungren v. Deukmejian (1988) 45 Cal.3d 727, 735.)

In other words, the term medical has been read into the law by the Court from the other legislative provisions which surround it. (It wasn’t even done reasonably, either, as the dissenters in the case aptly show in their dissent.) Ergo, since moving a person from a dangerous situation in an emergency isn’t medical care, the Good Samaritan in this case can be held liable for damages caused by that action.

I believe I can confidently state that at least four of the justices on the California Supreme Court are not textualists.

(It’s worth noting that others present at the accident apparently contest that there was an actual emergency at the scene, because they saw no evidence the crashed car was going to explode. If that’s the case, the correct action would have been to contest that there was an emergency and thus prevent the Good Samaritan exception from applying. [In fact the dissent in its closing paragraph noted precisely this point.] This particular situation sounds to me like more a matter of nerves than anything else, but as that argument seems not to have been raised, it’s somewhat irrelevant now anyway.)

Second, it’s no big secret that California’s in the midst of a pretty hefty budget crisis (which, to the best of my knowledge, has been around since before the current economic upheavals — a situation also shared with Michigan, my immediate past home state). California’s legislatures have been attempting to address a projected $18 billion (or so) deficit for some time now. There’s merely one small roadblock to avoid in doing so: the California State Constitution in article 13A section 3 says that:

Section 3. From and after the effective date of this article, any changes in state taxes enacted for the purpose of increasing revenues collected pursuant thereto whether by increased rates or changes in methods of computation must be imposed by an Act passed by not less than two-thirds of all members elected to each of the two houses of the Legislature, except that no new ad valorem taxes on real property, or sales or transaction taxes on the sales of real property may be imposed.

To parse that out a little and omit irrelevant text, it says that any change in state taxes for the purpose of increasing revenues must be part of a legislative act passed by two-thirds of each house of the California legislature. So unless the California legislatures can get two-thirds of each house to agree to a bill to do it (and they can’t, not in the middle of an economic downturn), they can’t combat the fiscal emergency by increasing taxes.

What should then be done? Clearly, if you can’t make more money through taxes and you can’t make money through bond sales because nobody wants to buy them, the only other option is that you should spend less money (or, most probably, a blend of the two). Instead, however, we have the following (and more like it) as described by California State Assemblywoman Noreen Evans:

Specifically, the bill enacts a new $0.39 per gallon fee on gasoline. This compares with the existing $0.18 per gallon excise tax and the 5% general sales tax on gasoline which is assessed per dollar. It enacts a new $0.31 per gallon diesel fee, and this compares with the existing $0.18 per gallon diesel excise tax.

(The source of that quote is an audio file at around 27:30 into it; I transcribed from the audio. My Google-fu on this topic isn’t up to snuff at least partly because I’m still new to California politics and don’t know the right names to use in search queries, so I’m having trouble finding the quote in text format online.) So what’s happening is our spades (“taxes”) are now shovels (“fees”), except super-sized, and that rule that applied to spades no longer applies just because we’re calling them shovels rather than spades. Instead, an increase in a “fee” requires only a majority vote, not a two-thirds super-majority vote. The Governator™ vetoed this constitutional end-run (or will be doing so, not sure about the exact timeline), but that the legislatures would have the sheer audacity to attempt this is breathtaking.

There’s a lesson to be learned here, kids: if you don’t like your constitution, just ignore it. Also, blame it on an obstructionist minority if you can; it’s not your fault you had to violate the constitution to which you took an oath/affirmation of allegiance.

(also cross-posted on RedState)



A (novel?) twist on looking up Mozilla (or other) bugs

Tags: — Jeff @ 14:13

If you follow Mozilla stuff much, you probably do a lot of reading of bugs; if someone passes you a an unseen bug number, you’ll probably want to view that bug. (Of course, the Awesomebar’s suggestions make revisiting an old bug significantly easier than with Firefox 2 or with other browsers, so this trick’s much less applicable to already-seen bugs.) Here follows a few ways to do this, including one that I suspect very few people, if any, have ever used.

Method #1: You already know it

The simplest way is to type:


…followed by the bug number. It’s a bit slow. Copy-pasting helps, but you have to re-seed the clipboard every time and possibly delete a bug number, if you’re pasting from a previous bug viewing.

Method #2: Use a bookmark keyword

Setting up a bookmark keyword can reduce the bug URL prefix to a few characters. First, load the following URL and bookmark it:


Then open up Bookmarks < Organize Bookmarks…, find the new bookmark, and edit its properties. After selecting the More expansion triangle at the bottom of the window, type something like “b” in the Keyword textbox. From now on, typing b <bugnumber> in the location bar will open up that bug by loading the bookmark with %s replaced with whatever you typed as <bugnumber>. Repeat visits won’t require this as the bug will already be recognized by the Awesomebar (so hitting down a few times followed by Enter will bring up the bug again), but it’s still handy for first-time visits.

Method #3: keyword.URL

Is this as far as we can go? Can we reduce the typing any further in the new-visit case? I doubt many people have considered this, but the answer’s actually yes.

I assume most avid bug-followers already knew about bookmark keywords; after all, they date back at least to the Mozilla Suite. Keywords are a somewhat less-known functionality triggered by typing search text in the location bar and hitting Enter. Assuming you’re using something like the default setting, typing search terms in the location bar triggers a Google search using a URL specified as a hidden preference, and the search terms are tacked to the end of that URL.

What if we changed this URL to something other than Google? Particularly, what if we change it to recognize bug numbers and “fall through” on everything else? Here’s a URL which will do just that:

data:text/html,<title></title><script>onload=function(kwd){kwd=document.getElementById("text").textContent;location.replace((/^\d{1,6}$/.test(kwd)?"https://bugzilla.mozilla.org/show_bug.cgi?id=":"http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=")+kwd);};</script><span id="text" style="display:none">

You’d use this, of course, by typing about:config in the location bar, clicking through the nanny screen, typing keyword in the filter box, double-clicking the keyword.URL preference, and pasting the above URL in the dialog box.

I’ve been experimenting with this for a couple days, and it’s clear it isn’t quite optimal. There’s a noticeable pause between this URL loading and the redirect to the bug happening that the keyword.URL syntax makes unavoidable, it hardwires the fallback keyword URL, it offers only one Bugzilla (if you happen to follow multiple Bugzillas regularly), and it’s less elegant than the bookmark keyword solution. However, it does avoid a few characters, which might balance out the delayed load time; I don’t have the long-term experience (or ability to override significant bookmark keyword muscle memory, yet) to say for sure.

This last idea isn’t perfect, but perhaps people other might find it useful.