Wednesday, October 10, 2007

Extension Development, and Trials and Tribulations Thereof

Well, I am almost done with an extension I am developing for a third-party company. Wow! Was this ever harder than I thought it would be....

I had some slightly complicated things in the extension. 2.5K lines of javascript, a custom XPCOM component, a status bar icon, a toolbar popup button, a sidebar, and a partridge in a pear tree thrown in for good measure. The app was crashing on exit. Actually only FF 2.* was crashing. FF 3.* was fine.

So, I am doing a bunch of different kinds of allocations and there are listeners and so on. I figured I was doing something wrong with the memory. Much staring at the code. Much re-reading of dbaron's docs on this stuff. Much more staring at code....

Turned out it was this:


<toolbarbutton id="id1" type="menu" popup="id2">
<menupopup id="id2" />
</toolbarbutton>


I thought that all this memory stuff might have a problem, and it turns out to be something bone simple! It is amazing what taking a machete to your code can show you. Along the way, an amusing thing happened. I took the image attribute off the toolbarbutton and I got this:



And someone said this was ok! I might try to guess at the logic, but I cannot make myself do it. Obviously, some people are very immersed in how XUL gets rendered. I hope I can learn enough to understand it. I hope I never forget that its contortions are, after all, contortions.

Next things to do now that this monkey is almost off my back:

- do an extension for rule-based qualification of XUL, because you need something to tell you that you can have A, B, and C together, but C makes B have no effect, and C without A does something totally different. Look at a given XUL reference. It inherits all its parent's attributes. Now, how many have any effect? How many break everything? There has got to be a way to get information about this.

- figure out something to help me search bugzilla. I looked for bugs on this many times and did not find it. Maybe it is because the relevant bug was marked for Windows. Maybe it was because the title mentioned <menupopup> and not <toolbarbutton>. Maybe it was because the title said it happened on window close and I was searching for "quit". I do not know. I just know I truly hate trying to find things in bugzilla. But when I suggest changes to bugzilla, they seem to hate that even more. I have no idea why. So, I just obviously need to construct tools to help me get around this thing. There has got to be a better way to find bugs than creating new bugs and letting gavin find the dupes. For one thing, this is not fair to gavin, or neil, or reed, or whoever it is.

- and some other things I am sure I have forgotten. We'll see.

4 comments:

bsmedberg said...

The most common bugzilla-searching problem is that people choose search parameters that are too restrictive: unless you have specific needs, the "find a bug" form at https://bugzilla.mozilla.org/query.cgi?format=specific is the best way... you can try a couple search terms to see what you get.

Of course if you have a crash, you can also try searching for bugs with your crash signature, as determined by talkback/crashreporter or by your debugger and the symbol server.

Neil said...

Image attributes should rarely be necessary in correctly designed XUL; images should nearly always be coded in your skin as list-style-image (and optional -moz-image-region) style rules. (Favicons are an obvious exception to the rule.)

Wladimir Palant said...

The "funny" thing already "happened" to pretty much everybody who ever worked with toolbar buttons in Firefox. Reason is the following CSS rule in chrome://browser/skin/browser.css:

.toolbarbutton-1 {
list-style-image: url("chrome://browser/skin/Toolbar.png");
}

Your toolbar button had class "toolbarbutton-1", right? So unless you have an image attribute (which overrides list-style-image in CSS) or your own list-style-image style you will get this image displayed on your button.

Reason why Firefox developers wrote this rule - standard toolbar buttons also have -moz-image-region set in CSS as well that defines which part of the image should be displayed on them. And having one large image instead of several small ones saves loading time.

Btw, if you choose to override list-style-image in CSS you should remember to load the same CSS file in the customization dialog as well. "Style overlays" should be a good search keyword for that.

Laurens said...

…And that’s why using a Schema-aware XML-editor is a good idea ^_^.