Firefox 6 - Major version, major pain

I was testing out my web code in Firefox today, and I got a message saying that Firefox 6 had been released. Wanting to make sure I was keeping up to date with our users, I installed the update. After restarting the browser when prompted, I noticed that it looked exactly the same. So I went online to check what's new.

Apparently, not much. Oh, there's a small list, but nothing really visible, and it's not really any faster than before. It seems that Mozilla's accelerated release schedule is nothing more than releasing what would normally be a "point release" as a major version instead.

But to what end? Chrome is on version 13; IE's current release is version 9 (with 10 available for preview); Opera is on version 11. Could this be nothing more than a way to "catch up", so "Firefox 5" doesn't sound like it's way behind the other browsers? It was speculated that Microsoft named their second console the "Xbox 360" because "Xbox 2" would sound like it was behind "Playstation 3"; this could be another example of toying with customer mindshare.

Or could it be a way to flush some of the old versions out of general support? Many companies I worked at had a policy such as, "Support the current major browser versions minus two", which today would mean "IE 7 and above, Firefox 4 and above, Chrome 11 and above, etc." — releasing a few major versions quickly would push older browsers that don't support up-and-coming standards like HTML5 out of the support window rather quickly.

Whatever the reason, there is one rather large detrimental effect. Extension authors have to certify that their code is compatible with major releases. Because Firefox just got a new major version number, all of my extensions were marked as "incompatible" and disabled, and that way they will remain until their authors update their xpi packages to mark them as compatible with this new major version. Essential debugging tools like FireQuery, HttpFox, even the Java console are among those that are off-limits until they are updated. Even the extension for the corporate virus scanner is disabled, as is Skype's "click to call" extension (which wasn't marked compatible with Firefox 5 either; not that I use it myself, but I have to be able to confirm that, for customers who do use it, its phone number reformatting doesn't make the page unusable).

Firefox, you used to be cool. I didn't mind inviting you over and letting you crash on my couch. But now you've stolen the food from my cupboards, gotten fat and lazy, started leaving your dirty clothes lying all over the house; and you're wild parties broke my antique table lamp without so much as a "sorry" from you. I grow tired of having to clean up after your mess. IE used to be where you are now, but at least he's been working on cleaning up his act.


Does courtesy fade with age?

I'm sitting on the train, headphones on, playing a game on my Windows Phone, as normal, when I hear a demanding voice from over my shoulder say, "Do you see that sign!?"

My brain attempts to disengage from my virtual world and process this. Usually, when a voice like that is heard, it's from the train police, asking to see passengers' tickets. But wait, that's not what he asked for. Do I see the sign? There are a few posted signs asking for certain behavior. I'm not playing loud music, I'm not eating or drinking, my feet aren't on the seat… Ok, something's wrong, and I guess I need to turn to this mysterious voice and figure out what it is.

I turn and see an elderly man, looking a bit angry, glaring at me, with his finger pointed at the sign that indicates priority seating for elderly or disabled passengers and asking to comply with all requests to vacate the seat for a disabled passenger.

So, I figured I'd give him the opportunity to request my seat. "Do you want to sit down?"

"DO YOU SEE THAT SIGN?" he yells again.

The people in the rear-facing seat across from me offer their seat and practically stumble over themselves to get up and move to one of the several other vacant seats on the train. "No, I can't sit backwards," the old guy complains after them.

"All right," I said, giving up on any chance of civility with this curmudgeon. I stand up, turn around, and sit in the hastily-vacated rear-facing seat.

The old fart then sits down, pulls out a 12oz Coke bottle, and starts drinking it, right under the sign that says "No Eating or Drinking".

I guess he didn't see the sign.


RJ11 to RJ14 - easier than I thought

I've just switched from Comcast's VoIP to a third party VoIP provider (the company formerly known as VoIP.com, now a part of Phone Power). When I got my box (slightly smaller than a 3"x5" card and just thick enough to have phone and ethernet jacks on its back), I noticed it had Phone Line 1 and Line 2 as two separate RJ11 jacks. Why they didn't just use a single RJ14 jack is beyond me. It's not like A splitter that takes an RJ14 two-line jack and converts it to two RJ11 one-line jacksline splitters are that expensive — they retail for a couple bucks and probably cost half that wholesale. But where splitters are apparently plentiful, a combiner, something that takes two separate single-line jacks and makes a single two-line jack out of it, is impossible to find in a store and even extremely rare online. So, how was I supposed to take these two RJ11 outputs and plug them into the single RJ14 jack that serves as input for my house wiring?

