In the process of converting my remote XUL apps to use Firefox 1.5, I found a bug in <tree>.
The column picker breaks when you've added things to Array.prototype. That took many hours to find, after removing and re-adding
countless lines of XUL and javascript. It came down to some functions we were adding to Array.prototype in one of
our libraries. When I commented those out, it worked just fine. I installed the
Console2 extension, which gives some better
error reporting, and found the a javascript error occurring in a file called tree.xml. It was a mess of XBL,
but the problem was apparent.
The orignal code:
|
| var hidden = !tree.enableColumnDrag; |
| const anonids = ["menuseparator", "menuitem"]; |
| for (var anonid in anonids) { |
| var element = document.getAnonymousElementByAttribute(this, "anonid", anonids[anonid]); |
| element.hidden = hidden; |
| } |
The problem is the usage of in. in is rather introspective, and will iterate over all
the properties on the object, including user-added functions.
My guess is the author of this code is used to the Python in keyword, which
just iterates over the values in the object. I figure changing that to not use the in keyword should solve the problem:
|
| var hidden = !tree.enableColumnDrag; |
| const anonids = ["menuseparator", "menuitem"]; |
| for (var i = 0; i < anonids.length; i++) { |
| var element = document.getAnonymousElementByAttribute(this, "anonid", anonids[i]); |
| element.hidden = hidden; |
| } |
To test this out, I went into my Firefox chrome directory (C:\Program Files\Mozilla Firefox\chrome for me),
unpacked toolkit.jar, and made that change in chrome\toolkit\content\global\bindings\tree.xml.
Console2 let me know where to look. In
order to get Firefox to read my files, I had to edit chrome\toolkit.manifest to look in the unpacked
directory instead of the jar.
Original toolkit reference:
content mozapps jar:toolkit.jar!/content/mozapps/ xpcnativewrappers=yes
New toolkit reference:
content mozapps toolkit/content/mozapps/ xpcnativewrappers=yes
Now that Firefox is looking at the unpacked source with the updated tree.xml, I restarted Firefox and
saw that it worked. The next step was to file a bug, and submit a patch.
As this was the first time I filed a bug at Bugzilla, I did it wrong.
Asking
around on #js, Hannibal kindly told me to make a diff from CVS, and request a review. I had to install
cygwin, and
partially followed Jeff's instructions for
setting up an MSVC toolkit Firefox/Thunderbird build environment.
I wasn't concerned with needing to actually build it, so I only followed the bits about cygwin.
After getting a bash shell working, I followed the
Mozilla Source Code via CVS
instructions, and got the source on my machine. The build failed, but I didn't need it to build me anything, I just needed all
the source.
Once I had the source, it was all very easy, following the
Mozilla Source Code via CVS verbatim.
After some browsing, I found a policy page for Toolkit patches, the
Tookit Review Requirements.
From there I uploaded my patch to my bug, and
requested review. Within an hour or so, my request had been bumped to another toolkit dev, (the original guy is on vacation),
and my bug's status had gone from UNCONFIRMED to NEW, and its looking to be put in the mozilla1.9alpha1 milestone.
So, it looks like I might get a very trivial piece of code into Firefox, and have learned a lot more about how Mozilla's internals
work, and how open source development works. If I get ambitious, I might get the source for other Mozilla projects and see
if I can contribute to those.