Bad Intel-Only Icon for Minefield

Someone posted a while back about this icon. I thought they said they were not sure what caused it. I got one of these and saw what it was.



This is what happens when you have an app that is built only for Intel, and you are looking at it on a PPC system. It is not going to run. If it is built "fat", then it has both an Intel executable and a PPC executable hidden inside its bundle directory and it will run on either.

This particular app was the Mac OS X 10.4.x app put up by Chris Double for his SVG Video Demo.

Just FYI.

Discovering the Coolness of nsIWebProgressListener

I am writing an extension and I have been jumping through some painful hoops with the "load" and "unload" events and "onDocumentLoad" and I have been trying to figure out how this is supposed to behave....

Then I discovered nsIWebProgressListener. What a beautiful interface!

I had thought that, in all my questions and grumblings and gripes, that someone would have pointed me to this. Someone probably did and I probably did not hear. But then, I notice that I will be drowning in a pool and I will say "Help!" and someone will say "you probably need an instance of a nsINylonLinearExtractionDevice...". No, actually, I need to not drown! Or I need a rope. And if I decode the answer, I can see that, yes, I was told I should grab a rope. How could I have missed it? :-)

It also makes it challenging that when you do a search (in site:mozilla.org), you are as likely to find a document from 1999 as any other. Yes, people have written new documents on the new ways of doing things. How often do the old documents get removed from wiki.m.o, or www.m.o? From the evidence, I would guess it does not happen very often.

There needs to be many more snippets on MDC that make use of this interface. I look forward to posting some. I am recalling many newbie questions on the newsgroups where the appropriate response would have been that one needs to look at all the wonderful things this interface gives you.

Of course, I always have a suggestion for future improvement. It's just something I have to do.

I wanted to keep track of some resources, one for each open window or tab. The interface, through the onStateChange and onLocationChange, gives me almost everything I need. Except that when I close a window, or close a tab, I get no message? I could just keep my stuff around in case a notification ever comes in on that window. But if that window was closed, wouldn't that be a leak in my extension?

I am sure there are other, older events I could look for, but it seems that nsIWebProgressListener was written to provide a better interface. It just needs to do the whole job.

See: http://bugzilla.mozilla.org/show_bug.cgi?id=395709 -
nsIWebProgressListener can send message when window or tab is closed

Tools for UI Testing Coming Around...

In case anyone missed it, as I almost did, a technology that had been called Koala was released by IBM as CoScripter. Here is the post. I, for one, am jazzed about this.

There is an opportunity here that I want to try to take advantage of. It has been possible, for at least a few months, to use JavaScript to create events and throw them at a DOM tree and see what happens. Some really good work went into making this possible.

But it has been made possible. It has not been made easy. As far as I know, there has not been a flood of new mochitest test cases using this API to test the UI in Firefox. Which is a shame. There is a lot of good testing that needs to be done.

Right now, most UI testing is done via the "clicks and eyeballs" harness that is housed at Building K of MoCo Central. These people do a great job with what they are given, but frankly they should not have to do it all. If the UI was more specified and the development of automated tests was part of feature development, there would be less fire drills at release times. Fire drills may be good for building esprit de corps in an organization, but it does not always lead to a quality release. When we hear of a successful fire drill at MoCo, we should be glad they got through it, but we should be worried that it happened.

What does this have to do with CoScripter? Am I done with my MoCo org rant? Yes, I am. And let me tell you.

Last time I heard, CoScripter records JavaScript events. I still have to confirm this. A lot may have happened since this was shown at MoCo in February and it was said that it would be released "any day now" and then "when IBM legal signed off". And hey, it only took six months. Those lawyers must have really burned the midnight oil, yes? :-)

The point is that it may be possible to record a user doing stuff, and then turn that into an automated test case. I am sure some processing of the resulting recording will have to occur, but I have done automated test case generation with a UI recording tool at Apple (that is proprietary and shall remain nameless), so I am pretty sure it can be done.

Imagine a user being able to turn on an extension, and then do something that causes whatever error they are seeing, and then just drop that into a bug. It would certainly make user's bugs a bit more informative. And more automated UI tests? This cannot be a bad thing.

Hopefully I can do this and not fail my classes this semester. We will see. :-)

What Prevents Multi-App Development at MoCo?

Reading some (but not all) of the Firefox/Thunderbird discussions, I find myself sanguine. I am not finding anything to be upset about. I think the current discussion may be more about the social structure of Mozilla. It does not seem to be a technical issue.

Looking at the technologies, it might be helpful if MoCo became, or came to see itself as, a service-provider for projects like Thunderbird. It could be "sourceforge with benefits", or perhaps a "sourceforge with a conscience". This seems obvious.

What makes it hard for MoCo to deal with Thunderbird as it is right now? Open-source avoids some problems one sees with commercial development. Commercial development seeks local maxima of utility with minimal investment of money. But MoCo has a similar issue. It seeks local maxima with minimal investment of social capital. What does this mean? If one looks at how Mozilla works, one sees this played out in many ways. I see some of them, but I do not think I am the best one to call them out.

One can identify, though, the "Mozilla way" of doing things. I noticed this when I was at Apple, and I still see it today. The "Mozilla way" is to use quirky tool sets, often old tools sets, with lots of hand-crafted modifications for particular issues. Enabling flexibility in these systems is not often a priority. Often it seems to be easier to hand-craft a solution to deal with the hand-crafted solution from two years ago. Finding a general solution that does not require tweaking does not seem to be a priority. A general solution rarely has social benefit. Individual tweaks, each to satisfy a different social entity, do have social benefits.

Why are more things not better documented? There is no social benefit to documenting that which is known by the core group. MoCo has, in general, a resistance to making things obvious. But social networks are built on shared knowledge, and if that knowledge requires a "maturation ritual", a "rite of passage", to find, all the better.

So, why can't Mozilla keep Thunderbird up-front, alongside Firefox? Perhaps it is not a technical issue. Anthropologists tell us that primates form social networks whose size varies with the ration of the brain size to body size. Given MoCo's reliance on social cohesion, Mozilla may not be able to concentrate on Thunderbird because the social network required is too big. Is Mozilla's pervasive reliance on social cohesion a good thing?

automated leak testing - followup

I have filed a bug (389361 - reproducible leak accessing page www.1ting.com) as a result of my leak testing. There are actually 6 URLs in that bug, but I cannot differentiate the leaks, so I have reported them together. I will have to figure out the leaks-gauge output so that I can make sense of this and report better bugs.

The leaks tool available on the Mac allows one to set an environment variable, MallocStackLogging, that makes the leaks output much more verbose. It will potentially tell you a lot about the objects being leaked. Unfortunately, this mostly works for Objective-C objects. C++ seems to be pretty good at obfuscating itself, or Apple has not done the work to help here, or both. It's a shame.

