Over the last couple years, the Mozilla code base has evolved significantly on the trunk. Unfortunately, development on the JavaScript Debugger has not kept pace - the code has "bitrotted" significantly, and introduced significant bugs.
This is a serious problem. It's equally serious that no one is hacking on it. I've found it to be a very useful tool for working on chrome code, and XULRunner apps would benefit from having a debugger handy.
So here's what I want to do. I want to schedule a weekend meeting for 2 pm PDT Saturday at #venkman on moznet. The goal, as I see it, is to plan fixing Venkman so it is usable on the XULRunner 1.9 platform. (Getting it working on Firefox 3 would be a nice thing, too.) I want to see who's willing to contribute hours (weeks, more likely) of coding and/or reviewing to this goal. In particular, I'm worried about trying to find out whatever API changes are needed in Venkman itself (not what API Venkman has to call) and getting them in before 1.9 branches.
Watch this space for more details; I'll write up a draft plan for the meeting, so we have some things to think about.
UPDATE: So, here goes:
First thoughts - Venkman isn't quite as bad off as I initially thought. I tried to install a 1.8-based XPI on the 1.9 XULRunner build, and that didn't work very well at all. When I finally figured out how to build a Venkman XPI:
export CONFIGDIR=(...)/mozilla/config/ cd mozilla/extensions/venkman/xpi/ sh makexpi.sh
Everything seemed to be okay. Starting Venkman via
window.open("chrome://venkman/content/", "_blank", "chrome")
works. But it doesn't take long to notice a few oddities.
Ultimately, I think these are all fixable. The real problem, as I
mentioned earlier, is a lack of current contributors. Venkman, like
Inspector, has been neglected for quite a while. There are 136 open bugs
against Venkman right now. (Inspector's been doing much better lately.) Looking at
extensions/venkman/resources/content/ right now, there are a lot
of "2006", "2005", "2004" files... meaning that exactly one file has been
touched here in over eight months! 136 bugs + eight months bitrot means an
effectively unowned module - or a super-stable, frozen one. :-) Given the
fact this is on trunk, and the above very-obvious bugs, I'd say it isn't the
latter.
So here's what I propose: for 1.9.0, we need two or three chrome app experts to spend a few days fixing the above issues, and reviewing patches. Next, we need to go through the bug list and triage it, both for priority and time constraints. If there are any IDL changes needed, those should go first in the bug list because we'll have a harder time getting such changes in 1.9.1. (There aren't likely to be very many.) We should start planning for 1.9.1 - whatever it is - right away. For 1.9.0, I think we're effectively in maintenance mode - there's too little time for big changes.
If we somehow find the time, (i.e. we decide that all the high-priority, low-risk issues have been fixed, and we don't want to chance further 1.9.0 changes), we should probably write a miniature XULRunner app with a known set of bugs and start running Venkman against it. This becomes a "reference" application for Venkman testing.
Reviews for new patches should emphasize both tests and JavaDoc'd functions. I'd love to see some xpcshell tests of the jsd code which Venkman depends on.
We need to start putting out "nightlies" of Venkman, and making them available for trunk usage. The simplest way to do this might be a bit of tinderbox adjustments. Fortunately, building a Venkman XPI takes only a few seconds.
So who's willing to spend time on this? The good news is that Venkman's code is mostly XUL + JS, so you don't need C++ hacking skills to fix many of the bugs against Venkman.
With many thanks to Dave Townsend and Robert Strong for reviews, Mozilla trunk builds now support extensions for "the toolkit" - meaning any XULRunner app which uses the toolkit. This will also be true for the next milestone, and (barring something really unusual) Mozilla 1.9 and the next major XULRunner release.
I can think of several extensions which would be good candidates:
The bug for DOM Inspector has a pretty simple example of how you'd add support for the toolkit to an extension. It's less than ten new lines, added to install.rdf.
There's also a nice side benefit possible here: extensions for another application - say, Songbird - which don't need to be for just that application could port easily over to Firefox with the toolkit target.
So what determines if an extension should be for "the toolkit"? First, you need module owner or author's approval for that extension. :-) Second, it shouldn't be specific to a given product or written for a given application - for instance, an extension for browser history doesn't qualify. On the other hand, if it adds more tools (a new SQLite database, for example, or a spell-checking dictionary - thanks for the idea, KaiRo) or capabilities without requiring that the app be a browser, a mail client, a multimedia player, etc., then it should be fine.
I'd invite fellow developers to start experimenting with this, and generate feedback. Any bugs to add "the toolkit" as a supported application should be marked as depending on bug 299716. Also, any other missing support for toolkit extensions we need bugs on, depending on bug 299716. We need eyeballs!
P.S. Congratulations on document.elementFromPoint(x, y), Mr. Karel. That's very useful, too.
(No offense to our Chinese readers or their communities is intended.)
There have been quite a few major storms lately. Erin has dropped to a tropical depression out in the Pacific. Hurricane Dean's making a mess in the Caribbean and the Gulf of Mexico. (Category 4. Oh, boy.) One storm we're not hearing much about in the U.S.A., though, is Super Typhoon Sepat. It's heading northwest, straight for the heart of China, with a pit stop in a rather controversial island. The Phillippines already took a hit from this one. (I call it a Super Typhoon because earlier stories rated it a Category 4, though right now I think it's somewhere between 2 and 3. Still a monster, though.)
I was browsing around on Google News this morning before leaving for work, trying to find out a bit more. Most of the headlines were appropriately serious - but one of them didn't make a whole lot of sense. From the Shanghai Daily: Typhoon Sepat to cool city over weekend
I'm sorry, but I burst out laughing when I saw that one. Only in China is a super typhoon considered good news.
(The story does mention the seriousness of the storm leading to closures and heavy weather preparations - but in the typical reverse-pyramid style of newswriting, lesser facts are put at the end of the story. As a former Journalist for the U.S. Navy, I can say this story is written that way. Apparently, the danger a massive storm brings is less important than shaving a couple degrees Celsius. Go figure.)
For the last few months, I've been doing Verbosio development based on Mozilla milestones (as opposed to the trunk). Each of the last few milestones has brought a change which impacted Verbosio. I didn't spot any for 1.9a7, and I thought the migration would be nearly painless.
There was a change impacting Verbosio - and depending on the point of view, the result is either trivial or damaging.
Several months ago, I blogged about XPCOM class invariants for JavaScript - using the nsIScriptableInterfaceInfo interface. The code for this interface lives in extensions/webservices... which was shut off with SOAP. Oops.
I filed bug 392004 to resurrect it, but even as I do this, I realize there's not much use for having it on by default. (Otherwise, people would have complained about it much, much sooner.) Sure, it benefits me, but between one developer's convenience and millions of users's Firefox installs, a few extra kilobytes are expendable. Even for XULRunner 1.9, I expect it would be a tough sell.
The simplest solution, of course, is to disable the invariant contracts when they can't be built. I should've done that in the first place. Invariants, though, add valuable sanity checks. So to get them back, I have to compile the scriptable interface info code as part of Verbosio.
There, I said it: "compile". With that one word, I have overshadowed one of those little goals I had for Verbosio from the beginning: that you could take an unmodified XULRunner and run Verbosio. It's ironic, considering Benjamin Smedberg quietly taught Firefox how to run XULRunner apps like Verbosio - and thus expanded the potential user base by a factor of five thousand. (I meant to blog about that in particular.)
Naturally, I can ship the necessary .dll, .so or .dylib files with Verbosio - just pre-compile them. By all rights, I should. I'm not sure if I can ship a DLL file compiled from Visual C++ Express, though - which means spending a few bucks getting Visual Studio.
I have only myself to blame for all this - not just for relying on an extension, but for not planning for C++ code to enter the picture. Sure, it sounds like a lot, considering this is for debug-only code. As a developer, though, I like having as much debug code on as I can get while I'm crafting the app. Live and learn...
Generally speaking, when I post requests for help on my blog, it's for some little bug that has me stumped. This time, it's for something longer-term.
The company I work for, DVC Labs, wants Mozilla experts. Simply put, we're swamped right now and will be for the foreseeable future. We're also pushing the boundaries of what Mozilla can do, with an interesting twist that I can't talk about publicly. (Start-up life. You know how it is...)
So if you happen to be a Mozilla developer frustrated with where you're at right now, or you're looking for one of those once-in-a-hundred-years, win-the-lottery types of deals (I won't go so far as to claim "Google-IPO" type of deal... I'm not that brash), ring my company phone. I'll pass it on to my supervisor, and we'll go from there.
(E-mail removed, as I only got one actual response and a couple dozen spam since.)
It occurs to me that various people are working on editing tools or extensions to Mozilla to support editing. I know of some of them:
All things considered, that's quite a list. Each individual contributing has their own itch to scratch, and the projects don't really compete with each other. (You might argue that ETNA and Verbosio compete, but I don't see it that way. Verbosio's an experimental project right now.)
Three of the others I met through Mozpad. (ETNA we haven't heard from yet, but we haven't gone out of our way to invite them either. Oops.) This makes me think we could form a small working group over at Mozpad - not for the IDE (which is apparently going to be Eclipse), but for smaller editing applications.
What would this new group try to do? I don't know yet. I suppose the starting point would be for us to share ideas and code - and avoid duplication of effort. I personally doubt we'd try to develop a common editing tool anytime soon, seeing as our efforts are going in different sub-sets of editing right now, and we're all pretty busy. I think my initial intent is to answer questions from community members about what work is going on in the editing space, and who's doing it, and how developers could contribute.
Then again, maybe none of us have the time for that...
UPDATE: Okay, so ETNA is alive and well. I just haven't heard much about it lately. (It's not my fault Laurent isn't on planet or the moon. :-) )
I was just thinking Friday @ noon Pacific time that any such group as I describe above should probably start with a simple wiki page on mozpad saying "Here's what editing tools work is going on, and who's doing it." Then I don't have to guess about who's doing what. :-)
After eighteen months of "try, try again", the first version of XPath Generator code has landed in Mozilla 1.9 "trunk" code. It is currently off by default.
I'm quite pleased with this. This is the first complete feature I've driven from initial API drafts to a final implementation in Mozilla CVS.
So how do you use it? First, you need a build with ac_add_options -enable-extensions=default,xpath-generator. Once you have it, your chrome code should be able to call:
var generator = new XPathGenerator();
generator.addNamespace("html", "http://www.w3.org/1999/xhtml"); // optional, but recommended
var xpath = generator.generateXPath(targetNode, contextNode);
nsIXPathGenerator details two currently supported flags for the generator's searchFlags property. IGNORE_ID_TYPE_ATTRS means that the XPath should not stop when it finds an ancestor with an ID attribute. USE_DESCENDANT_AXIS produces a single-step (in the case of attributes, double-step) XPath beginning with descendant::.
XPath Generator objects also provide their own namespace resolvers, which as I note above can take new namespace declarations via the generator's addNamespace() method.
Sadly, this implementation excludes support for attributes in the XPath (foo[bar="baz"]); based on review feedback it didn't seem necessary for the initial implementation.
So why is this feature off by default? It's new. Aside from myself, I don't know anyone actively using my XPath Generator right now. Because it's so new and untried, we (myself and the reviewers) decided we should not expose the generator to web pages just yet. For that reason, we left it off by default as well. Finally, because it wasn't on by default, it didn't land for the 1.9a7 milestone.
If you are a developer and you see yourself needing or wanting XPath Generator, you have two options. (1) Start playing with it now, and see what improvements you'd suggest (patches welcome). Your experiences with XPath Generator - including actually using it - will carry weight in any attempt to get it approved for Firefox 3. (Popular opinion & votes will not.)
(2) Package XPath Generator as an extension and submit it to AMO, and include it with your own extension as a multi-item package. If you're going to do the latter, please contact me and let me know. Ideally, it would be submitted only once.
Either way, I really would like to find out how useful you find XPath Generator in your own work.
In the meantime, I need to work on making it and other extensions available to all Gecko-based apps...
Oh, by the way, there's also a new do_parse_document() function available for XPCShell tests. If you have a particularly slow Mochikit test that doesn't need a window, you might want to rewrite your test to work using this new function. (Come to think of it, there could be a significant speed-up in total test execution, if we converted many tests and if text/html for DOMParser landed.)
(Now why do my most significant events take place on weekends...)