Whoops.
I’m kicking myself pretty hard right now. I’ve said for a very long time, “The first step in confirming there is a bug in someone else’s work is confirming there are none in your own.” Once again, I’ve violated my own favorite dictum.
There are bugs in the TreeWalker code I was working on. But what I was writing patches for was even worse: a flawed idea that didn’t match the W3C Recommendation’s text.
I’m going to go back to square one on my work, write a much humbler patch, write testcases specifically for that patch, and then file a bug

.
UPDATE: Bug 260293. This one’s much smaller, and I can back this one up with the Traversal spec.
SECOND UPDATE: Nope. I was wrong there too. TreeWalker spec sucks.

The open source community has always prided itself on the idea that if something is bugging you in an open-source product, you swat it.
How true that is…
Those of you who follow this blog should know I am just now learning C++

. For those of you experienced with C++, I wonder: what are the differences between writing C++ under most circumstances, and writing C++ for Mozilla-based applications? nsCOMPtr was never in my copy of “Teach Yourself C++ in 24 Hours”…

http://www.w3.org/TR/2004/WD-sXBL-20040901/
Thank you, Ian Hickson

. Thank you, David Hyatt. And also Jon Ferraiolo. I haven’t read past the first example, that of inline XBL, and I like it already.

I’ve been thinking for some time that we should really build some sort of <xul:calendar/> widget in XBL. We’d probably use attributes of the element to change the appearance of the widget (say, one arrangement might be a grid filled with calendar dates, another might be a month-day-year trio of menulists, another would be a day-month-year trio, etc.). A common binding would support the implementation and event handlers; the content bindings would each correspond to a particular view of the element, as determined by attributes

.
Does anyone want to start writing one?

A few days ago I wrote about a possible security hole I’d discovered in my own work, and the process I went about in closing it safely.
However, it now occurs to me that, although my particular use-case was protected, the eval() function itself is still a very dangerous function to call from JavaScript chrome.
This is particularly true if the application has loaded the JSLib input/output module, and thus has enabled the application to directly access the filesystem of the client. Chrome files operate in a scope outside the security sandbox model web developers tote (with good reason) as gospel. However, even without JSLib, it would not take a hostile input source long to duplicate the include() function from jslib.js…
Bug 88314 @ b.m.o is an ancient bug for reviewing dangerous eval() calls from chrome. I’m beginning to think that quite frankly, this is not enough! I’m beginning to think that Mozilla would be very wise to completely disable the eval() function when running from chrome, and throw an exception instead.
Here, it becomes a matter of opinion: who’s responsible for security in the context of a Mozilla extension? Taking my own project as an example, I very nearly allowed a potential security hole into the 0.1 release.
The hole isn’t immediately obvious; the exploit would require loading a template with evil code to execute as an mEdit:execute attribute. Unfortunately, in an effort to be friendly, Abacus would allow an application to specify at runtime where to get its data files from. So a web-served page calling on Abacus could insert its own malicious XML data files, and you get the picture from there.
I closed that one, and hopefully I have no others, but it still begs the question: if I hadn’t stopped it, could it have been stopped? The eval() function is part of the ECMA-262 standard, which defines ECMAScript, 3rd Edition. So blocking that one from running inside chrome:// scope would be a violation of ECMAScript.
Who would be to blame if someone exploited eval() for evil purposes from a chrome application’s scope? Certainly the chrome application could be blamed for letting it happen… but Mozilla could also be to blame for making it possible.
I’m undecided on whether I should file a bug at Bugzilla asking for Mozilla to specifically disable eval() in chrome. I’d like your opinions on the subject (particularly those of Mozilla developers and the security group).
I would offer a third alternative, though: requiring a second argument to eval() within chrome apps. Say, eval(expr, testFunc), where testFunc(expr) would return true only if it was safe for eval() to execute the expression. Thus, the implementation of eval() could force an application developer to consider security when writing the eval() call. If the developer simply wrote:
eval(x, function() { return true; });
then there’s no way Mozilla could be blamed when x says:
“var y = new File(‘/usr/bin/mozilla’);y.open(‘w’);y.write(‘you are an idiot’);y.close();”

.
Of course, we could just as easily advise developers to say:
if (testFunc(expr)) {
eval(expr);
}
Comments are open!

XML document identification, and also getting the human language for an element
In Mozilla, figuring out if a document is a HTML document is easy. You simply do (aDocument instanceof HTMLDocument).
If you’re handed a vanilla XML document, it’s also easy. (aDocument instanceof XMLDocument).
XUL docs are handled a little differently; you check to see if it’s an instance of XULDocument

.
But what about XHTML documents?
Thanks to a bug which I believe jst fixed, Mozilla reports (aDocument instanceof HTMLDocument) as true for XHTML documents (content-type: application/xhtml+xml). This is good. Unfortunately, (aDocument instanceof XMLDocument) returns false for the same expression.
To my knowledge, there are precisely two content-types for which a document will be considered an HTMLDocument object. One is the text/html content type, which Mozilla parses as “tag soup”. The other is application/xhtml+xml, which must go through the XML parser.
Because I never know when someone else might come up with a content-type for HTML, I figure any time we get a content-type of text/html, Mozilla will not treat the document as XML in any way.
So, I wrote a little function called isXMLDocument, and it’s included via the link at the top of the page.
Why does this matter? It matters a LOT. Applications processing XHTML documents, when dealing with features which are XML-specific or HTML-specific, must know what’s allowed and what’s not. For instance, XML namespaces are useless in HTML (text/html), but are important in XHTML (application/xhtml+xml). So an application processing a document must know if it should use DOM Level 1 methods (Element.getAttribute, for example) or DOM Level 2 methods (Element.getAttributeNS).
Tag soup for thought.
(There’s a bug I just realized in the filter for getLanguage; the filter will accept in an XHTML document.)

