Getting Adobe Air to Recognize Your Default Browser

Among the issues I have re-encountered in reinstalling my Ubuntu fresh is that links from TweetDeck open up in Firefox, instead of Chrome, my default browser. Chrome on Linux, by the way, is still only available from the dev channel. It's readily available, but still has its share of issues - currently, my dropdown boxes are blank when I try to select an option. They get fixed - that particular isse has been taken care of already and will be fixed in the next release - but it's still iffy. That said, it is way zippier in Linux than Firefox, which is pretty much dog-slow at times, in my experience.

Anyway, for these reasons, I wanted TweetDeck to respect my default browser, but it stubbornly insisted on opening links in Firefox. Since I generally don't have it open, it takes a few seconds to open Firefox and load the page, instead of popping up Chrome with my page already displayed pretty much instantly. It didn't take long before it got on my nerves, and I remembered that I had fixed this before. A quick trip to the (one guess) Ubuntu forums pointed me to a very helpful post by Andrea Olivato, detailing how to fix this without resorting to really nasty hacks like symlinking Firefox to Chrome.

Turns out that Adobe, in all its wisdom, decided to hardcode Firefox into their binary for opening links. Brilliant. Which means that you have to get your hands dirty doing a little bit of hex editing and, yes, symlinking. Because for the hex editing, the string for the browser has to have the same number of characters as "Firefox", so you don't screw everything up. Andrea had the clever idea of symlinking "browser" to your desired browser, which is good semantically, and has the same number of characters as "Firefox". Perfect! His commenters further improved upon the fix by suggesting that "browser" be symlinked to either x-www-browser or xdg-open. Both are generic "default browser" options. After reading up a bit, I still don't really know which is "better". I think I like xdg-open though. So, here's how to Fix It Right, based on Andrea's instructions, with the commenters' suggestions integrated in:

Before anything, do a sudo su to get into a root prompt. Then, symlink the desired default-browser alias (xdg-open or x-www-browser) to "browser" in /usr/bin:

root@geekmobile# ln -s /usr/bin/xdg-open /usr/bin/browser

Then find your libCore.so file with a locate:

root@geekmobile# locate libCore.so
/opt/Adobe AIR/Versions/1.0/libCore.so

With your hex-capable editor of choice (Vim in my case, gEdit isn't going to do it this time), open the file found via the locate command:

root@geekmobile# vi /opt/Adobe\ AIR/Versions/1.0/libCore.so

Find where it says "openURL" in the file. In Vim this is a simple as a /openURL<enter>, but of course this depends on your editor. Then replace the "firefox" right after that point with the word "browser" (which you symlinked above to your default browser). Save the file, restart TweetDeck (or whatever Air app you're using), and enjoy quicker, better link-opening! Hurrah.

And again, many thanks to Andrea for the tips!

Wordpress, Plugins, Paragraphs, and wpautop

Just a quick tip, because nothing I found in a quick Googling was helpful. I was writing a plugin for Wordpress recently that functioned as a filter on the_content, like many, many plugins do. As I was applying the CSS/HTML from a design mockup that I had sliced up from a PSD, I noticed that some of the spacing was funny for no apparent reason. Thanks to Firebug, I quickly discerned that Wordpress was randomly* sprinkling <p> and <br/> tags all over the place, in ways that very much broke my layout. I could fix it by smashing all my tags up onto one line, which seemed to dissuade Wordpress from throwing tags in, but that was ugly and made my code rather unreadable.

After a bit of research, I found out that this was the doing of the potentially useful, but unintentionally nefarious wpautop filter. After some more digging, I realized that if I could get my filter to happen after wpautop had worked its "magic," all of my problems were solved. Fortunately, the add_filter function provides just such an option. And upon investigation, the previous author (I'm revising an existing plugin) had set it to be priority 0 (aka before everything). I switched that up to priority 99, and the random paragraphs and breaks disappeared, and my layout fixed itself.

*Okay, there was some rhyme and reason, such as after images, or before divs, or something...but the point is, it was putting them places where I didn't tell it to, and didn't want them. End of story.