Well, the long and short of it is that leaks-gauge output does not make very much sense to me yet. :-(

I was not being very creative in how I got URLs. Someone pointed me to the alexa 500 and I hit pay dirt. Here are the sites I filed the bug against:

* http://www.1ting.com
* http://www.chinaren.com/
* http://www.cmfu.com/
* http://www.hurriyet.com.tr/
* http://www.yahoo.com/
* http://www.zaycev.net/

By the way, I am trying to get my add-on up onto AMO. This extension does nothing but quit Firefox at any page load. This is useful when launching Firefox from a script. The extension is available at my site and in the AMO sand box (login required, or may not be reachable). If anyone wants to review, after reading the docs, please do. I am not sure what the trigger is for getting it accepted on AMO. We will see.

I find it interesting that these leaks are sometimes not reproducible. There were a couple of dozen URLs in the list which generated leaks, but only once. As I re-tested URLs, sometimes they would leak every other time (like www.yahoo.com) and sometimes every third access (like www.1ting.com) and sometimes it was just more random than that. I did not list a URL if I could not get it to leak again. I am re-launching the browser each time, though, so I thought the testing would be more reproducible. It is more reproducible, but it is still surprising to me how many one-time leaks there were. There are some questions I am going to investigate.

* Does it matter if I randomize the list of URLs I am checking?
* If I automatically retry leaking URLs a certain number of times, how many times should I check?
* What files in the app bundle or in the profile directory change with an instance launch and shutdown? Or,
* What state being held between app launches?

We'll see.

automating leaks testing

I have managed to get some ideas I had to work in code. It required a couple of things.

First, why. The leak-gauge.pl script by dbaron is obviously very useful for tracking leaks in Firefox. I was just reminded of this reading this blog post by Steve England.

But reading Steve's post, it looks as though he did the following:

1) invoke leaks-gauge.pl on some URL
2) do a bunch of stuff on the resulting page
3) quit the browser
4) look at the results
5) perhaps file a bug
6) lather, rinse and report

If one wants to automate this testing, there are issues from some of this.

"invoke leaks-gauge.pl on some URL"

Right now, one uses a web page to tell leak-gauge.pl what to do. It is a manual process, hence this is not automatable.. I modified the leaks-gauge.pl script so that you give it an application executable, a profile directory, and a URL and it launches the browser for you. Another script goes through a list of apps and a list of URLs and calls the modified leaks-gauge.pl with the Cartesian product of these. This could all be done smarter than I am doing it.

What URLs can I run it on? Not wanting to answer that right now, I just looked at my copy of the trunk and used all the html files inside the layout/reftests directory. Right now this is 1081 URLs. I used 5 different applications, those being nightlies from 2007/01/30, 2007/03/24, 2007/05/23, 2007/06/15, and 2007/07/13.

"do a bunch of stuff"

Steve was testing extensions. Indeed, if one wants to test the memory footprint of extensions, one probably has to interact with the UI to cause the extension to do its stuff. I have no solutions to this quandary. I can say that it would be useful to use leak-gauge.pl just for single-page loads and this is automatable now.

"quit the browser"

This is not hard, but it is a bother. There are lots of ways to do it, but many of them make testing hard for various reasons. My solution to this was to create a very small extension, which will be up on AMO very soon. All it does is wait for a page to load, any page, and quit the browser. So, if one invokes firefox from the command-line and passes in a URL, then Firefox gets launched, it loads the page and then it automatically quits.

"look at the results"

So, I have a script that takes the output from the test run and outputs a couple of pages. Of course, anybody would know I will say this should be in a database, since I think everything should be in a database, but that is for later.

For full results, see http://www.wykiwyk.com/mozilla/leakTesting/testlog_20070718_byApp.html and http://www.wykiwyk.com/mozilla/leakTesting/testlog_20070718_byURL.html.

The summary results are that 2007/01/30 leaked some on a lot of pages, 2007/03/24 was slightly worse, and 2007/05/23, 2007/06/15, and 2007/07/13 did not leak at all on these files. Yeah for Cycle Collection! :-)

And now, there is a Firefox extension for which someone is actually paying me, so I should get back to it.

Starting a Firefox Instance With a Fresh Profile

Maybe it is just me, but in doing anything with development builds of Firefox, I was constantly bothered by having my profile mucked around with, or having to create fresh profiles, or having to switch the default profile for some set of tests I wanted to run.

I had slapped together little scripts to deal with some of this, but I finally got them all together in one script and it has been working for me for a while. This may be useful to others. Maybe not.

One thing different about this is that I am doing things on a Mac. I have not tried to make the script cross-platform at all. I also find the executables in the places I keep them. There is no way to find out about the different copies of Firefox that are installed on a particular machine. There is no global installation log. And even though all of the apps read from resources in the 'Application Support' folder, none of them store information there that would tell one which instances of Firefox have been run. And it is not the most elegnt or clever script I have written. But it works. If anybody has suggestions for something to replace this find command, or anything else, please suggest. Until then, here it is:

http://www.wykiwyk.com/mozilla/newbrowser.pl

So, the script will create a fresh profile, put some preferences into it, ask you to identify the copy of Firefox that you want to run and then launch with the new profile. Here is an example of it being run:

% newbrowser 
1: /Users/ray/mo/trowser/mozilla/dist/MinefieldDebug.app/Contents/MacOS/firefox
2: /Users/ray/mo/trowser2/mozilla/dist/Minefield.app/Contents/MacOS/firefox
3: /Applications/Mozilla/Firefox_1.5.0.11.app/Contents/MacOS/firefox
4: /Applications/Mozilla/Firefox_1.5.app/Contents/MacOS/firefox
5: /Applications/Mozilla/Firefox_2.0.0.2.app/Contents/MacOS/firefox
6: /Applications/Mozilla/Firefox_2.0.0.4.app/Contents/MacOS/firefox
7: /Applications/Mozilla/GranParadiso_20070426.app/Contents/MacOS/firefox
8: /Applications/Mozilla/Minefield_3.0a2pre_20070130.app/Contents/MacOS/firefox
9: /Applications/Mozilla/Minefield_3.0a2pre_20070206.app/Contents/MacOS/firefox
10: /Applications/Mozilla/Minefield_3.0a3pre_20070222.app/Contents/MacOS/firefox
11: /Applications/Mozilla/Minefield_3.0a3pre_20070308.app/Contents/MacOS/firefox
12: /Applications/Mozilla/Minefield_3.0a3pre_20070317.app/Contents/MacOS/firefox
13: /Applications/Mozilla/Minefield_3.0a3pre_20070324.app/Contents/MacOS/firefox
14: /Applications/Mozilla/Minefield_3.0a4pre_20070413.app/Contents/MacOS/firefox
15: /Applications/Mozilla/Minefield_3.0a5pre_20070503.app/Contents/MacOS/firefox
16: /Applications/Mozilla/Minefield_3.0a5pre_20070519.app/Contents/MacOS/firefox
17: /Applications/Mozilla/Minefield_3.0a6pre_20070623.app/Contents/MacOS/firefox
which executable? 1
cmd = "NO_EM_RESTART=1 /Users/ray/mo/trowser_newbad/mozilla/dist/Minefield.app/Contents/MacOS/firefox -profile /tmp/3lwhsxqz.mozilla_20070707_215451_PDT  2>&1"
WARNING: NS_ENSURE_TRUE(compMgr) failed: file nsComponentManagerUtils.cpp, line 90
Type Manifest File: /tmp/3lwhsxqz.mozilla_20070707_215451_PDT/xpti.dat
*** Registering xpconnect components (all right -- a generic module!)
etc, etc, etc, etc, ....

