Burning Chrome

TIMTOWTDI Bugs

Over the past few months, I've stumbled across a baffling class of bug. Basically, the old saying "There Is More Than One Way To Do It," where one way works correctly and another doesn't.

Bug 267050 is one example. In that one, clicking a link works. Entering the link's URL into the location bar and hitting enter results in a crash.

Another is bug 258365. In that one, replacing one node with another leads to a crash, but inserting the latter and removing the former separately works flawlessly.

In a sense, once a bug is recognized as a TIMTOWTDI bug, it's both good and bad. Good in that the person who discovered the bug can always work around it, but bad in that the workaround suppresses a bug. For people who hack the lizard, good and bad here are reversed. Mozilla developers want to know about and to test bugs so bugs can be fixed, but if the user works around it, it just stagnates and bites probably another three or four people who haven't reported it yet. So these kinds of bugs unintentionally and inadvertently pit developers against users, at least in the terms of what the goal is: to make things work right.

I don't really know how to analyse TIMTOWTDI bugs. For all I know, there may be a better-known term for it.

The only idea I have towards supporting both the application developer and the Mozilla developer is for the application developer to include debug-only UI controls for changing execution paths on the fly within their own application.

I'd appreciate some feedback on this, including your experiences with this class of bugs, editorializing, suggestions on tracking such bugs down, etc.

Curses, (they were) foiled again!

I love blogspammers. I found 38 new GMail messages generated in the last two hours.

Oh, by the way, did you notice that I have to approve every comment before the Internet search engines see them?

Whoever you are, you really are an idiot, and your bosses should fire you for making your advertising reach precisely one customer, who ignored your spam.

(Unfortunately, other people who have blogs provided by mozillazine also were victimized by a mass-spam effort.)

Most doomed, continued

Party Like It's 1.999 has just been updated.

Most doomed

Well, as of 10:00p Oct 25 2004, there are 114 people signed up for my party in San Francisco. This puts me one behind the person who is hosting the party in Mexico City (currently in the lead).

I believe that qualifies me for the "most doomed" list of hosts. :) Or, to quote a familiar character: "Oh, boy."

IRC summary of #documentation

Per bernd's comment a few days ago, I had a little chat with fantasai about potential "Doc Days" and the overall documentation effort. I have a rough summary (posted in extended entry) of what we talked about, courtesy of fantasai. We'll be seeing a blog later from fantasai about this in some more detail.

fantasai: WeirdAl posts blog entry about Doc Days
fantasai: http://weblogs.mozillazine.org/weirdal/archives/006711.html
fantasai: fantasai notes concerns with not having a good idea of what documentation needs to be written
fantasai: and therefore not a good idea of how it should be organized
WeirdAl: (roadmap bug)
fantasai: fantasai filed bug against Bugzilla for a READY state
fantasai: which Hixie requests for handling regular bugs
fantasai: (state represents bug ready to be tackled - specs, testcases, description, etc. all good)
WeirdAl: checkins? :)
fantasai: would be useful for docs as well - this request has enough info that random person wanting to help will know what to do
fantasai: another problem with doc bug triage:
fantasai: no flag to distinguish
fantasai: - fix minor errors
fantasai: - major rehaul
fantasai: - write new doc
fantasai: different kinds of bugs
fantasai: people searching for one often don't want to look at unfiltered list including others
fantasai: WeirdAl considers documentation-specific issue tracker
fantasai: fantasai suggests that Bugzilla+wiki+doctor would probably be sufficient
fantasai: and has less overhead
WeirdAl: weirdal agrees
fantasai: fantasai notes:
fantasai: I don't believe that [mozilla.org] docs should be hosted on a wiki
fantasai: but I think that it's a great place to work on them
fantasai: start an article
fantasai: and multiple people can work on it at the same time
fantasai: it's easy to do, anyone can help, make small/large changes, poke it around
fantasai: and not worry about it being scrappy or disorganized at first
fantasai: -- like a public workspace
fantasai: CVS checkin is like publishing
fantasai: current workarounds are a) use your own webspace b) use bugzilla attachments c) checkin to mozilla.org prematurely
fantasai: none is good :)
nilson: So you were proposing to use kb.mz.o?
fantasai: weirdal looks around web, notes existance of www.naturaldocs.org
fantasai: yes
fantasai: points out that auto-generated docs don't handle XUL etc
WeirdAl: (I should note that my thinking at the time was on the level of source-code docs)
fantasai: -
fantasai: Doctor is great for handling "minor errors" category of problems
fantasai: "rehaul of existing docs" and "write new doc" should ignore diffing
fantasai: would be useful to have wiki for document development
fantasai: we look at kb
fantasai: wrt wiki, would need (besides standard editing of articles)
fantasai: a) linking wiki article to bug report (URL field of bugzilla?)
fantasai: b) redirecting to completed document once its done
fantasai: so can move doc from wiki to moz.org
fantasai: but not break links that decide in-progress doc is better than none
fantasai: c) wiki needs to allow direct editing of markup
fantasai: -
fantasai: wrt bug triage, need to categorize by skillset
fantasai: someone looking for something to work on may know XUL but not C++
fantasai: so being able to restrict search to bugs that don't require C++ would be good
fantasai: someone knowing Perl might want to restrict search to bugs that /do/ require Perl
fantasai: etc.
fantasai: applies for documentation too
fantasai: weirdal notes that the tree components for docs in bugzilla are mostly useless
fantasai: consider various reorganizations, nothing conclusive
fantasai: fantasai pulls up kb summary of mozilla products
fantasai: http://kb.mozillazine.org/index.phtml?title=Intro_:_Summary
fantasai: points out that there is lots of useful info there
fantasai: but it's targetted at people interested in mozilla project
fantasai: not downloaders
fantasai: whereas mozilla.org's products page is exact opposite

