Silver's Weblog - Tag - 'ChatZilla'

Some people know about the ChatZilla Release Console, a slightly unstable and very dynamic page which displays the bugs planned for the next ChatZilla release or two (as well as an archive of bugs fixed in older versions). It's been around a while, and works in IE 7 and Firefox 2, but it is pretty heavy on the dynamics, and some people have had it completely hang Firefox on occasion.

To address this, I have created the ChatZilla Static Release Console, which is entirely static HTML (and CSS), created by Perl on my server rather than JavaScript on the client. It doesn't even have a META refresh. You can also get it to view a specific release.

ChatZilla users have for a while wanted to get a notification on all messages, but we've never considered it important enough to warrant fixing individually, instead opting to recommended some workarounds:

• Add all vowels/letters to the Stalk List, thus triggering the normal stalk matching on (almost) every message.
• Write a simple script, but never providing one ourselves.
• Wait for the new message filtering which will be able to do it, among many other variations.

Today, another user asked for this feature, and I caved in and wrote a script to do it. To install the script:

1. Find the scripts folder. You can use either /pref profilePath or /pref initialScripts since the latter defaults to the scripts subdirectory of the former. You want the scripts subdirectory, if that wasn't obvious.
2. Create a new directory for this script. My suggested name is message-notify, just to match the script's ID, but ChatZilla doesn't care.
3. Save the script itself into the new directory, making sure to name it init.js.
4. Reload all scripts with /eval processStartupScripts(). This will reload all the scripts found in the subdirectories of the scripts directory - including the new one.

The following message categories trigger the script, but only when the window is inactive (nothing happens if the window is active):

• channel:privmsg
• channel:action
• channel:notice
• channel:join
• channel:part
• channel:quit
• channel:kick

The script has two preferences:

• sound - specifies what sound to play when a message arrives. Defaults to beep, and can accept the same things as the standard ChatZilla sound preferences (namely, a file: URL, beep or none).
• attention - specifies whether to grab the user's attention, which usually means flashing the window but can vary by platform. Defaults to true.

Enjoy.

Now that it has been officially stated that XULRunner is dead, it is time for a ChatZilla Roadmap Change™.

The original XULRunner and ChatZilla plan was to wait until the 1.9 version of XULRunner was officially distributed - 1.8 was never going to have the necessary shared UI or support - and then produce a ChatZilla package that works on it. Ideally, we would use the same XPI as for Firefox, SeaMonkey, etc. installs, although there were/are still some pretty critical hurdles to overcome for that to work. Even if it was a separate XPI, it would be a normally-size ChatZilla XPI, and could be on Firefox Add-ons.

So much for that.

After getting over the initial WTF? reaction, we need to decide on the way forward for ChatZilla on XULRunner. Thanks to tH's wonderful ChatZilla on XULRunner page (which include mozilla.org built nightlies from the appropriate dates), we do actually have a measurable percentage of our user base running this configuration. A small percentage, but not zero.

• Do we build XULRunner ourselves? This would require a lot of effort on our part, and really should be shared with other projects if possible.
• Do we only make available our ChatZilla package, and tell users to find their own XULRunner (or link to someone else who is making them)?
• Do we give up trying to support XULRunner entirely?

Right now, I don't know, but the last option is looking disappointingly good.

ChatZilla doesn't support HTTP proxies. Well, I say HTTP proxies but this particular thing apparently has far too many names:

• HTTP proxy [X-Chat]
• SSL proxy [Firefox]
• CONNECT proxy
• URL proxy
• Secure proxy
• (incorrectly) HTTPS proxy
• Proxy protocol [mIRC]

Personally, most of them are completely meaningless terms. HTTP proxy is what everyone (except Ben C) calls it.