I have also made it trivial to run a set of reftests, as so:

% newbrowser -reftest layout/reftests/reftest.list
1: /Users/ray/mo/trowser/mozilla/dist/MinefieldDebug.app/Contents/MacOS/firefox
2: /Users/ray/mo/trowser_newbad/mozilla/dist/Minefield.app/Contents/MacOS/firefox
3: /Applications/Mozilla/Firefox_1.5.0.11.app/Contents/MacOS/firefox
4: /Applications/Mozilla/Firefox_1.5.app/Contents/MacOS/firefox
5: /Applications/Mozilla/Firefox_2.0.0.2.app/Contents/MacOS/firefox
6: /Applications/Mozilla/Firefox_2.0.0.4.app/Contents/MacOS/firefox
7: /Applications/Mozilla/GranParadiso_20070426.app/Contents/MacOS/firefox
8: /Applications/Mozilla/Minefield_3.0a2pre_20070130.app/Contents/MacOS/firefox
9: /Applications/Mozilla/Minefield_3.0a2pre_20070206.app/Contents/MacOS/firefox
10: /Applications/Mozilla/Minefield_3.0a3pre_20070222.app/Contents/MacOS/firefox
11: /Applications/Mozilla/Minefield_3.0a3pre_20070308.app/Contents/MacOS/firefox
12: /Applications/Mozilla/Minefield_3.0a3pre_20070317.app/Contents/MacOS/firefox
13: /Applications/Mozilla/Minefield_3.0a3pre_20070324.app/Contents/MacOS/firefox
14: /Applications/Mozilla/Minefield_3.0a4pre_20070413.app/Contents/MacOS/firefox
15: /Applications/Mozilla/Minefield_3.0a5pre_20070503.app/Contents/MacOS/firefox
16: /Applications/Mozilla/Minefield_3.0a5pre_20070519.app/Contents/MacOS/firefox
17: /Applications/Mozilla/Minefield_3.0a6pre_20070623.app/Contents/MacOS/firefox
which executable? 1
cmd = "NO_EM_RESTART=1 /Users/ray/mo/trowser/mozilla/dist/MinefieldDebug.app/Contents/MacOS/firefox -profile /tmp/60yqqqnd.mozilla_20070707_221500_PDT --reftest layout/reftests/reftest.list 2>&1 | /usr/bin/grep '^REFTEST '"
etc, etc, etc, etc, ....

For more:

% newbrowser -usage
newbrowser [ -noUserJS ] [ -reftest <manifest file> ] [ -exec <executable> ]
%

A Way Around my Gordian Knot with Reftests

I have been trying to figure out a way for reftests to be able to do image comparisons. I have been hampered by both my lack of experience with writing "Mozilla-ish" JavaScript and by the fact that reftest was not designed to do this. Or perhaps, reftest was designed not to do this. Indeed, the thing that makes reftest different is that it does not do exact comparisons with a hard-coded "golden" page and so it is more flexible and does not cause unnecessary failures when unimportant changes are made to, for example, layout.

But there is a call for exact rendering comparisons.

For example, if a certain Unicode value in an html page is supposed to render an Urdu character, the only way to test for this is to have a human look at it and see whether it is right or not. Similarly, whether a given MathML leads to correctly rendered expressions is, at this point, only checkable by a human loading a page and looking at it. I call this the "browsers and eyeballs" test harness.

But the people blocking my changes for reftest are better at doing that than I am at figuring out what would be acceptable and would also do the job, so I have figured out a way to use the current, checked-in version of reftest to do exact visual comparisons. Rather than go into the code, I will demonstrate.

First, I created a file, u1.txt, that contained a list of URLs that I pulled from Ian Hickson's "HTML 4.0 Test Suite" at http://hixie.ch/tests/html40/test41-1a.html . Following the chain that starts at that page leads one to 16 URLs.

Then I run:

% perl runRef -generate -src u1.txt -app /Users/ray/mozilla/dist/MinefieldDebug.app/Contents/MacOS/firefox -profile /tmp/12qp5rt8.mozilla_20070630_153321_PDT > u2.txt

The profile is nothing special. It is just dynamically generated so that the browser can run in an automation-friendly manner. Then u2.txt will contain something like:

URL: http://hixie.ch/tests/html40/test41-1a.html
DGT: 9e747d8a7b957f5126f07135b75f9564405da513
URI: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAPoCAYAAAAmy5qxAAAgAElEQVR4nOzdf1zV9 (and so on ...)

URL: http://hixie.ch/tests/html40/test41-1b.html
DGT: 1bb9c5fba9fd37d6afdced89817f0a61104b3ced
URI: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAPoCAYAAAAmy5qxAAAgAElEQVR4nOzdf1zV9d3/8QfXgA4 (and so on ...)

URL: http://hixie.ch/tests/html40/test41-2.shtml
DGT: 0f3e0c63e174afff4c61924384cbe2dc78722447
URI: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAPoCAYAAAAmy5qxAAAgAElEQVR4nOzdf1zV9d3/8QfXAA8aB (and so on ...)

URL: http://hixie.ch/tests/html40/test41-3.html
DGT: ad782efed8ab827701fb6740f2089d897f8499bd
URI: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAPoCAYAAAAmy5qxAAAgAElEQVR4nOzdf1zV9f (and so on ...)

Then when I can do:

% <re-fetch and build Firefox here>
% perl runRef -test -src u2.txt -app /Users/ray/mozilla/dist/MinefieldDebug.app/Contents/MacOS/firefox -profile /tmp/12qp5rt8.mozilla_20070630_153321_PDT
URL: http://hixie.ch/tests/html40/test41-1a.html -> Ok
URL: http://hixie.ch/tests/html40/test41-1b.html -> Ok
URL: http://hixie.ch/tests/html40/test41-2.shtml -> Ok
URL: http://hixie.ch/tests/html40/test41-3.html -> Ok
...

This will verify that the html being received from the URL is exactly as is expected (the DGT marker above is for an SHA1 digest of the source) and the new copy of Firefox displays exactly the same images as the old copy.

Are there obvious issues raised by doing this kind of testing? Yes. And there are ways around them. There are some tools needed to support a workflow that uses this test tool. And I could try to guess what the objections will be now but, then again, "vita brevis, programmi longa".