GMail advertising Firefox?

Anyone know who these guys are?

I've looked at the source code, and it looks like they simply put the Firefox website in an iframe.

UPDATE: Judging by the consensus, most people seem to think it's harmless. I think I inadvertently gave Netiviti more points at SpreadFirefox than they fairly deserve, because so many people looked into it... so I'll probably ask a SpreadFirefox staff member to invalidate the numbers for the next two or three days for Netiviti. Just to be fair to other players in this game.

How about we make Sunday "Doc Day"?

... and on the seventh day, God rested. So do most of our developers, for very good reasons. Sunday is usually the lowest traffic day of any day in any IRC channel.

But we still get people in the channels asking for help. Less, certainly, but not zero.

I'm thinking Sundays would be great days to have a "Doc Day", where we just go through the source code and the docs on mozilla.org and see what we can turn up that needs fixing and/or writing down. The various trees are usually very stable on the weekend, with few checkins.

So what would a Doc Day entail?

At first, not very much! When I tried kickstarting documentation a couple years ago, I fell flat on my face, mainly because I tried too hard to guide everything in a certain direction and we didn't have enough feedback. We might still not get enough feedback on Sunday, but this time around I can afford to linger for 12 hours at a time online.

Probably we'd start out mainly by picking an area that someone wants doc'd, and we'd spend a day on it, gathering notes. Somewhere late in the evening Pacific time (say, 5 pm), we'd probably call it quits on note-taking and gather around one place to start compiling what we learned into a document or two.

I'd host it on my blog (thanks to my saveAsFile.js script), and we'd gather in a channel like #mozillazine to nitpick it and polish it to a submittable draft. The goal would be one major document (an article, an interface's implementation, etc.) a week. Then, I'd probably ship off the draft to Asa or someone else who cares, and we'd get it posted.

One document a week. I think it's doable. Who's willing to help?

UPDATE: But not this Sunday. This Sunday, two of the hottest teams in football this year are going head-to-head. One of them happens to be that of my hometown, beaten only once this year. The other is the defending Super Bowl champions, unbeaten for nearly 20 games.

I'm beginning to think that I'm the Rodney Dangerfield of Mozilla development. I get a lot of things wrong, and that's why I don't get no... :)

"What a marketing coup that would be..."

If Bart Decrem could ever pull this off, he'd have earned his salary from the Mozilla Foundation for a year. At least.

I'm beginning to think that Mozilla Firefox will really take off only after one major Internet Service Provider specifically offers it as an alternative to Microsoft Internet Explorer.

The security and stagnation issues have been well-publicized. Unfortunately, I believe these ISP's (AOL, PeoplePC, Juno for three I've used) either have contracts that prohibit them from offering other web-browser programs, or, equally likely, they feel that their customers want IE and don't care to have confusing alternatives offered to them. Many people want a simple Internet.

