The Inside Track on Firefox Development.

« April 2006 | Main | June 2006 »

May 31, 2006

I Hate Comcast

We use Comcast for Cable TV and Internet services. I last paid them by credit card some time ago, and must have forgotten to set up automatic payment (probably because no one on the phone when you call them seems to know how, and their website is mysterious and useless, and as an internet customer you get no information about how to log into it). While we were in New Zealand, they suspended our service for late payment. What follows is the set of steps
we had to go through to get it reactivated. While I understand this is probably mild in comparison to the experiences of some, with a whole variety of service providers, I still think some public shame is required.

DAY ONE (Saturday)

When we arrived back we found a note in the mail with a Comcast letterhead saying that there was urgent information and that I should call some number written in handwriting on the page before 8PM that day (it was dated the day we returned). I called the number and reached a voicemail box which promised I would be called back. I left a message. I was not called back before 8PM.

I called Comcast on 1-800-COMCAST. I was connected to a "customer account executive" who said that the service had been reconnected by having a technician visit and remove a filter somewhere. I was told I would have to be home so the technician could verify that the TV was receiving a picture. I agreed to 8-12 on Tuesday (Monday was a holiday)

DAY FOUR (Tuesday)

I waited at home for the Comcast technician to show up. The TV stayed with "Please wait, channel content available shortly" or some such on the screen. Hours ticked by. Noon came and went. I called and was connected to another "executive". There was confusion. They called "dispatch" and came back to me saying that the technician reported that he had visited the address. I told the person on the phone that no one had come to the door. They pushed a button and all of a sudden the TV came on and started showing content.

I asked if Internet was working now too and they said "oh yes."

I went to work, and when I got home later I checked the internet. It was not working. Any time I tried to visit a page I got sent to some page on Comcast's servers telling me to download a file to install "connection software". Except the file was on http://cdn/ ... which does not exist.

I had a CD from when I got the stuff initially and tried running the installer on that. I ran the installer about 20 times. Almost every time it failed in a unique way. Sometimes it was a JavaScript error. Sometimes it reported that I needed to call Comcast. Sometimes it would show an IE certificate dialog and would then hang. I wonder if anyone actually QA'ed this thing?

In the evening I called back. The first person I talked to said there was a filter on and they'd have to send out a technician on Thursday to remove it. I knew this was BS because I was accessing content off of Comcast's site, just all other sites were blocked. I was sent to an Internet specialist.

The Internet specialist told me that they would turn it on for me, but the database that controlled registration was down for maintenance. Apparently it was down for maintenance every night between 1-4 or something like that.

Think about this for a minute will you. Any Internet company that ran its systems like this would be laughed out of business - and that's web companies that run largely free services! This is a company we pay $50 per month to!

I decided to try again the next day. I asked to be transferred to someone who could set up automatic payment.

The next person said they would forward me to an automated phone system where I would enter my routing number and my account number to set up autopay from my checking account. I agreed. I was transferred. A voice asked me to enter my "sales number". Wtf's a sales number? I pushed #. "That is not a valid Sales Number". I pushed 0#. "To make another call, please hang up and dial again."

So you'd think Comcast would make it easy for people to set up autopay so that situations like this whole ordeal wouldn't happen, but as you can see this is not the case.

DAY FIVE

On getting home from work, tried the internet again. Still no go. Leslie called. After what seemed like almost an hour on hold, she got on to a clueless bottom rung tech support person who said someone would have to come out.

I was listening and told her that the person on the phone was either clueless or lying. We were able to get to comcast's site, so no one needed to come out.

She was transferred to a supervisor. More hold.

More dicking around with the computer (restarting the computer, the router, the modem) and the supervisor pushed a button and the Internet was there.

This is deplorable customer service. Comcast has wasted probably 5-6 hours of our time collectively. Why didn't they just flip the bit in the first place and save everyone the time? The only reason we don't switch to AT&T is that the service there isn't any better.

As an aside, is there any way to communicate to one of these droids that you know what you're doing and don't need to run the script?

Posted by ben at 9:15 PM

May 8, 2006

Code for the Wise

var demo = new Hotness();
if (manager)
  demo.fail();
else
  demo.run();

--- demo-rules.js	2006-05-08 09:59:46.775999400 -0700
+++ demo-rules.js	2006-05-08 10:00:12.809415200 -0700
@@ -1,4 +1,4 @@
-if (manager)
+if (manager && !sacrificeMadeToDemoGods)
   demo.fail();

Posted by ben at 8:58 AM | Comments (10)

Feed Content Now Visible

Today's nightly builds now show some basic entry content for feed entries:

After a2 I'm going to go through and make some more UI changes (see Mike Beltzner's post to dev.apps.firefox for more info) but this is a good start.

Thanks to Robert Sayre for writiing the new Feed Processor which provides a convenient XPCOM component for parsing various feed formats to Gecko applications. After 2.0, we will convert Firefox Live Bookmarks over to use it, and Thunderbird will transition over too. This will provide an excellent building block for RSS/Atom based extensions and XULRunner applications too.

Underneath this is a new scriptable SAX DOM parser which Robert also wrote. Thanks also to Peter Van der Beken for the review of this significant new component.

Posted by ben at 8:31 AM | Comments (10)

May 5, 2006

The "Joy" of XUL?

Firefox's user interface is built using an XML grammar called "XUL" (for XML User interface Language). Shortly after the decision was made to switch to Gecko, the Netscape team began developing a web-based user interface toolkit for the new Mozilla browser. The rationale was that it would allow the application to be built for the variety of target platforms and toolkits once, rather than individually. Without going into a long history lesson that many
of you will already know from other places, this approach turned out to be trading one set of problems for another. But we ended up with some cool and ultimately useful technology as the platform stabilized.