This should definitely not be seen as an attempt to replace testing tools like mochitest or reftest. On the other hand, I could spend a few days and find 50,000 static URLs and be able to say whether any given check-in causes any difference in the display of any of those pages. How long would it take to find the 5000 or so important differences in those pages and write reftests for them? I do not know, but I am not going to spend a few years trying to find out.

Proposed Litmus Database Schema

I had proposed this change to the guys who run the litmus site. They had not responded, as they are in the middle of other changes. The other changes are, I think, orthogonal to these suggestions. I wanted to capture this suggestion before I lost it.

I think that this is the current structure (as I have reverse-engineered it) of the Litmus database.



I am proposing this, which I think will be much more flexible and will scale better in the long run. I am seeing a few slight errors, such as that there should be "0+" resources associated with a test, not "1+". But I think this is mostly correct.

The Category entity and its self-link allows a flexible categorization of the tests, but also allows a heirarchical categorization at the same time. The Resource entity would allow us to capture, for example, a URL as one resource of a "go to site of URL" test. Then associating 100 URLs with that test would be more flexible than creating 100 tests of the form "go to URL A", "go to URL B", etc. The Config entity would capture the type of machine and the versions of what is being run. This would be more flexible than, for example, creating a one version of test for Firefox 1.5, then a separate copy of the test for FireFox, then a separate copy of the test for Firefox 3, and so on.




If anyone has suggestions, please let me know.

Slides from Mozilla OnSite Preso

They are here: http://66.16.208.213/mozilla/OnSite2007Preso/Intro.html

A Random Attempt at Specifying Firefox UI

Correction: 2007/04/07 - This is why I like specs. I get things wrong at times. I was switching back and forth between FF and TB and wrote down the wrong menu headers. I am fixing the Firefox menu headers for Mac OS X. Thanks for the notes about this in the comments. This will be the last edit here. This document will be moved. Back to the original post....

I was telling people that this should be done, so I decided to put my feet into the dance. There is a lot of good stuff written in various blog entries and on wikis scattered hither and yon that describe various aspects of the UI of Gecko apps, such as Firefox. I mentioned that these could be brought together into some sort of specification that could be used to help people who are trying to test the product, document the product, develop for the product, or just plain understand it.

I borrowed a picture from Alex Faaborg, something I really wish I had seen in my first month at MoCo, when I was writing things in bugs that sounded like "that thing that does that stuff, next to that other thing, I do not think it is working...". Yeah. That went really well.

It is going to be difficult for one person to be comprehensive. I wanted to illustrate, though, an approach that can be taken. So, I have tried to describe the empty first page. I ended up also describing the "Quick Find" box. I think people know that command-F brings up Find, from the menu, but how many people know that the '/' key brings up the Quick Find bar instead? People remember vi, yes? Of course, they do. Very intuitive. :-)

So, here goes.

---

Firefox - A Browser



Of course, one does not always see these UI elements all at once. This will help more if it actually describes the state the browser is in at the time one sees this UI. While we're here, how did we get here? That is the big picture. But there are other pictures.





The first image above is the first page one sees on a Mac OS X system running Firefox 2.0.0.3 and the second is the same Firefox release on Ubuntu Linux 6.10. Obviously, there are differences between all the platforms.

- There is no Menu Bar in the window on Mac OS X. The menu bar for a Mac OS X application is at the top of the system window. The top-level menus are different.
* Mac top menus: File, Edit, View, History, Bookmarks, Tools, Window, Help
* Windows top menus: ???
* Mac top menus: File, Edit, View, History, Bookmarks, Tools, Help

- The Navigation Toolbar appears to be the same. Add-ons may place other icons in the Navigation Toolbar.

- In the Windows picture, there is a square box to the right of the Menu Bar. This is the "Busy Searching Spinner".

- The Mac has a "Busy Searching Spinner" on the right of the Search Bar. It spins when one is searching. It stays motionless while one is not searching.

- The Bookmarks Toolbar is the same.

- The Tabstrip is the same, except that the icons are different.

- The Content Area is the same. By default, the Content Area is blank. Firefix may be configured to open a page at launch. To see a blank Content Area, type "about:blank" in the Location Bar.

- The Sidebar is the same. It is only made visible under certain conditions. By default the browser history is made visible in the Sidebar when one types the 'History Sidebar Key'. Typing key again makes the History sidebar appear. Typing this key again makes it disappear.
* Mac - 'History Sidebar Key' = command-shift-h
* Windows - 'History Sidebar Key' = ???
* Linux - 'History Sidebar Key' = control-h

- The Status Bar is the same.

- The Find Bar is the same. Typing 'Find Key' makes the Find Bar visible below the Content Area and Sidebar.
* Mac: 'Find Key' = command-f
* Windows: 'Find Key' = ???
* Linux: 'Find Key' = control-f

- There is also a Quick Find Bar that replaces the Find Bar.


Quick Find Bar:

The Quick Find Bar in a browser window on Mac OS X is shown below.

If the Content Area is not blank, typing the '/' key makes the Quick Find Bar visible below the Content Area and Sidebar. There is also an issue with the default keyboard focus. For example, bring up the page shown below and type the '/' character. The Quick Find Bar will not appear because the default keyboard focus is on the search form field. One must click somewhere else on the page to take the keyboard focus away from the form field. When there is no form field accepting keyboard focus, then typing the '/' key brings up the Quick Find Bar.

If the Content Area is blank, typing the '/' key has no effect. The Quick Find Bar disappears after approximately 4 seconds if nothing is typed.



If one types a character, it is put into the 'Quick Find' field. If there is text on the page matching the text in the Quick Find text field, then the first instance of that text on the page is selected. If the selected text is part of a link, the URL for that link is displayed in the Status Bar and if one types a return key or an enter key, then that link is activated. If one types text which does not appear on the page, the background of the Quick Find text field turns red. If another character is typed and the action does not place a text string which is found on the page into the Quick Find text field, there is an audible "beep".

For example, if one navigates to the page above and types a '/' character and then a 'xxx', the result is two audible beeps and the page below.



If one does not hit return and stops typing, the Quick FInd Bar and the text typed in disappears. If one hits the '/' key again, the Quick Find Bar appears again, but the text field is empty and the previously typed text is lost.


Still To Be Done

Absolutely everything else.

Cranking on the Test Engine

I recently "finished" an inventory of the testing tools and test suites available here at Mozilla. I put quotes around the word "finished" because, of course, it is not done. In a sense, it never will be. What I have done is that really turned one crank on an engine. Hopefully, the engine will be started.

I view this as an engine because there is a cycle that needs to occur. (I may actually have my engine terminolgy wrong here. I do not actually know engines as anything other than an abstraction. Apologies in advance.) Also, I am not an artist. I do words, not pictures.


Spark - identify and ignite existing tests. This will lead to...

Combustion - tests are executed and results recorded.

