This week in the evenings, I've been banging on the inter-process communication (IPC) bug to try and get it working for me, with little success. I finally remembered about noon today that your standard output stream is buffered. So now my blocked testcase has been hit with a plunger (pun intended).
So among the several things I tried was a NS_ERROR break in the IPC code, along with GDB, the GNU Debugger. Here's roughly how it turned out...
GDB: What'cha doing? XPCShell: Watching the Web, having a bug. GDB: True, true. (phone rings) XPCShell: Hold on... Hello? run_test(): Whassup??? XPCShell: Whassup??? run_test(): Hey, where's Perl? XPCShell: Let me check. (shouting) Yo, Perl! Hey, pick up the phone! IPC: Avon calling... Perl: Just a minute... let me start up... (grumbles) Hello? XPCShell: Whassup??? Perl: Whuzzuuuuuuuuuuuup? run_test: Whassup??? Perl: aaaa XPCShell: aaaa run_test: aaaa IPC: aaaa GDB: (click) XPCShell: aaaa IPC: aaaa... assertion! *cough* *cough* *hack* (silence) Perl: ... XPCShell: ... run_test: ... Perl: ... run_test: ... XPCShell: It wasn't me. (user quits XPCShell, and the party ends.)
(With apologies to Budweiser, Shaggy and of course, Charles Stone III. Can we get a Red vs Blue PSA on this?)
While I wrote this to let off some steam, the important thing here is how GDB -- and XPCShell -- reacted when the assertion tripped: GDB remained attached, but for some reason when the assertion tripped, GDB didn't break on it and XPCShell didn't stop executing. GDB's "set detach-on-fork off" (which GDB itself suggested) didn't help much.
This presents an interesting problem. Assertions are fatal, but XPCShell didn't die from it in this case and GDB didn't pick up on it.
I'll file a bug on it later, if I can be convinced that I didn't miss something with GDB. GDB and I have not always understood each other.
That may change. The big reason I undertook IPC is to wrap GDB in a Mozilla app for debugging other Mozilla apps. You would be wise in asking, "Why another debugger? We have Eclipse, GDB, WinDbg, XCode, Visual C++..." The answer is two-fold. One, it would be a common platform using technology Mozilla developers are very familiar with. Two, it's way past time we built a XPCOM debugger - something that can take the native C/C++ stack and translate it into a multiple-language stack (JavaScript, C++, Python if Mark Hammond's feeling generous, et cetera).
Linux and Mac have GDB, and Windows has a little-known equivalent called CDB. If I can drive them via IPC, then I can write a common interface for components to drive them. One more layer of abstraction, and I can translate js_Interpret, js_Invoke frames in the C++ stack into JS frames in a XPCOM stack. From there, we're rolling.
I'm tentatively calling this project Coroner. We'll see how it goes.
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.
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:
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:
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".
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 http://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.
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.)
Components.Exception on LXR
A long-standing custom in Mozilla code for XPCOM components in JavaScript is to throw Components.results.NS_ERROR_FAILURE or something like it. However, Components.Exception is more useful, particularly since it lets us component authors define our own error messages to go with the error code. Plus, it's been around for quite a while.
It's actually pretty useful, I've found. I'm wondering if we should add this to a list of to-do's for Mozilla 2.
I spent another six hours on this, and I'm fairly pleased with the results. The bulk of the code is now in a new SnapGrid.js library file. The features:
It's another proof-of-concept, but this time for something much smaller than Verbosio. Hopefully, if I've designed it right, I can rapidly expand it to cover other shapes and, more importantly, the SVG path element...
Last night, I was thinking I'd really like to have a JavaScript-based SVG editor. There are some really freaking sweet examples out there. But there's something missing from all of these, which surprises me in retrospect: SVG snap-to-grid support.
Freehand drawing is nice... unless you want precision. Sadly, the human hand (mine, at least) isn't that accurate with distilling individual pixels. If I can get close enough with the mouse on a zoomed-in view, though, and I can see a grid indicating pixel coordinates, maybe the application can round off my mouse position to the nearest real point, and give me a visual indicator. Like this snap to grid example, which I put together in about two hours.
Right now, if you load the example, you can place a point by hitting a key on the keyboard. This is in keeping with the idea that controls should be accessible without the mouse. Unfortunately, I haven't gotten into maneuvering points with key strokes. Nor have I factored in any kind of zoom & pan capabilities - linear algebra is not one of my strengths.
Over the next few days, I hope to turn this code into an actual class, similar to a Dojo-style library. I might even make it a XBL binding. Ultimately, by being able to precisely identify coordinates, I could plug coordinates directly into shapes such as SVG paths (Bezier curves made simple), rectangles, ellipses, etc. I could even build interfaces to create classes of polygons. (I want my <svg:triangle/>!)
You might wonder why I'd work on yet another SVG editor, when there are so many out there. There are two reasons. First I didn't see any examples that would really be compatible with running inside a Mozilla framework, besides the ones above. They're usually stand-alone apps. The examples above are exceptions to that rule, but (this is the second reason), the first two are not explicitly licensed under an open-source software license (no explicit license, and Creative Commons, respectively). Mark Finkle's work is under the MIT License, but it's HTML based. Nothing wrong with that. It just strikes me as unnecessary if the only platform you're targeting is Mozilla. Mark's targeting IE, too. My use case is simply different.
On the other hand, if I keep it as a JS-based constructor (instead of XBL), that would make it easier to port to other platforms, such as RichDraw.
Food for thought.