The problem that we face is relatively simple from the top, but a real pain to actually fix: we ask Necko (Mozilla's network layer) to pick the proxy to use.

The result is that it will ask PAC if so configured, just return the SOCKS v4/v5 proxy, or return no proxy. The user has no way to configure Necko to give IRC the HTTP proxy.

There are a few things we can do, none of which seem that good:

• Add a single option to force ChatZilla to use Necko's HTTP proxy.
• Add an option to pick between none, HTTP proxy and SOCKS proxy.
• Add an option to override Necko, and also add host/port settings.

The real problem is that adding any options will be creating two locations for proxy configuration. Could we automatically pick when to ignore Necko's choice? Maybe. Should we? Probably not.

If only I got paid for doing this...

It is coming, eventually. The plan for last Sunday didn't quite work out, but we're now ready to go and should be rolling it out this coming weekend instead. To come in this version:

• /who now accepts multiple parameters (useful for some of the more extended syntaxes some servers support).
• A small leak for plugins has been fixed.
• Sending files with DCC closes the file handle in more cases so it shouldn't stay locked after.
• When midnight happens, the messages about the logs changing have been suppressed.
• If your connection to a server drops, ChatZilla will now try to reconnect to the same server first, before moving on to the next one in the list.

We're actually getting some interesting data coming it from the instrumentation startup ping.

In particular, you can see that people updated from Firefox 1.5 to 1.5.0.1 almost the moment it was released.

We can also estimate that there are approximately 1100 new or updated ChatZilla users a week (calculation: sum up new installs [the numbers on the pages linked, 40], divide by the number of days [25], multiply by 700 [1% and we want per-week]).

It's been released, but may take a few days to appear on addons.mozilla.org. This update fixes the userlist/tab switching issue mentioned previously, as well as some less interesting things, like adding support for /dcc-accept with non-regexp parameters.

As ever, the revisions list has the gory details, including bug links and download link for those too impatient for addons.mozilla.org.

I suppose I probably should mention that ChatZilla 0.9.69 has been released. Woo.

We're currently working through a couple of big issues, but the release is great. The main problem anyone is likely to encounter is bug 319066, which should only occur if you select the top user in the userlist, and then switch tabs.

The next ChatZilla release will be called 0.9.69, mostly due to the excess of changes that have occurred on trunk since the last release. This will be the 0.9.68.5 codebase merged to trunk, plus some extra compatibility updates; this means all the trunk changes since then will be included - and there are a lot of them!

Look forward to it!

So much for early-June. Well, the tree is still frozen, which doesn't help at all. Plus reviews are slower than expected. We're also not going to get 0.9.69 out any time soon at all - the next release will be 0.9.68.6, hopefully not too far away now.

We are, however, making slow but steady inroads into the bug list, and have a few people outside the 'core' (Robert Ginda, Samuel Sieb and myself) who are doing patches and generally helping a lot. It sounds like we're going to get a better (ish) reconnect system shortly, too.

Begining build of ChatZilla 0.9.68.6...
 WARNING: output XPI will be overwritten.
 Checking XPI structure.....            done
 Checking JAR structure..               done
 Updating Firefox Extension files.....  done
 Updating Mozilla Extension files....   done
 Constructing JAR package..C:\Program Files (x86)\Cygwin\bin\perl.exe (3972): *** recreate_mmaps_after_fork_failed
ERROR (0)
Cannot determine cygwin mount points. Exiting.
     3 [main] perl 3972 fixup_mmaps_after_fork: WARNING: VirtualProtectEx to return to previous state in parent failed for MAP_PRIVATE address 0x1ED0000, Win32 error 87
   538 [main] perl 3972 fixup_mmaps_after_fork: WARNING: VirtualProtect to copy protection to child failed forMAP_PRIVATE address 0x1ED0000, Win32 error 487
   680 [main] perl 3972 fixup_mmaps_after_fork: ReadProcessMemory (2nd try) failed for MAP_PRIVATE address 0x1ED0000, Win32 error 487
C:\Program Files (x86)\Cygwin\bin\perl.exe (3972): *** recreate_mmaps_after_fork_failed
     6 [main] perl 2916 fork_parent: child 3972 died waiting for dll loading

And thus ended my Cygwin Perl installation. No matter of rebaseall-ing or complete Cygwin reinstalls could fix it, and I don't even understand precicely what the error is.

So a short while later, I had myself an ActiveState ActivePerl install, perl-cygwin.sh (a wrapper I wrote to use ActivePerl in places expecting Cygwin Perl), and some tweaks to makexpi.sh to let me specify the Perl engine (save me doing path & symlink hacks). And thus it did build! Yay!

Everything: you use them almost all the time when using the mouse, and pretty often when using the keyboard - though it varies depending on the app.

ChatZilla's menus have been evolving over time since they first appeared, probably at least 5 years ago now, and are a in a bit of a mess. As part of fixing this, I've drawn up the current menus in the Mozilla Wiki. If anyone wants to move stuff around, into the right place, and add notes, they're welcome to, after all, it's a Wiki.

I will be off down to Cov for the entire week, to generally socialise and stuff. Since multiple companies are sucking heavily with regards to something as simple as getting a PSU to me, the computer I am taking may or may not actually have a PSU in it when I take it. I'm willing to bet it wont. The upshot of this is that I may have significantly limited access to anything Internet-like for a few days, but damn well better be on-line by Wednesday.

Contacting

Since I wont be taking my laptop, twpol.dyndns.org will stay up and fully functioning (bearing with issues like ADSL going pop), and all the usual contact methods will work as good as they ever do.

Note: It seems warwickcompsoc.co.uk has died as of 12:22AM UK BST, suspected to be heatstroke. That wont be back until last morning Monday I suspect.

Marking

I have a mostly working line marker! It's not perfect (when it appears, it doesn't scroll the line into view, meaning it is really hard to tell when it is occuring to the unfocused view), but it works for the most part. Still got some issues with scrollDown and force to sort out...