There has been a lot of random firing in the past. There are a bunch of tests. But when people look to run tests, their choice of tests has been close to random. I believe this to be so because if one wanted to pick tests by another method, there is no way to do so. There is no information available to provide any other criteria. There is a very rough correspondence between modules and tests, but modules are amorphously defined and the results are usually passed on in the form of a message that "I ran tests in X and they worked." Not very specific.

Right now, combustion is starting to happen. Litmus tests get executed and there is information at the end that can be pointed to. There are suites of reftests and mochitests scripts that are being run after a build and reported in tinderbox. But there are a lot of tests that are not in these harnesses yet. There are a lot of tests that are hard to analyze and hard to understand. It is hard to tell how useful they are.

Expansion - results of testing are analyzed.

It is usually in this stage that a determination is made about whether something can be shipped, or if the quality of the product is deemed good enough for some purpose. This stage involves an evaluation about what the testing meant. This leads to the next stage.

Compression - functionality is identified for which new tests are needed.

Did the testing that was done test the features that we care about? Usually, enough testing is done so that we are confident of the new features and of drastically changed functionality. But we all know there are side-effects and side-effects to side-effects and I do not think anybody feels we are testing as much of the functionality as we should. Thinking about what new tests are needed pushes the piston back down to a firing position.

Injection - define more tests of the functionality.

And then this brings us back to Spark.

I suggest this could be thought of as a cycle, and a cycle that needs to continue to go around. It is not something to do until we are "done".

Investigating NSPR Logging

There are a lot of tests written in C++ and there are a lot of different ways that they log their results. Among the strings that one finds are ": PASS", "INFO PASS", "tests passed.", "... OK", and so on. And that is only for the successful runs of the tests.

I am investigating the use of the PR_LOG call defined in http://lxr.mozilla.org/mozilla/source/nsprpub/pr/include/prlog.h.

It turns out that you can turn on logging in modules that take advantage of the NSPR function but setting an environment variable. So, if I want to see the log output from a test, I can do:

$ cd dist/bin
$ NSPR_LOG_MODULES=all:5 ./TestCookie 2>&1 | grep -v WARNING

At this point, there is a lot of output. I can also do:

$ cd dist/bin
$ NSPR_LOG_MODULES=all:0 ./TestCookie 2>&1 | grep -v WARNING

These numbers are from prlog.h. I found this in a post about troubleshooting mail. Or rather, Tomcat found it.

PR_LOG_NONE = 0, /* nothing */
PR_LOG_ALWAYS = 1, /* always printed */
PR_LOG_ERROR = 2, /* error messages */
PR_LOG_WARNING = 3, /* warning messages */
PR_LOG_DEBUG = 4, /* debug messages */

So, 5 means "I want everything" and 0 means "please, be quiet". But there is still a lot of output when I use "all:0" above.

It turns out that this test is using printf. I do not even want to do a search for the number of cpp files we have using printf. I am sure there are a gazillion of them.

When you register with the logger, you have to give your module a name. This is an interesting list.

