Friday, 21 January 2011

Firefox Soft-Blocking Skype Toolbar Extension

The Skype Tool­bar for Fire­fox is an exten­sion that detects phone num­bers in web pages, and re-renders them as a click­able but­ton that can be used to dial the num­ber using the Skype desk­top appli­ca­tion. This exten­sion is bun­dled with the Skype appli­ca­tion, and is installed into Fire­fox by default when Skype is installed or, in some cir­cum­stances, updated. As a result, a large num­ber of Fire­fox users who have installed Skype have also installed the Skype Tool­bar, know­ingly or unknowingly.

Skype’s user-hostile “I’m just going to enable this for you” behav­ior reminds me a lot of RealPlayer in the late 90s. Also this isn’t first time Skype Tool­bar has been soft-blocked.

The cur­rent ship­ping ver­sion of the Skype Tool­bar is one of the top crash­ers of Mozilla Fire­fox 3.6.13, and was involved in almost 40,000 crashes of Fire­fox last week.

Mozilla pro­vides a Top Crash­ers report that is a lot fun to browse through if you aren’t respon­si­ble for any of the prod­ucts involved.

Addi­tion­ally, depend­ing on the ver­sion of the Skype Tool­bar you’re using, the meth­ods it uses to detect and re-render phone num­bers can make DOM manip­u­la­tion up to 300 times slower, which dras­ti­cally affects the page ren­der­ing times of a large per­cent­age of web con­tent served today (plain Eng­lish: to the user, it appears that Fire­fox is slow load­ing web pages).

So what exactly is the Skype Tool­bar doing? You can read through var­i­ous user and devel­oper feed­back col­lected in Bugzilla 615799: Numer­ous prob­lems with skype addon. Senior Mozilla Engi­neer Boris Zbarsky pro­vided the fol­low­ing feed­back con­cern­ing Skype Toolbar’s phone num­ber scrap­ing feature:

  1. Don’t do it on every mutation.
  2. Don’t post an event to trig­ger it on every mutation.
  3. Don’t use muta­tion event han­dlers, ever.

If they really think they want to scrape for phone num­bers after onload, say, one way to do that is to do the scrap­ing when the user hov­ers over their tool­bar or what­ever. Because, again, there is no point doing it on every mutation.

Seems like sane advice for almost any user exten­sion. Peo­ple won­der why Safari and Opera waited so long to imple­ment user exten­sions and it is because this area is very very messy.

Camino 2.1 Alpha Release

After over a year of hard work fol­low­ing the release of Camino 2, the Camino Project is proud to announce the first pre­view release of Camino 2.1.

Enhance­ments include:

  • Enhanced Loca­tion Bar Auto­com­plete: The loca­tion bar’s auto­com­plete fea­ture now searches both book­marks and his­tory and matches against page titles as well as page URLs.
  • Improved Plug-in Con­trol: Camino now dis­ables Java by default, and a new hid­den pref­er­ence allows dis­abling arbi­trary plug-ins.
  • Sta­tus Bar: The sta­tus bar can now be hid­den by choos­ing “Hide Sta­tus Bar” in “View” menu.
  • Offline Mode: New “Work Offline” and “Go Online” items in the “Camino” menu allow Camino to enter offline mode and pro­vide a more use­ful expe­ri­ence when no net­work con­nec­tion is available.
  • Cer­tifi­cate Errors: The cer­tifi­cate error page in Camino 2.1 Alpha 1 is both friend­lier and more infor­ma­tive than the one in Camino 2.
  • Gecko 1.9.2: Camino now uses ver­sion 1.9.2 of the Mozilla Gecko ren­der­ing engine, which has enhanced sup­port for web stan­dards and improved JavaScript performance.

I con­tinue to hold the posi­tion that Camino is an under­rated Mac OS X browser and those loca­tion bar auto­com­plete improve­ments are a most wel­come user expe­ri­ence improve­ment. (Actu­ally the Cer­tifi­cate Error UX enhance­ment will prob­a­bly make more reg­u­lar users happy…)

I’d love to see a more exper­i­men­tal Camino build that was based on Gecko 2 though.

Thursday, 20 January 2011

New W3C Testsuite Server

There’s not a lot of infor­ma­tion here, such as how to sub­mit a test to a W3C project. It does says the host­ing was a dona­tion from Microsoft who has pre­vi­ously placed an empha­sis on strong test suites.

It is pos­si­ble this is just meant as a sta­ble home for raw test case host­ing and the edu­ca­tional pieces will live else­where, but that seems like a missed opportunity.

Friday, 14 January 2011

Firefox 4 Beta Overview

As a release of Fire­fox 4 Beta 9 approaches, Christo­pher Bliz­zard gives us an overview of what to expect. It is a nice laun­dry list of every­thing Fire­fox 4 will deliver when it is finally shipped to the gen­eral public.

Christopher’s list doesn’t quite sep­a­rate what is new in Beta 9 though, but my under­stand­ing is that this release includes a num­ber of updates to their HTML5 pars­ing & ren­der­ing by imple­ment­ing more of what was once-known as Web Forms 2, <video> pre­load­ing and buffer­ing sup­port fixes, and some fixes to push­State and replaceS­tate.

