This week, I had a series of “great” ideas for things I wanted to do with Mozilla code, starting with a gripe from three and a half years ago. Some of them worked, some of them didn’t, and it’s generally evolving.

Tonight’s idea, for instance, was to start using XTF to augment XUL’s capabilities. However, since XUL is a predefined XML language in Mozilla, XTF can’t share the same XML namespace. No problem – a second XML language, plus display: -moz-box, and I’m in business. It’d also mean explicitly defining the public interfaces to these elements in IDL, something I’m not opposed to.

I’ll get back to this subject in a bit, but I need to express another thought here. These two subjects are related, and frankly I’ve been chewing in silence on this other subject for months now.

What’s going on with Mozilla 1.9.x?

I’ve been very concerned about the plans for Mozilla post-1.9. On Mozilla 2, everything I’m hearing about there is fantastic, and I’m chomping at the bit to get my hands on some of it. Mozilla 2.0 final, though, is a very sizable change. I bet conservatively on 2.0 and believe it won’t be ready for at least 18 months. This means I’m very unlikely to start hacking on it for at least six months to a year – except when I want to get patches reviewed for check-in. 🙂

This brings me back to 1.9. Simply put, once it’s out, it’s going to be The Premier Mozilla Application Platform for a long, long time in “software years”. Yet there’s been practically no talk in public on what happens to 1.9 code after 1.9 comes out.

As a professional Mozilla software developer, this worries me. Whatever the plans are for Mozilla post-1.9, there’s been no discussion of them in public. So while everyone’s getting really hyped up about Mozilla 2, out here in the real world, where people are building real applications based on Mozilla 1.8/1.9, we’re left wondering “what’s next”? The leap from 1.9 to 2.0, while exciting, is also scary. The biggest scare, in particular, is “while we’re waiting for this new product that’s going to blow our minds, how do we improve on the common platform we already have?”

There is, of course, an obvious comparison to the Mozilla 1.8.0.x/1.8.1 branches (Firefox 1.5, Firefox 2). The 1.8.1 branch was successful, but there were two drawbacks:

1. The IDL interfaces from 1.8.0.x branch could not be changed. Instead, we had to create new interfaces.
2. Check-ins to the 1.8.1 branch were restricted.

We had 1.9 for unrestricted development, so it wasn’t a real problem. The 1.8.0.x branch was (rightfully, in my opinion) far more restricted after Firefox 1.5 was released. There, it was strictly in a maintenance and security patches mode, much like 1.8.1 branch is now.

If all development on 1.x stops after 1.9 (aside from the obvious security and regression fixes), then here’s the scenario:

• We have this really hot, fashionable — hell, cover-model-sexy — platform that product developers don’t dare touch for a year and a half.
• We have this nice, useful, stable platform for product developers that isn’t getting any new bug fixes, except for security and regression fixes. Which means the two tons of bugs that product developers have now, they’re stuck with.

This scenario, for me, is a problem. I’m all in favor of both of these… but I also think we need a middle ground. Something we can work on from 1.9 that doesn’t break backwards-compatibility, but lets us continue on a major milestone path, checking in much like we have for the pre-1.9-release cycles. It’s a contingency for corporate consumers of Mozilla-the-platform, who find themselves with too many nasty bugs that just couldn’t get fixed in 1.9.

Which, finally, brings me back to my original point, and subject matter of “Overwhelmed”.

Even 1.9 leaves a lot of Bad Bugs laying around

Tonight, I decided to start work on a personal copy of the Mozilla source. I have traditionally maintained a single tree per system, and that tree I’ve kept nearly pristine. However, I’ve also fallen into a forest-for-the-trees trap, where I look at individual bugs-of-the-moment without considering what has bothered me for years. At present, I’m directly cc’d on, the reporter for, or the owner of about 600 open bugs in mozilla.org’s Bugzilla. I can’t possibly fix all of them quickly (and keep my day job), especially since reviewers themselves are also perenially swamped.

So I went through the list and tried to figure out which bugs and missing features I considered critical – things that make my life as an editor and software developer harder than they should be. I expected to find 10 to 20. I found over sixty:

* Spreadsheet controls
* Scrollable content model
* nsITransaction* enhancements
* bug 380089, XPCShell tests
* Exposing TransactionManager to web content (maybe)
* Veto Transaction capabilities
* Nested transaction listeners
* Bug 362694, Noticeable perf issues with transaction components.
* Bug 204793, Editors need procedure for using alternate TxMgr
* bug 369571, Make nsEditingSession extensible (makeWindowEditable) via JS components
* IPC (bug 68702)
* Unnecessary exceptions (see https://weblogs.mozillazine.org/weirdal/archives/018562.html)
* XPCOM/XPConnect enhancements
* bug 380169, nsXPCWrappedJSClass::CheckForException needs a way to silence XPConnect reporting component errors temporarily
* bug 392004, Resurrect nsIScriptableInterfaceInfo and friends
* bug 228205, Redesign nsIConsoleService and related APIs
* Component property localizations
* JS to C++ XPCOM rewriter Perl script
* C++ to JS XPCOM rewriter Perl script
* bug 229824, Add function stack trace to DOM exceptions
* bug 389370, JavaScript stack frames through DumpJSStack are usually one line off
* RegExp support from C++ (bug 106590, bug 348642)
* bug 381191, [meta] Reduce code duplication in js xpcom by using the import module (XPCOMUtils.jsm)
* bug 383566, Imported module objects can have their properties reset
* DOM bugs
* Better XPathNSResolver implementations
* bug 304514, nsContentIterator::Init(range) doesn't consider Document nodes
* bug 247397, Spit Warning to javascript console when a document contains duplicate ids
* bug 283861, Want Text3.isElementContentWhitespace
* bug 166419, Mozilla's DOM Ranges don't support comment nodes
* bug 157373, Range.selectNodeContents(document).toString() returns ""
* bug 366944, Range.surroundContents doesn't check node type early enough
* bug 383650, Provide API for getting a nsIDOMCSSStyleSheet from nsIStyleSheetService
* bug 302775, extractContents doesn't work if start and end node of a Range object is an attribute node [@ nsContentSubtreeIterator::Init]
* bug 332148, extractContents clones nodes when it should just cut them
* bug 306058, tabindex attribute on XUL textbox breaks tabbing backwards
* bug 370031, Cycling through tabindex among HTML inputs only works once
* bug 383109, Tabbing order does not follow specified tabindex order
* bug 344850, Tabbing from <radio> or <textbox> with tabindex fails
* bug 315805, setAttribute("xmlns", "...") should throw
* bug 318086, No XML Declaration when serializing
* bug 326745, Support XPath in Mozilla crossing content boundaries
* Support XPathGenerator in Mozilla crossing content boundaries
* bug 330426, Script elements in XUL documents have no child nodes (with inline scripts)
* bug 42976,  Implement cloneNode() for XUL and HTML Document nodes
* bug 73681,  Child Nodes of Attr Nodes have a parentNode property set to null.
* bug 269482, Allow <svg:use> to reference elements in other documents
* bug 288513, add support for DOM 3 setIdAttribute*
* bug 69799,  External entities are not included in XML document
* bug 352539, Implement SAX InputSource
* XTF bugs
* namespaced attributes
* bug 346754, Kill append related methods and enums from nsIXTFElement
* bug 358257, Add support for XTF attributes
* XUL bugs
* bug 312869, Support XUL textboxes accepting new context menu items
* bug 367009, Radio elements always assume to be in a radiogroup
* bug 362321, XUL decks assume the selectedIndex attribute has been set
* bug 246407, <xul:textbox type="file"/> is recursion-happy
* Testing bugs
* bug 384339, The check-interactive code executes head, tail scripts before the user runs
* bug 360294, XR (XULRunner) testing infrastructure (mochikit-like)
* bug 359830, Simple make check target for running xulrunner based unit tests
* Custom JS modules
* ArrayConverter.jsm
* ecma-debug.jsm
* XMLValidator.jsm
* XPCOMUtils.jsm service improvements

That’s “overwhelmed”. Even with ten percent of the original bug list, it’s still one hell of a lot

. Factor in my day job, plus helping out with OpenKomodo / building Verbosio, plus those “bugs-of-the-moment”, and I can suddenly understand why I’m thinking, “Yeah, 1.9 is going to be good, but… it’s just not good enough.”

Plus, we’re already very late into the 1.9 cycle. Very few, if any, of these would make 1.9 at this point. So I don’t have a choice – I can’t stick them into 1.9. I don’t want to try sticking them in a 2.0 build that may undergo radical changes, to where code that passes reviews for 1.x wouldn’t be taken for 2.x under the new Mozilla C++ styles. I need these fixes, and I hear no news that confirms there will be a home for them.

Barring a 1.9+ repository and plan which allows these real improvements — not just security, not just regression-fixing — I’m pretty much isolated until Mozilla 2 matures. That means I can’t offer real-bug fixes to a community, and I can’t get real-bug fixes from a community. That is what worries me.

Conclusion

I’m not posting this as a rant against the Mozilla Foundation for their management of the repository or their resources – on the whole, they’ve done quite frankly a pioneering and fantastic job. I’m posting this primarily to see if, in the event that the repository managers decide not to offer a middle-road approach like the one I came up with, a community like MozPad (which really is bigger than Matthew Gertner) can offer that middle-road. I’m posting to see if there’s room for hosting a community fork _{(all right, I finally said that four-letter word, I really wish I didn’t even bring it up or think about it)} of the source code, where development can continue with at-least-unofficial milestones for the community – which isn’t entirely lonely, irrational hackers in their apartments. (I at least hope I’m not irrational.)

If there’s one thing I can critique the Mozilla Foundation on, it’s on not having a discussion in public about 1.9 code after 1.9’s release in the face of Mozilla 2. Your community cares, guys. So do corporate customers which help to evangelize you. Please, if you’re going to make the decision without our input, at least tell us what you’re thinking.

(P.S. Somewhere in here I meant to make an Apache 1.x versus Apache 2.x analogy. But I’m not familiar with the history of the Apache project, and I just couldn’t find a spot for it in here anyway.)