Filtering stuff is one of those things everyone wants to do, no-one wants to write the code, and even fewer debug it when it breaks. Luckly, this doesn't stop some intrepid people from adding message filtering to ChatZilla.

Of course, the killer questions are:

1. what to filter with, and
2. what to do when a filter matches?

The first question is relatively easy, we only have a limited number of things known about a message anyway.

• Actual message text, of course
• The type of message (PRIVMSG, NOTICE, JOIN, etc.)
• Source (e.g. the user object)
• Destination (e.g. the channel object)
• Handler source. This one is the fun one - it is where the message was displayed 'from', e.g. what code handled it. It may sound useless, except that it will be the default destination if no filters match, and will mean messages for a particular channel will appear on that channel (at least by default!).

That was easy. So what about the actions? They are more fun, as this is where the real flexibility will lie in the system. What I see being included:

• display on source view
• display on destination view
• display on handler view
• display on handler's parent view
• set message priority (superfluous, activity, attention)
• make sound (beep or WAV file)
• activate/flash window
• run some JS?

Update: Draft spec is here: http://hannibal.digitalrice.com/msgfilter/

You don't use those menus, do you? Good, because now you can't in ChatZilla on current Mozilla and Firefox builds! The menus vanished mysteriously one morning, after DOM Inspector got a menu hack-attack. If it weren't for a slight problem with :empty, it'd be ok, but it's not.

Edit: bsmedberg had a good idea to hack around the :empty problem, which I've done into a patch. Hopefully this will be fixed soon in trunk (and will be in 0.9.68.6).

It's in need of some slight attention right now. The main problem is that it always prefers munger entries that were enumerated first, which equates to added first in Spidermonkey (Mozilla's JS Engine).

I filed the bug on it a while ago now, but it recently came to my attention that Wikipedia actually had a script that broke stuff because of it. I've corrected the script with version 1.2 so it doesn't completely break normal links, but the real bug still stands.