I found instructions for rewiring a CAT-5 ethernet cable to do the job, but I didn't want to have to buy a crimping tool to form the plugs, nor did I feel comfortable splicing it into existing phone cords (the last time I tried something like that, it ended badly). But then I had a sudden revelation.

You see, there's really nothing special about telephone cord accessories. A splitter just takes the pins in a given plug and wires them to the appropriate pins in the right jacks. In the splitter pictured above, the first pair on the RJ14 plug is wired to both the first (and only) pair on the L1 jack and the first pair on the L1+L2 jack. The second pair on the RJ14 plug is wired to the first (and only) pair on the L2 jack and the second pair on the L1+L2 jack. All those associated pins are interconnected; there is no special circuitry that separates the connections (i.e., nothing keeping the L1 jack and the first pair on L1+L2 from talking to each other) — that's why these things are so cheap. Further, wires are bi-directional. If you apply an input voltage to one end, it will carry it to the other end; conversely, if you apply an input voltage to the other end, it will carry it back to the first end. Wires don't care which end is labeled "input" and "output".

And neither does a splitter. With all the pins interconnected by wires, you can just as easily send a signal input into L1 and L2, and get the combined output in both the L1+L2 and the RJ14 plug on the back side.

So that's what I did. I connected the VoIP adapter's Phone 1 and Phone 2 jacks to the L1 and L2 jacks of a splitter, and connected the L1+L2 jack to my house wiring input jack. (I could've used the RJ14 plug on the splitter itself instead of another phone wire, but there wasn't enough room around the input jack on the patch panel for a splitter to fit.)

So why is this so important that I bothered writing a blog post about it? Because, as I was searching out a solution to this problem (which apparently plagues users of Vonage equipment as well), I couldn't find this very simple solution. Maybe someone else will stumble upon this blog post as they search for their own solution and discover just how easy it is.


Firefox, jQuery, and event binding, revisited

While I had decided for myself that I didn't want to support Firefox anymore, the company that signs my paychecks respectfully disagreed. Because my project is an internal admin tool, we were able to tell our user base not to use Firefox for the time being and assign the bug a relatively low priority — but, it was something that should be revisited and fixed. Having completed my tasks well ahead of schedule, the time was at hand.

The bug had to do with Firefox failing to fire off a jQuery click event handler. I had long since installed the Firebug extension, but all it could tell me for certain was that the event handler code was not being called. I was fortunate, in my searching, to find another extension, FireQuery, which extends Firebug by adding jQuery information to the debug panels. Installing that and viewing the HTML, I could see that the jQuery click event handler simply wasn't there on the switches that weren't working.

Using the development version of jQuery, I stepped through the code that attaches the event handler, and I could find no difference in code execution between the switches that worked and the ones that didn't (unsurprising, since I attached to all of them at once).

The solution, surprisingly, came about when I started mucking around with elements and styles, substituting divs for lis in a desperate attempt to find the cause. To make a long story short, it was the fact that, later in the code, I called a jQuery plugin called "text-overflow" that emulated the text-overflow: ellipsis stylesheet directive that every browser but Firefox supports.

The problem with the code is that, in order to emulate the feature, the plugin creates a cloned copy of the node to "ellipsify" and progressively removes characters until the width of the cloned node fits in the desired width of the original. Then, it sets the contents to be the new text, and destroys the copy. Unfortunately, there are a couple side effects:

  1. If no truncation happens, the contained elements lose their event bindings, since they end up not being the original elements, but copies.
  2. If truncation does happen, when the contents are replaced with the new text, any other elements contained therein (i.e. hidden form fields holding data for a form post) are wiped out.

The first problem might have been overcome by using jQuery's own clone method which clones nodes and any events associated to them. (This was added after the plugin was written, so I don't fault the author for oversight). To be safe, though, I changed the class on the switches' containers and excluded them from my .ellipsis() call. That successfully kept the slider click event handlers from disappearing.

The second problem was the source of another bug, where a jQuery function attempting to look up values from hidden form fields was failing to find the data on elements that were truncated by the text-overflow plugin. I moved the hidden form fields outside of the elements targeted by the function call, and that, too, was magically fixed.

Internet Explorer has a bad (and well-deserved) reputation for needing special development time to do the same thing that other browsers do (although, in my experience, a lot of this would be unnecessary if it weren't for a requirement, usually from an upper-level executive or, worse, marketing, mandating pixel-perfect replication across all browsers), but I've found lately that the pendulum has swung far the other way to deal with the quirks in Firefox.