The problem is this: almost all of XUL as it exists today hasn't changed much if at all since it was originally written in the charge to Netscape 6, and as a result the capabilities and problems with the platform reflect the quick cycle and shortcuts that had to be taken.

Today, we're in a difficult spot. XUL and the Mozilla platform at large allowed Firefox 2 to be built very rapidly and have many capabilities, including its popular extension system. Other projects like XULRunner have grown up too. The popularity of Firefox and the perceived flexibility of XUL to an outsider mean that now there are many extensions, and a growing number
of XULRunner applications.

Inconsistencies and Bugs

As I said earlier, very little work has been done on it over the years since the Netscape XPToolkit team moved on. There have been a lot of minor incremental fixes that have made many aspects of the system more stable, but significant bugs and critical failings remain. This is immediately obvious to anyone who has ever built with XUL but who isn't part of the "Mozilla community" where the sort of work that people do sort of self-selects towards the things that XUL is capable of. There is a web of inconsistency (for instance today a colleague of mine asked a question which pointed out that we have several different ways to get the "width" of a XUL widget: boxObject.width, width Attribute, and the width held by the computed CSS style of the object. The problem only gets worse if you extrapolate "widget" to include "top level window". There are also things that just don't work as they should, like layering any kind of complex widgets using the <stack> element (see creative workarounds in the Safe Browsing code).

The Solution

What really needs to happen is a holistic, top to bottom review of the XUL API with significant overhauls where necessary. This sort of review needs to be done from the point of view of "What do app developers expect from modern toolkits" not "what will be possible to implement within the framework of Mozilla". This is a culture thing we have to shake. This is in my opinion the
only way XUL has a chance at being capable of delivering the sort of applications that users will expect to run on their systems in the future.

There are many things that we could be doing now, things that aren't necessarily gated by the Cairo work that's going on, etc. These include building a more capable tree widget, revising APIs, etc.

Why aren't we doing things like this? Well, one reason is I think in many ways as a community we have come to think of XUL as a "frozen" thing, despite the fact that no review or freeze process was conducted on the API. What we're stuck with then is a lot of self-induced confusion and stop energy when it comes to making changes that push the XUL platform forward.

My Opinion

My opinion (just my own, and I know I'm controversial) is that we should break whatever we have to in order to get XUL into good shape. We never said this platform was frozen. We built (inconvient but effective) version restrictions into extensions as a result of this. We actively don't promise that folk using non-frozen APIs won't be broken by new major Gecko versions. So why don't we use this as an opporunity to fix what's broken and take the time to do the right thing by the platform, our developers, and ultimately our users?

I think we should do this to the exclusion of supporting the old XUL APIs. The reason for this is that by adding rather than replacing we increase the overall size and thus complexity of the code. Every time there are two different components that do similar things we raise the barrier to entry for new hackers and we frustrate people building on our technology.

As someone who spends a lot of his time building with XUL, I can tell you it's not a pretty picture. Over the years I have become accustomed to the quirks and I have formed little shortcuts in my brain that I apply when I run into problems. Not everyone has had a chance to do this, and I don't think that they should have to.

Developers Are Users Too!

These days, developers have a lot of platform choices when building their applications. Once you're familiar with XUL it can let you develop applications incredibly rapidly and within it lies true value. We need to take steps to not only to make sure it keeps pace with developments elsewhere in the software world but also to make sure that it lives up to what could be said as being its presently superficial promise of making application development easier.

Sidebar: On the Cairo Transition

Another thing I've noticed people saying a lot is "Oh that will be fixed once we switch to Cairo." and "We'll be able to do that in 3.0". This scares me. I have a very limited understanding of how most of layout works, but it's my understanding that if there's a bug in XUL, the bug is often in the XUL layer itself, or something else like the native widget code or the View system. Changes like the switch to Cairo may make possible a certain class of
toolkit features, but only if the bugs in the layers between graphics and the application developer are fixed.

Posted by ben at 1:58 PM | Comments (34)

May 2, 2006

New Feed Handling Feature for Testing

We have just enabled an experimental Feed Handling feature, which will be available in nightly builds starting Friday May 5 2006. When you click on links to RSS or Atom feeds, you will be shown a preview page that lets you subscribe to the feed using your favorite reader. The idea for Firefox 2 is to also make web readers available as options. We are allowing web sites to register as Feed Readers using a method exposed on window.navigator. As this is not yet implemented, for Firefox 2 alpha 2 we are offering users the ability to customize this through about:config, and we have also seeded the list with a few providers.

To edit your web feed readers, go to about:config and type in browser.contentHandlers.

The preferences work like this:

In each of the examples, # is the next number in the sequence after the last registered set.

Once you have created these preferences for your favorite web service, it will show up as an option in the Feed Reader selection UI.

You can also subscribe with a client application or continue to use Live Bookmarks. To test the feature click on links to RSS/Atom content in web pages, or click the Subscribe icon in the Location Bar when it appears. To change your settings after you've made them, go to Tools, Options, General and click on Choose Feed Reader.

And finally, here's a screenshot:

This is a work in progress, not all of the functionality works yet but it was a solid enough improvement over the status quo (where clicking links that are feeds shows garbage) that we thought it was a good idea to get it out there. File bugs in the RSS Discovery & Preview component in the Firefox product in bugzilla.

See my previous post on feed handling for more information about how this was implemented.

Posted by ben at 4:18 PM | Comments (16)

©1997-2006 Ben Goodger. All Rights Reserved.
Opinions expressed here are my own, and not those of any organization that I may be affiliated with.
Reload icon is © Stephen Horlander;
Firefox logo is by Jon Hicks, and is a trademark of The Mozilla Foundation.
GetFirefox buttons are from rakaz