It's a clout issue. Convince one of these major (or even minor!) ISPs to offer Firefox as an alternative to their customer base, and you'll have scored the marketing coup of the decade. If just one of these heavy-hitters offered Firefox, the others would take notice.

Branding a Mozilla-based product doesn't sound that hard. Gervase Markham's Patch Maker (a tool I still use all the time when I hack Mozilla) gives as a sample instructions on changing the browser's main title. It's time-consuming and requires a dedicated team of chrome hackers (MozDevGroup, anyone?) to do it right, but it's eminiently feasible. If for no other reason than it's been done before.

It's also a clout issue in that if a major ISP suddenly offered a branded Mozilla Firefox, web developers (myself included) would also take notice. We'd be happy about all the features Mozilla Firefox supports (DOM 2 namespaces, traversal, range, events just to name a few that I care about) that IE doesn't. It would go a long way to convince people who write web pages to support standards a bit better.

In short, I think getting this done would break a hole in the Hoover Dam of web standards.

Now, I don't want to tell Bart Decrem how to do his job. I've met him, and he's got a tough job that he does admirably. (I've tried my hand at marketing before. I know what it's like.) But I'm wondering what the community at large can do. The press has been raving about Mozilla Firefox well before the 1.0 final release. Millions of people have downloaded it and use it on a daily basis. It's reached a de facto 1.0 status unofficially. But if we can't get a major conduit to the general public to offer Firefox (not outright replacing IE, since I don't think any sane ISP would consider that at this stage!), then Mozilla Firefox will probably remain a niche browser that Microsoft and friends can safely ignore. If a certain Firefox marketing site were to ask its visitors to politely request their ISP's offer Firefox, who knows? The beancounters would probably shrug, as both browsers are free to the public.

What a marketing coup that would be: to get an ISP to offer a branded Firefox to their customers.

UPDATE: I should clarify that I don't want people to push a product "before it's ready". I've never wanted that. This blog entry could be misconstrued as saying, "Let's do this now," when it's not supposed to be. My only goal here, as in other blog entries/editorials, is to get people thinking about things like this.

Who likes to party? Who likes, who likes to party?

UPDATE: Oops. Gerv's right.
http://www.openforce.com/mozparty2/?party=67

SF Aviary 1.0 party: Who?

Gervase Markham notes:

The Mozilla Foundation isn't organising a big public party, so those of you in San Francisco have an opportunity to join the rest of the world and roll your own this time around.

Gerv blogs about the Firefox/Thunderbird 1.0 parties.

Given the limited budget of the Mozilla Foundation, this is perfectly understandable. Somebody's gotta throw a bash, but no one in the SF Bay Area has stepped forward yet.

I remember the Mozilla 1.0 party Netscape threw a couple years ago. I still have the 1.0 CD. I gave out a couple copies of my book at that party. The only reason I don't step forward to organize such a party myself is I know the turnout will be (relatively) huge, and I have never done such a big event before...

Who's brave enough to host it in San Francisco?

And why isn't Antarctica on the list? They're already partying...

Which Linux distribution is best for building Mozilla?

For the moment, it appears I may have access to a DSL connection, plus a CD-RW drive. Considering the machine at home is running Mandrake Linux 9.1, and Mandrake's latest version is 10.0, it's probably time for an upgrade.

But which one should I upgrade to? Fedora Core? Debian? Mandrake again? I realize this blog entry may restart some ancient rivalries...

UPDATE: It did restart the ancient rivalries. Would that I had this much commentary on my blog on a regular basis!

So far, I think Gab00n's comment is the most informative for me, even though it didn't answer my question directly. It answered another, more fundamental question.

Maybe I should just ask Alex Fritze what he recommends. After all, I'm really interested in using his Mozilla-contributed SVG and XTF code.

OSCON 2005: Suggestions?

I had a great time at the Open Source Convention this year, and I'm already thinking how nice it would be to go back to speak next year. My presentation this year drew a very small crowd, though -- only about a dozen people.

Obviously I'd like to talk about Mozilla-based technology, but also have it be something the community would be more interested in. So this entry is to invite your suggestions on what you think OSCON should hear about Mozilla. Besides the marketing stuff that Mitchell Baker and Bart Decrem handled so very nicely this year...

One idea crossing my mind is the eXtensible Tag Framework, which just landed on the trunk today. I was alerted to its existence via replies to this weblog, and I am astounded at the concept. It's beautiful.

(For those of you who haven't followed this blog all that long: it just so happens that I have the lowest expenses of any OSCON attendee. My parents live right across the Columbia River from Portland, OR, the convention city. So it's really a nice bonus to go up there.)

Searching for a particular laptop

Okay, now that it's a given that I'm going to be getting a nice check from the Mozilla Foundation, my mind keeps going back to an encounter last July...

While I was up there for the Open Source Convention, I was staying with my parents. Shortly before I left, my eyes landed on an article in a popular computer magazine. What really caught my eyes about this particular laptop were two features: namely, that it was priced at $800, and that you could upgrade its RAM to 3 GB.

Unfortunately, I can't find it anywhere!

I'm looking for a laptop, preferably one that I can seriously upgrade the RAM on. If it has a ceiling of 2.5GB or better, and is decently affordable, I'm very interested. I don't need the RAM now, but I do need the ability to upgrade it later.

(I will admit that 3GB RAM capacity is a bit much. But just to think of it...)

I don't need all the fancy commercial software. I've been doing tech for long enough that I can get products like OpenOffice and the like without paying a penny. The RAM is for building Mozilla. (I once heard someone say they had a 2GB RAMdisk that they built Mozilla on. That idea has me salivating.)

If it's not that expandable but gets decently close, I'm still interested. I don't care if you're selling it yourself or if you know where I can find it; I just don't want a bunch of someone else's cruft built up on it. I'll take used, as long as it's clean.

Basically, I want to find some good products that I can use to hack the lizard, the fox, the bird, and whatever other beasts you throw at me.

Bug 259708: I got the bounty...

Thank you very, very much, Mozilla Foundation!

Saving text from a web browser

When I write weblog entries, I often find myself thinking, "I'd really like to write some markup where the user can just click a button and save what I've written. Uploading files to my weblog is a pain."

Not any longer! Courtesy of the data: protocol, it is now fairly easy to write a fragment of HTML markup and use this script to quickly convert text in a webpage to a format Mozilla can save to your hard drive!

<form action="javascript:void()">
<fieldset><legend>saveAsFile.js</legend>
<textarea rows="10" cols="80" id="saveAs" readonly="readonly">
<!-- Use whatever id you want, and stick the contents you want the user to save in here. -->
</textarea><br>
<button onclick="saveAsFile('saveAs', 'application/octet-stream')" type="button">Save File</button>
</fieldset>
</form>

The second argument is optional; it simply specifies a content-type for the textarea's contents. If you omit it, the script assumes "application/octet-stream", which is commonly used for downloads.

The only downside to this script is it doesn't specify the filename through the data: protocol. That's not allowed in the protocol, so the user has to manually specify the filename. Hence why I included the filename in the legend element.

Here's the script, ready for you to save per the instructions.

Enjoy!

Bug 259708: A human perspective

I've filed good bugs before, innovative bugs, bad bugs, serious bugs, bugs I fix, just-plain-silly bugs, bugs I intend to fix but never get around to doing... all kinds of bugs. But I'd never filed a bug that implied a potential security hole.

In this particular bug, there were mistakes made, certainly by me, possibly by others and the community-at-large. I wanted to take a moment to tell the story behind this particular bug, the part that the bug itself probably won't tell you. I will say this: Bug 259708 is rare among bugs filed at bugzilla.mozilla.org in that it had no truly meaningless comments. So, before I roast anyone, I want to say this one was largely done right.

On to the story...

Bug 153281

This bug has had a high level of interest for me for quite some time. Unfortunately, it has stagnated for an equally long time...

The idea is simple: we should somehow keep a reference to the original document (not letting the XSLT transformation obliterate it) and all the descendant nodes.

I really don't know where to begin looking for ways to fix this one. Getting the original document without XSLT transformations applied would be a boon for web developers.

Planet Bombing

Just take a look at Ian Oeschger & friends' articles which have just about taken over planet mozilla for the moment.

I'm outraged! Today was my day to bomb the planet. :D (You'll see why in a few hours.)

He's "going thermal".

(Don't take this entry too seriously. I'm surprised planet.mozilla.org aggregated an aggregated RSS feed, though.)

D-composing continued: A partial BigDecimal implementation

BigDecimal in D

Feedback welcome!

If you're on Firefox, update your product now

Here's why

If you aren't running the Preview Release, you need to update to 0.10.1 right now for security reasons.

If you are, the page above offers an XPI to update your Firefox 0.10 (aka PR 1.0) build.