Bug 246668
I was asking myself how to identify the default language Abacus should use, and I realized there’s really no DOM-defined procedure for getting the language of an element

.
This is rather important to me.
I’ve started writing out a little JS to figure out how to get an element’s default language, which is inherited per the HTML 4.01 specification (and probably in XML 1.0 as well, for xml:lang)
function getLanguage(aElement) {
var walker = aElement.ownerDocument.createTreeWalker(aElement.ownerDocument, NodeFilter.SHOW_ELEMENT, hasLangAttrFilter, true);
var rv = null;
var aNode = null;
walker.currentNode = aElement;
if (hasLangAttrFilter.acceptNode(aElement) == NodeFilter.FILTER_ACCEPT) {
aNode = aElement;
} else {
aNode = walker.parentNode();
}
}
rv = aNode.getAttributeNS(XML_NS, “lang”) || aNode.getAttribute(“lang”);
return rv;
}
hasLangAttrFilter = {
acceptNode: function(aNode) {
if (aNode.hasAttributeNS(XML_NS, “lang”) || aNode.hasAttribute(“lang”)) {
return NodeFilter.FILTER_ACCEPT;
}
return NodeFilter.FILTER_SKIP;
}
}

I’m beginning to really hate the usage of the editor element in Mozilla Composer and Nvu. Because the way it’s used in
both projects is a nightmare. Worse, it has worked for ages in this manner, so I may have a hard time convincing
anyone that its diapers need changing.
In Mozilla, the chrome://editor/content/editor.xul file has this excerpt:

<deck id="ContentWindowDeck" selectedIndex="0" flex="1">

<stack>
<editor editortype="html" type="content-primary" id="content-frame"
context="editorContentContext" flex="1" tooltip="aHTMLTooltip"/>
</stack>
<vbox>
<label id="doctype-text" crop="right"/>
<editor type="content" id="content-source" context="editorSourceContext" flex="1"/>
</vbox>
</deck>

Two editors. In case anyone hasn’t noticed, Composer has four editing modes. 2 is not equal to 4, but through some very creative hacking (namely, adding in stylesheets through non-DOM C++ and doing some last-second JS to update the other editor element when it’s needed), Composer makes it work. (Using one editor only would be ideal, but I can see some reasons why that wouldn’t fly.)
This two-editor scheme causes problems for extensibility of Composer. A long time ago, someone filed bug 109682 to add DOM Inspector to Mozilla Composer. I wholeheartedly support that idea and plan on implementing it when I feel I can do so reliably

.
Alas, transactions are broken between edit modes in Mozilla Composer. Just try this:
(1) Open an document in Mozilla Composer.
(2) Add a table in the Normal view.
(3) Switch to HTML Source view.
(4) In one of the cells, write something (Hi Mom).
(5) Switch to Normal View.
(6) Switch to HTML Source view.
(7) Check the Edit menu for the Undo command.
Expected results: Undo is enabled.
Actual results: Undo is disabled.
To the user, this is inexplicable. The user thinks he’s editing one document when he’s really editing three. The first is the baseline document under the Normal view. The second is the document he creates when he switches to Source view the first time. When he switches back to Normal view, all his transactions in Source view become one transaction for the normal editor element — and surprise, the transactions in the Source view get wiped out. So when he goes back to editing in Source view, it’s like starting with a whole new document.
Unfortunately, this particular bug is a WONTFIX per comments in editor.js:

else if (previousMode == kDisplayModeSource)
{
// Only rebuild document if a change was made in source window
if (IsHTMLSourceChanged())
{
// Reduce the undo count so we don't use too much memory
//   during multiple uses of source window
//   (reinserting entire doc caches all nodes)
try {
editor.transactionManager.maxTransactionCount = 1;
} catch (e) {

Now, I can see that being practical when the user puts out bad HTML markup for the Normal view. (What can we do about that?) But even so, a 1-to-1 correspondence based on caret positioning would be MUCH smoother.
To implement DOM Inspector safely, I would first have to force the primary editor to get its update if I’m leaving the HTML source mode. Even so, this doesn’t really fix the undo/redo scheme.
Nvu is even worse in regards to switching edit modes. It uses a tabeditor to let you edit multiple documents. But thanks to the way it’s used as of Nvu 0.2 (namely, to replace the first editor of two in editor.xul and not both of them), when you switch to HTML Source editing mode, you lose the ability to switch documents! This is understandable considering it’s 0.2, but even so, it’s sloppy. The underlying bug, using two editor elements in the first place, forced this implementation. I’d call the loss of tab editing in Source view a major bug.

resource:///res/mathml.css , which I got used to using for XUL apps playing with MathML, wasn’t in my Mozilla 1.7RC1 installed build. Bug 244384 @ b.m.o

.
However, because I could be wrong on the correct reference of the MathML stylesheet, I’ve filed the bug as “UNCONFIRMED”.
On another note, I’ve been wondering just where to put a post-editing stylesheet for the Abacus MathML editor. After all, documents which have been edited through Abacus should not require Abacus be installed to read them…

I goofed (a little)

. If you have an object literal:

foo = {
test: function() {
},
test.precondition: function() { // WRONG
}
}

So I am adding a setContract() method to the ecmaDebug.js library. I’ll upload the latest version in a few more days.
That way, I can say:

foo = {
test: function() {
},
test_precondition: function() { // WRONG
}
}
setContract(foo.test, foo.test_precondition, null);

I also added a bunch of asserts to the contract-management functions. There’s no sense in applying a contract if the contract you apply is bogus (for example, if the precondition isn’t a function or doesn’t have a matching number of arguments).