"Autodial" - netwerk/base/src/nsAutodialWin.cpp
"BMPDecoder" - modules/libpr0n/decoders/bmp/nsBMPDecoder.cppPRLogModuleInfo
"BayesianFilter" - mailnews/extensions/bayesian-spam-filter/src/nsBayesianFilter.cpp
"DOMLeak" - dom/src/base/nsGlobalWindow.cpp
"DeviceContextSpecGTK" - widget/src/gtk2/nsDeviceContextSpecG.cpp
"DeviceContextSpecQt" - gfx/src/qt/nsDeviceContextSpecQt.cpp
"DeviceContextSpecXlib" - gfx/src/xlib/nsDeviceContextSpecXlib.cpp
"DeviceContextXlib" - gfx/src/xlib/nsDeviceContextXlib.cpp
"DocLoader" - uriloader/base/nsDocLoader.cpp
"DocumentLeak" - content/base/src/nsDocument.cpp
"DrawingSurfaceXlib" - gfx/src/xlib/nsDrawingSurfaceXlib.cpp
"FontMetricsGTK" - gfx/src/gtk/nsFontMetricsGTK.cpp
"FontMetricsPS" - gfx/src/ps/nsFontMetricsPS.cpp
"FontMetricsXlib" - gfx/src/xlib/nsFontMetricsXlib.cpp
"GC" - nsprpub/lib/msgc/src/prmsgc.c:
"HelperAppService" - uriloader/exthandler/nsExternalHelperAppService.cpp
"IMAP" - mailnews/imap/src/nsImapProtocol.cpp
"IMAP" - mailnews/imap/src/nsImapProtocol.cpp
"IMAPOFFLINE" - mailnews/db/msgdb/src/nsMailDatabase.cpp
"IMAPOFFLINE" - mailnews/db/msgdb/src/nsMailDatabase.cpp
"IMAPOFFLINE" - mailnews/db/msgdb/src/nsMsgOfflineImapOperation.cpp
"IMPORT" - mailnews/import/comm4x/src/nsComm4xMailImport.cpp
"IMPORT" - mailnews/import/eudora/src/nsEudoraImport.cpp
"IMPORT" - mailnews/import/oexpress/nsOEImport.cpp
"IMPORT" - mailnews/import/outlook/src/nsOutlookImport.cpp
"IMPORT" - mailnews/import/src/nsImportMail.cpp
"IMPORT" - mailnews/import/src/nsImportService.cpp
"IMPORT" - mailnews/import/text/src/nsTextImport.cpp
"ImageXlib" - gfx/src/xlib/nsImageXlib.cpp
"InMemoryDataSource" - rdf/base/src/nsInMemoryDataSource.cpp
"JPEGDecoder" - modules/libpr0n/decoders/jpeg/nsJPEGDecoder.cppPRLogModuleInfo
"JSComponentLoader" - js/src/xpconnect/loader/mozJSComponentLoader.cpp
"JSDiagnostics" - dom/src/base/nsJSEnvironment.cpp
"LoadGroup" - netwerk/base/src/nsLoadGroup.cpp
"MAILBOX" - mailnews/local/src/nsMailboxProtocol.cpp
"MAPI" - mailnews/mapi/mapihook/src/msgMapiImp.cpp
"MCD" - extensions/pref/autoconfig/src/nsReadConfig.cpp
"MIME" - mailnews/mime/emitters/src/nsMimeBaseEmitter.cpp
"Mai" - accessible/src/atk/nsMai.h:
"Movemail" - mailnews/local/src/nsMovemailService.cpp
"MsgBiff" - mailnews/base/src/nsMsgBiffManager.cpp
"MsgPurge" - mailnews/base/src/nsMsgPurgeService.cpp
"NNTP" - mailnews/news/src/nsNNTPProtocol.cpp
"NNTP" - mailnews/news/src/nsNNTPProtocol.cpp
"NNTP" - mailnews/news/src/nsNNTPProtocol.cpp
"NNTP" - mailnews/news/src/nsNNTPProtocol.cpp
"NSJAVA" - modules/oji/src/nsJVMManager.cpp
"NTLM" - security/manager/ssl/src/nsNTLMAuthModule.cppPRLogModuleInfo
"ObserverService" - xpcom/ds/nsObserverService.cpp
"PALMSYNC" - mailnews/extensions/palmsync/src/PalmSyncImp.cpp
"PNGDecoder" - modules/libpr0n/decoders/png/nsPNGDecoder.cppPRLogModuleInfo
"POP3" - mailnews/local/src/nsPop3Protocol.cpp
"PangoFont" - gfx/src/gtk/nsFontMetricsPango.cpp
"PhGfxLog" - gfx/src/photon/nsRenderingContextPh.cppPRLogModuleInfo
"PresShell" - layout/base/nsPresShell.cpp
"QtGfx" - gfx/src/qt/nsGfxFactoryQt.cppPRLogModuleInfo
"RDF" - rdf/base/src/nsCompositeDataSource.cpp
"RenderingContextXlib" - gfx/src/xlib/nsRenderingContextXlib.cpp
"RenderingContextXp" - gfx/src/xprint/nsRenderingContextXp.cpp
"SMTP" - mailnews/compose/src/nsSmtpProtocol.cpp
"SOCKS" - netwerk/socket/base/nsSOCKSIOLayer.cpp
"StaticComponentLoader" - xpcom/components/nsStaticComponentLoader.cpp
"Syspref" - extensions/pref/system-pref/src/gconf/nsSystemPrefService.cpp
"Syspref" - extensions/pref/system-pref/src/nsSystemPref.cpp
"Test" - netwerk/test/TestBlockingSocket.cpp
"Test" - netwerk/test/TestCookie.cpp
"Test" - netwerk/test/TestIOThreads.cpp
"Test" - netwerk/test/TestProtocols.cpp
"Test" - netwerk/test/TestServ.cpp
"Test" - netwerk/test/TestSocketTransport.cpp
"Test" - netwerk/test/TestStreamChannel.cpp
"Test" - netwerk/test/TestStreamLoader.cpp
"Test" - netwerk/test/TestStreamPump.cpp
"Test" - netwerk/test/TestStreamTransport.cpp
"Test" - netwerk/test/TestUpload.cpp
"Test" - nsprpub/pr/tests/anonfm.c:
"Test" - nsprpub/pr/tests/instrumt.c:
"Test" - nsprpub/pr/tests/mbcs.c:
"Test" - nsprpub/pr/tests/nameshm1.c:
"Test" - nsprpub/pr/tests/ntioto.c:
"Test" - nsprpub/pr/tests/op_excl.c:
"Test" - nsprpub/pr/tests/randseed.c:
"Test" - xpcom/proxy/tests/proxytests.cpp
"TestCase" - security/nss/cmd/selfserv/selfserv.c:
"TestSocketIO" - netwerk/test/TestOverlappedIO.cpp
"TestSocketIO" - netwerk/test/TestSocketIO.cpp
"URILoader" - uriloader/base/nsURILoader.cpp
"UrlClassifierDbService" - toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp
"UrlClassifierStreamUpdater" - toolkit/components/url-classifier/src/nsUrlClassifierStreamUpdater.cpp
"Widget" - widget/src/gtk2/nsAppShell.cpp
"WidgetDraw" - widget/src/gtk2/nsAppShell.cpp
"WidgetFocus" - widget/src/gtk2/nsAppShell.cpp
"WidgetIM" - widget/src/gtk2/nsAppShell.cpp
"XRemoteClient" - widget/src/xremoteclient/XRemoteClient.cpp
"XftFontLoad" - gfx/src/gtk/nsFontMetricsXft.cpp
"XlibScrolling" - widget/src/xlib/nsWidget.cppPRLogModuleInfo
"XlibWidgets" - widget/src/xlib/nsWidget.cppPRLogModuleInfo
"cache" - netwerk/cache/src/nsCache.cpp
"canvasGLES11" - extensions/canvas3d/src/nsCanvasRenderingContextGLES11.cpp
"clock" - nsprpub/pr/src/misc/prinit.c:
"cltsrv_log" - nsprpub/pr/tests/cltsrv.c:
"cltsrv_log" - nsprpub/pr/tests/provider.c:
"cmon" - nsprpub/pr/src/misc/prinit.c:
"cookie" - netwerk/cookie/src/nsCookieService.cpp
"counters" - nsprpub/pr/src/misc/prcountr.c:
"cvar" - nsprpub/pr/src/misc/prinit.c:
"expatdriver" - parser/htmlparser/src/nsExpatDriver.cpp
"frame" - layout/generic/nsFrame.cpp
"frameverifytree" - layout/generic/nsFrame.cpp
"gc" - nsprpub/pr/src/misc/prinit.c:
"gizmo" - nsprpub/pr/include/prlog.h:**
"gnomevfs" - extensions/gnomevfs/nsGnomeVFSProtocolHandler.cpp
"htmlcontentsink" - content/html/document/src/nsHTMLContentSink.cpp
"imgRequest" - modules/libpr0n/src/imgRequest.cppPRLogModuleInfo
"io" - nsprpub/pr/src/misc/prinit.c:
"ldap" - directory/xpcom/base/src/nsLDAPProtocolModule.cpp
"ldapautocomplete" - mailnews/addrbook/src/nsLDAPAutoCompleteSession.cpp
"ldapautocomplete" - mailnews/addrbook/src/nsLDAPAutoCompleteSession.cpp
"linker" - nsprpub/pr/src/misc/prinit.c:
"mon" - nsprpub/pr/src/misc/prinit.c:
"mozStorage" - storage/src/mozStorageConnection.cpp
"msgc" - nsprpub/lib/msgc/src/prmsgc.c:
"msgcompose" - mailnews/compose/src/nsMsgComposeService.cpp
"negotiateauth" - extensions/auth/nsAuthFactory.cpp
"nsAbOutlookCardLog" - mailnews/addrbook/src/nsAbOutlookCard.cpp
"nsAbOutlookDirFactoryLog" - mailnews/addrbook/src/nsAbOutlookDirFactory.cpp
"nsAbOutlookDirectoryLog" - mailnews/addrbook/src/nsAbOutlookDirectory.cpp
"nsAbWinHelperLog" - mailnews/addrbook/src/nsAbWinHelper.cpp
"nsCSSLoader" - layout/style/nsCSSLoader.cpp
"nsCachedChromeChannel" - chrome/src/nsChromeProtocolHandler.cpp
"nsCachedChromeChannel" - rdf/chrome/src/nsChromeProtocolHandler.cpp
"nsComponentManager" - xpcom/components/nsComponentManager.cpp
"nsContentPolicy" - content/base/src/nsContentPolicy.cpp
"nsDebug" - xpcom/base/nsDebugImpl.cpp
"nsDeviceContextPS" - gfx/src/ps/nsDeviceContextPS.cpp
"nsDeviceContextXp" - gfx/src/xprint/nsDeviceContextXP.cpp
"nsDirectoryIndexStream" - netwerk/base/src/nsDirectoryIndexStream.cpp
"nsDocShell" - docshell/base/nsDocShell.cpp
"nsDocShellLeak" - docshell/base/nsDocShell.cpp
"nsDragService" - widget/src/beos/nsDragService.cpp
"nsDragService" - widget/src/gtk/nsDragService.cpp
"nsDragService" - widget/src/gtk2/nsDragService.cpp
"nsElementMap" - content/xul/document/src/nsElementMap.cpp
"nsEventQueue" - xpcom/threads/nsEventQueue.cpp
"nsFTPDirListingConv" - netwerk/streamconv/converters/nsFTPDirListingConv.cpp
"nsFtp" - netwerk/protocol/ftp/src/nsFtpProtocolHandler.cpp
"nsHostResolver" - netwerk/dns/src/nsHostResolver.cpp
"nsHttp" - netwerk/protocol/http/src/nsHttpHandler.cpp
"nsIIdleService" - widget/src/gtk2/nsIdleServiceGTK.cpp
"nsIOThreadPool" - netwerk/base/src/nsIOThreadPool.cpp
"nsJarProtocol" - modules/libjar/nsJARChannel.cpp
"nsMapiAddressBookLog" - mailnews/addrbook/src/nsMapiAddressBook.cpp
"nsMetricsService" - extensions/metrics/src/nsMetricsService.cpp
"nsNativeModuleLoader" - xpcom/components/nsNativeComponentLoader.cpp
"nsObjectFrame" - layout/generic/nsObjectFrame.cpp
"nsPipe" - xpcom/io/nsPipe3.cpp
"nsPostScriptObj" - gfx/src/ps/nsPostScriptObj.cpp
"nsPrefetch" - uriloader/prefetch/nsPrefetchService.cpp
"nsRDFContentSink" - rdf/base/src/nsRDFContentSink.cpp
"nsRDFService" - rdf/base/src/nsRDFService.cpp
"nsRDFXMLDataSource" - rdf/base/src/nsRDFXMLDataSource.cpp
"nsRequestObserverProxy" - netwerk/base/src/nsRequestObserverProxy.cpp
"nsResProtocol" - netwerk/protocol/res/src/nsResProtocolHandler.cpp
"nsSecureBrowserUI" - security/manager/boot/src/nsSecureBrowserUIImpl.cpp
"nsSharedPrefHandler" - modules/libpref/src/nsSharedPrefHandler.cpp
"nsSocketTransport" - netwerk/base/src/nsSocketTransportService2.cpp
"nsStandardURL" - netwerk/base/src/nsStandardURL.cpp
"nsStorageStream" - xpcom/io/nsStorageStream.cpp
"nsStreamCopier" - netwerk/base/src/nsAsyncStreamCopier.cpp
"nsStreamPump" - netwerk/base/src/nsInputStreamPump.cpp
"nsThread" - xpcom/threads/nsThread.cpp
"nsThreadPool" - xpcom/threads/nsThreadPool.cpp
"nsTimerImpl" - xpcom/threads/nsTimerImpl.h:
"nsWabAddressBookLog" - mailnews/addrbook/src/nsWabAddressBook.cpp
"nsWyciwygChannel" - content/html/document/src/nsWyciwygProtocolHandler.cpp
"nsXPrintContext" - gfx/src/xprint/nsXPrintContext.cpp
"nsXULCommandDispatcher" - content/xul/document/src/nsXULCommandDispatcher.cpp
"nsXULContentSink" - content/xul/document/src/nsXULContentSink.cpp
"nsXULDocument" - content/xul/document/src/nsXULDocument.cpp
"nsXULTemplateBuilder" - content/xul/templates/src/nsXULTemplateBuilder.cpp
"nscontentsink" - content/base/src/nsContentSink.cpp
"nss_cache" - security/nss/lib/pki/tdcache.c:
"nss_mod_log" - security/nss/lib/pk11wrap/debug_module.c:
"nssilock" - security/nss/lib/util/nssilock.c:
"objlc" - content/base/src/nsObjectLoadingContent.cpp
"pipnss" - security/manager/ssl/src/nsNSSComponent.cpp
"printing" - layout/base/nsDocumentViewer.cpp
"printing" - layout/printing/nsPrintData.cpp
"printing" - layout/printing/nsPrintEngine.cpp
"printing-gfx" - gfx/src/windows/nsDeviceContextWin.cpp
"printing-layout" - layout/generic/nsSimplePageSequence.cppPRLogModuleInfo
"printing-widget" - widget/src/windows/nsDeviceContextSpecWin.cppPRLogModuleInfo
"proxy" - netwerk/base/src/nsProtocolProxyService.cpp
"sched" - nsprpub/pr/src/misc/prinit.c:
"schemaValidation" - extensions/schema-validation/src/nsSchemaValidator.cppPRLogModuleInfo
"schemaValidation" - extensions/schema-validation/src/nsSchemaValidatorUtils.cppPRLogModuleInfo
"shm" - nsprpub/pr/src/misc/prinit.c:
"shma" - nsprpub/pr/src/misc/prinit.c:
"styleverifytree" - layout/generic/nsFrame.cpp
"test" - nsprpub/pr/tests/y2k.c:
"testcase" - nsprpub/lib/tests/arena.c:
"testcase" - nsprpub/pr/tests/rmdir.c:
"thebesGfx" - gfx/src/thebes/nsThebesDeviceContext.cpp
"thread" - nsprpub/pr/src/misc/prinit.c:
"timing" - modules/libutil/public/stopwatch.h:
"trace" - nsprpub/pr/src/misc/prtrace.c:
"updatedriver" - toolkit/xre/nsUpdateDriver.cpp
"webdav" - extensions/webdav/src/nsWebDAVService.cpp
"webshell" - docshell/base/nsWebShell.cpp
"winfonts" - gfx/thebes/src/gfxWindowsFonts.cpp
"xpath" - content/xslt/src/base/txLog.h:
"xpclog" - js/src/xpconnect/src/xpclog.cpp
"xpcomproxy" - xpcom/proxy/src/nsProxyObjectManager.cppPRLogModuleInfo
"xslt" - content/xslt/src/base/txLog.h:

Creating Your First Reftest, and Your Second and Third

I have updated a page on devmo and I think it is a rather nice page, though I am not objective here.

http://developer.mozilla.org/en/docs/Creating_reftest-based_unit_tests

This describes in very practical terms how to create reftests. It turns out to be way easier than it seemed at first. Really, I just had to map what reftest did into my head. Not being a long-time Mozilla-ish person, it probably took me longer than it would take others.

Here is a slice from the page, giving instructions on just the first test. Please see the page for more info. There are details in the full instructions that may be useful. And if something seems wrong, please feel free to update the page. Send me an e-mail if you would like, but wiki is more wiki if people really edit what they see. And now for the show.

---

Step 1: Build a copy of Firefox for yourself.

Step 2: Open a terminal window. Create a directory and make that your current directory.

Step 3: Create a file named foo.html with the following:

<html><head><title>reftest0001</title><body><strong>Hello!</strong></body></html>

Step 4: Create a file named bar.html with the following:

<html><head><title>reftest0001</title><body><b>Hello!</b></body></html>

Step 5: Create a file named reftest.list with the following:

== foo.html bar.html

One is now ready to run the test. Here is how I run this. Adapt this to your own platform.

% /bin/sh
$ /Users/ray/mo/browser/mozilla/dist/MinefieldDebug.app/Contents/MacOS/firefox -P minefield1 -reftest ./reftest.list 2>&1 | grep REFTEST
REFTEST PASS: file:///Users/ray/moz/reftest0001.html
$

