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. :-)