In addi­tion WebGL is now enabled by default, join­ing Chromium in an exclu­sive club of awe­some. Opera and Inter­net Explorer have yet to ship a WebGL imple­men­ta­tion but I sus­pect Opera isn’t far behind. Opera had pre­vi­ously shipped an imple­men­ta­tion of WebGL’s lit­tle brother known then as 3D <canvas> in a Labs build a few years ago.

Tuesday, 11 January 2011

DOM Level 3 Progress

Edi­tor Doug Schep­ers con­tin­ues to update the W3C DOM Level 3 spec­i­fi­ca­tion. Over the last 3 weeks most of the weeks most of the work has been focused on the locale attribute:

The locale attribute con­tains a BCP-47 tag [BCP-47] indi­cat­ing the locale for which the ori­gin of the event (whether key­board, IME, hand­writ­ing recog­ni­tion soft­ware, or other input mode) is con­fig­ured, e.g. “en-US”. May be the empty string when inap­plic­a­ble or unknown, e.g. for pasted text, or when this infor­ma­tion is not exposed by the under­ly­ing platform

This is use­ful for detect­ing the client system’s key­board locale set­ting though not nec­es­sar­ily the lan­guage of the end-user inter­ac­tion with the keyboard.

Saturday, 8 January 2011

WebGL Enabled by Default in Google Chrome Beta Channel

WebGL is a 3D graph­ics API for JavaScript that devel­op­ers can use to cre­ate fully 3D web apps. It is based on the OpenGL ES 2.0 API, which should be famil­iar to many 3D graph­ics devel­op­ers. Google, Mozilla, Apple, Opera and graph­ics hard­ware ven­dors have been work­ing together to stan­dard­ize WebGL for over a year now, and since the spec is just about final at this point, we wanted to get our imple­men­ta­tion out there for feedback.

I’d imag­ine WebGL would get a lot more press if there was an imple­men­ta­tion of Google Earth built with it. Cur­rently web users are stuck with the resource hog­ging Google Earth plug-in.

Mozilla Labs Chromeless 0.1

Chrom­less is an exper­i­men­tal toolkit to make it pos­si­ble to pro­to­type browser appli­ca­tions using HTML, JavaScript and related Web standards.

Mozilla has finally released a devel­oper friendly to embed Gecko inside your appli­ca­tions much like you can already do with WebKit now. I hope this takes off as I’d like to see some more com­pe­ti­tion in the indie-browser devel­op­ment space. Also, I sus­pect for a lot Linux devel­op­ers need­ing to embed a web view inside their GTK or QT appli­ca­tion, this could pro­vide an attrac­tive alter­na­tive to exist­ing options like Gtk­MozEm­bed.

Skating to Where the Puck Is Going to Be

Mozilla engi­neer Rob Sayre’s noodlings on why, at least for now, Apple’s iOS is a good thing for those of us who want to see a plugin-less Web:

The iPhone, and later the iPad, are the best things that have ever hap­pened to keep these hor­i­zon­tal plu­gin plays from tak­ing over the Web. It’s helped me appre­ci­ate what com­pe­ti­tion among busi­ness mod­els can do. Some­one doing a plat­form play like Android or Win­dows will appro­pri­ate what­ever they can–so if you want to do Flash, they will try and make it hap­pen. But Apple has a totally dif­fer­ent set of moti­va­tions, and that is great for the Web. I’m pretty sure the offi­cial Mozilla line on an OS that pre­vents instal­la­tion of Fire­fox is not over­whelm­ingly pos­i­tive. How­ever, I think it’s the Apple busi­ness model that has freed us from unbook­mark­able crap restau­rant web­sites, not Firefox.

(Off-topic, but I also couldn’t resist link­ing to some­one who was famil­iar with the orig­i­nal Wayne Gret­zky quote… though it should be attrib­uted to Gretzky’s father Walter.)

How Does Opera Make Money?

Today we have two dif­fer­ent rev­enue mod­els: One for the Inter­net embed­ded mar­kets (such as Opera pre-installed on a mobile phone or a set-top box) and one for the desk­top market:

  1. For the Inter­net embed­ded mar­ket, we receive rev­enue as a mix of engi­neer­ing fees, main­te­nance fees and shares of sales income. The bal­ance varies from con­tract to con­tract. This model accounts for the major­ity of Opera’s income.
  2. For the desk­top mar­ket, we derive rev­enue from our free prod­ucts through rev­enue shar­ing with part­ners. For exam­ple, sev­eral search engines make usage pay­ments to us for searches made by you (Opera users). This is the major source of income for Opera’s desk­top browser, with rev­enue shares also in place on a vari­ety of mobile products.

… or the same way most browser ven­dors out­side of Apple, Google and Microsoft make mon­key: licens­ing and rev­enue shar­ing. For exam­ple The State of Mozilla 2009 report noted that roughly 85% of Mozilla’s rev­enue comes from their rev­enue shar­ing search refer­ral deal with Google.