Congratulations! You have just created your first retest!

Quick and Easy Leaks Detection on Mac OS X

If you are using a Mac OS X machine and have Apple's Developer Tools, such as Xcode, on it, you have access to a very quick and easy way to check for memory leaks. Not everyone knows about this, though it has been available for at least a few versions of the Dev Tools, so I thought I would put this out.

If an application is running and you want to see if it is leaking memory, you can do run leaks and give it either a pid as a parameter, or a string matchable to the running process, such as "firefox-bin" or "thunderbird-bin". The string matching only works if only one such process is running. Here is an example:

$ leaks firefox
Found process 260 (firefox-bin) from partial name firefox
Process 260: 1263939 nodes malloced for 147066 KB
Process 260: 76194 leaks for 7262704 total leaked bytes.
Leak: 0x19aeea00  size=4096
      0x0d0a0d30 0x6320740a 0x7373616c 0x7462223d
      0x7420226e 0x3d657079 0x62757322 0x2274696d
      0x6c617620 0x223d6575 0x646e6946 0x64692022
      0x6966223d 0x625f646e 0x6f74746f 0x3c3e226d
      0x726f662f 0x2f3c3e6d 0x0a3e696c 0x3c20200a
      0x3c3e696c 0x6e617073 0x616c6320 0x223d7373
      ...
Leak: 0x19968200  size=1024
      0x6d6c6f63 0x68697074 0x00000008 0x00000000
      0x43fa8000 0x43ba0000 0x00000000 0x00000000
      0x6b6d6f64 0x6d61676e 0x00000004 0x00000000
      0x00000000 0x00000000 0x00000000 0x00000000
      0x77696e64 0x77696e64 0x00000004 0x00000000
      0x776d6f75 0x68697074 0x00000008 0x00000000
      0x43f60000 0x43aa8000 0x00000000 0x00000000
      ...
Leak: 0x20b1a200  size=1024
      0x6d6c6f63 0x68697074 0x00000008 0x00000000

This one actually goes on for about 350,000 lines. I had been running this instance of Firefox 2.0.0.1 for about an hour, but with a lot of tab use.

You can get stack frames and symbols in the stacks of leaked objects if you set environment variables that are explained in the man page.

I think there is a lot of room for improvement in controlling memory leaks.

There is actually much more I could say about this, but that is for another discussion. Really, I just wanted to say, here is a tool. It gives information. It is pretty accurate. If anyone has questions about using it, check the man page for the leaks executable, or feel free to ask me.

Testing Thunderbird as a Standalone

I do not want to mess up my e-mail account, but I do want to help test Thunderbird. I was able to install a James server from Apache on my machine. This is a mail server written in java. It was not very complicated to set up.

At this point, I have the James server configured. I have sent mail to one of my users using telnet to talk to the SMTP port. I have received that mail in Thunderbird. I have used these TB instances to send mail to each other. And I now have a script that can send messages to the clients.

The tasks for setting this up are:

1) download and configure James.
2) create profiles in Thunderbird and launch a different instance for each.
3) use the clients to e-mail each other.
4) use a script to send e-mails.

Configuring James

I am using James 2.3.0 from Apache. I have only made a few changes to a file, apps/james/SAR-INF/config.xml.

1) I commented out a "mailet":


<!--
<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor">
<processor> relay-denied </processor>
<notice>550 - Requested action not taken: relaying denied</notice>
</mailet>
-->


This mailet was causing the mailer to think I was treating it like an open relay.

2) I changed an item inside the <servernames> bit:


<servername>10.0.1.6</servername>


This is the IP of the machine I am using when I am inside my house's firewall.

3) Inside the <remotemanager> bit, I changed the admin username and password. You do not have to, if you do not want to do so.


<account login="root" password="root"/>


4) Start the server.


% cd james-2.3.0 ; sudo bin/run.sh


5) Add some users.

One does this by using telnet to connect to the "remoteadmin" port, which defaults to 4555. Here is an example of adding usersm, with the stuff I typed in bold:


% telnet localhost 4555
Trying ::1...
Connected to localhost.
Escape character is '^]'.
JAMES Remote Administration Tool 2.3.0
Please enter your login and password
Login id:
ray
Password:
<mypassword>
Welcome ray. HELP for a list of commands
help

Currently implemented commands:

help - display this help
listusers - display existing accounts
countusers - display the number of existing accounts
adduser [username] [password] - add a new user
verify [username] - verify if specified user exist
deluser [username] - delete existing user
setpassword [username] [password] - sets a user's password
setalias [user] [alias] - locally forwards all email for 'user' to 'alias'
showalias [username] - shows a user's current email alias
unsetalias [user] - unsets an alias for 'user'
setforwarding [username] [emailaddress] - forwards a user's email to another email address
showforwarding [username] - shows a user's current email forwarding
unsetforwarding [username] - removes a forward
user [repositoryname] - change to another user repository
shutdown - kills the current JVM (convenient when James is run as a daemon)
quit - close connection
quit
Bye

Connection closed by foreign host.

%


Creating Profiles

Moz-people know how to do this already. Just set up a profile for each user in the list you added in the step above.

Creating Profiles

Moz-people know how to do this already. Just set up a profile for each user in the list you added in the step above.

Sending E-Mails From Clients

Just set the mail host and sender to the IP address of your machine and enter e-mail addresses as, for example: adam@[10.0.1.6], with the brackets. I am trying to find a way to set a preference to change the title of the main window. For instance, it would be useful to have the window title be the same as the e-mail of that profile. I have not found how to do this yet.

Scripted E-Mails

Download the following two files:

• muchMail.sh


• inMail.txt

I still need to put in parameters for some things. Right now, you say:

% ./muchMail.sh -h 10.0.1.6 -i inMail.txt

There are keywords in the file that get replaced dynamically, such as __DATE__. Some are structural keywords, such as __TO__, __FROM__, __SUBJ__, __END__.

Let me know how much this needs to be documented. Lines starting with a # are ignored. E-mails start with a __TO__ and end with a __END__.