Silver's Simple Site - Weblog - 2005

The world is at an end, I have a weblog. Things can only go downhill from here...

My time is slowly wasting away. Silly paid work. Still, money is money. Kinda.

New PC is still in bits, unfortunately, due to a rather important lack of PSU. There'll be some harsh words about this tomorrow!

Aaaah, a web-based posting system always feels so much better. Next stop, web-based editing...

Edit Ok, so the preview form is screwing up the <textarea>. *sigh*

Boy do they have a lot to answer for. The company I work for uses it, and believe me, it makes a right mess of the code. Not to say other HTML editors don't, but when I'm trying hand edit some code (so it, you know, works in non-IE browsers) and I see this:

  <td>
    <div align="left"><strong></strong></div>
    <div align="right">
      ...

I really start to get annoyed.

I get the feeling sometimes users don't really want any help, they just want to annoy those trying to help. You suggest they try X or Y, and they say that they copied some example from place Z. So you ask for a URL, and they give you one... you point out the major bit they didn't copy correctly, and they claim they are "just following the examples" and ignore anything you suggest again. Times like these I wonder why I ever tried to help in the first place...

Sucks.

For those wondering, yes, commenting will be added to this weblog at some point. Not sure when, depends how much work I want to do... but it shouldn't be too hard.

My build box actually ran out of virtual memory trying to link libxul yesterday. Scary. Luckly my new box (still in bits) will have somewhat more than 256MB RAM so it shouldn't even need VM to link!

Ah, that was a fun exercise indeed. I've now got an RSS feed of the last 10 posts, which your browser should pick up automatically.

This is a test weblog post which I will be using for testing some new features on over the next few days. Please don't be alarmed if new features appear here first!

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.

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

So, I added --enable-svg and --enable-canvas to my Mozilla Firefox build config the other day. Apparently that forces me into building Cairo, which, um, doesn't build.

m:\source-HEAD\mozilla\gfx\cairo\cairo\src\cairo-win32-private.h(43) : warning C4005: 'WINVER' : macro redefinition
        command-line arguments :  see previous definition of 'WINVER'
../../../../../../source-HEAD\mozilla\gfx\cairo\cairo\src\cairo-win32.h(66) : fatal error C1189: #error :  Cairo was not compiled with support for the win32 backend

make[4]: Leaving directory `/cygdrive/m/tree-firefox-debug/objdir/gfx/cairo/cairo/src'
make[3]: Leaving directory `/cygdrive/m/tree-firefox-debug/objdir/gfx/cairo'
make[2]: Leaving directory `/cygdrive/m/tree-firefox-debug/objdir/gfx'
make[1]: Leaving directory `/cygdrive/m/tree-firefox-debug/objdir'
make: Leaving directory `/cygdrive/m/tree-firefox-debug/objdir'

Update: It seems that, on way or another, I ended up with cairo-features.h in the srcdir without it being listed in CVS\Entries, so it never got removed. Thanks to vlad who suggested looking for that file in other locations. Let's hope it builds now.

You know how you get the feeling of what day it is by how well things go? Well, today has definately been a Monday - and a bad one. Not so much bad as in hardware blowing up, or injuries or anything, just people out to get me. All of them.

Dontcha just love 'em? My work suddenly seemed to decide that everything you could think of needed changing/doing with the project, and with the deadline at 1pm! Oh, and we had some fun with rsync not setting the times on the synced files for part of the day. I've done over 18 hours work over yesterday and today, and man I'm worn out.

And my PSU hasn't arrived yet. europc--

poof

I'm off down to London again, so don't expect any bug fixin' 'til Friday!

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/

Ever had the feeling the program is simply mocking you? Try doing addEventListener("foo", null, false) in a recent Mozilla or Firefox and you might understand.

It doesn't just throw an error (which seems a fairly sensible thing to do, given I'm providing bogus data), it throws a null error. That's not an error which says only "null", the actual error object itself is null! What gives?

With my basic knowledge of how XPConnect & co. work I can't work out how this can happen normally. The following three cases are what normally happens:

• If it can't convert the input data to make the wrapped call, you get a huge long error about "arg 1" or whatever.
• If the native code returns a failure code, you get an exception generated by XPConnect (which is just as excessive as the argument error one).
• If the native code returns a success code, you get the _retval, and not an exception.

This leaves only one option I can think of: the native code is returning a failure code, but also setting the XPConnect exception object explicitly to null (which allows native code to return nice exceptions to JS and other scripted languages, while still returning the 'nice' NS_ERROR code to native callers). I just can't find out where.

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

It's finally arrived! Wooyay wooyay!

Not that I'm there, of course, but it means me new box will work when I get home.

My new box (GALINSTAN) is up and working great - I'm writing this from it. However, it is running Windows XP 64bit (which is great fun) and I lack wireless cards that have network drivers (from what I can find out, only one or maybe two companies have got 64bit drivers currently, which is a shame). So I decided to simply route the small physical LAN in my room through one box that can use the wireless. Here's a summary of before:

Nice and simple - each box is on both the wireless (main) LAN using DHCP and also on my physical mini-LAN by fixed IP. I added Galinstan thus:

Then came the fun bit. I needed one of the three original boxes to route between the networks. So I just enable IP routing, right?

A few hours later, I finally found the key - literally.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  IPEnableRouter: 0x00000001

Set that and reboot. At least ipconfig /all agreed with me now. Of course, it's all very well having the box route, but everyone else needs to know this...

This was easy, luckly, and just involved setting the gateway on each box (BRONZE, SILVER, GOLD and GALINSTAN) to 41 (i.e. GOLD), which I'd picked to be the router. That almost works - packets go flying out onto the wireless network, but of course the replies don't know how to come back! So a single persisten route was added to PLATINUM (the wireless router box) to route anything for the physical mini-LAN to GOLD's wireless IP (which I'd now reserved in the DHCP server so it was effectively static).

Whew.

It worked.

I now have 4 boxes in my room, all with 'net access, and all accessible from the house router (meaning I can forward public ports to them for services as nessessary).

- Arthur Dent, The Hitchhiker's Guide To The Galaxy, by Douglas Adams

You all know what I mean.

On a slightly better note, mozilla.org finally decided to start telling developers what is going on. About time, too.

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.

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!

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.

FTS? Whatever, Mozilla Update is not doing itself any favours. Apparently (according to the developers' page) version 1.0.1 of my extension was denied, despite it being a simple bug-fix over 1.0.0 (which was approved). Naturally there is no indication as to the reason. I would check my mail, but I can't. I've waited two (or is it three now?) days to get this far, and it sucks.

What really worries me is that it may have been denied just because it was a different reviewer. "How does that work?" I hear you ask. Simple. My extension, while small at only 5KB, does a lot of poking at the Windows Registry to do its job. This is not trivial stuff, and it is known to not always work (I can't find any platform/setup locally that fails, however, which doubly-sucks). Version 1.0.1 is better at working that 1.0.0 - it actually fixes a very specific bug for Firefox 1.0.x users, for example.

Yet all it takes is one reviewer who has a system where it happens to not work and all the users lose out. Bring on the multi-reviewer system - oh, and a few times more reviewers too.

So Gecko 1.8 is branching on Friday, and there are only 126 bugs to fix before tomorrow night. Good luck!

Update: Oops, seems they're using bug 300860 to track blocking for the branch, so only two bugs left. This will be very amusing, however, when they realise they have a branch with 120 bugs to fix on it.

So the RSS button is gone from the statusbar, and now appears inside the URLBar. Yes, you heard me (and saw, too). So we now have a less-discoverable, less accessible, less flexible solution (no popup menu with a list of feeds any more!). And to top it all off, they are viewed in a hacked-up badly-integrated version of the Feedview extension (note: I have no idea if the Feedview extension suffers from any of the same issues as Firefox does, and don't mean to imply such), meaning you get suck and more suck, including such gems as bug 302749.

Since the menu change in Firefox to make the menus look like WinXP's themed style on all versions of Windows, rather a lot of people have been upset. Quite understandable, really, as the change has just made Firefox's menus look seriously lame on non-themed systems.

So much is the annoyance, that I've gone and started hacking nsNativeThemeWin.cpp to try and make it support theming menu components on Windows. It ain't pretty, but I've managed to fix some bugs with the toolbox and toolbar appearances already (which help a lot), and have got basic themed menupopup and menuitem support going. It lacks the classic appearance currently but, now I know my way around, that should be easier.

Well, it's taken a few days of work, but Firefox's finally look right in the Luna XP, Windows XP and Windows Classic themes. Woo.

In case you hadn't guessed, I don't believe there is any way my work to fix Toolkit's toolbar and menu appearances on Windows will make it into Firefox 1.5. The patch has been ready and waiting for review since 2005-09-18, yet it'll still completely miss. All it does is demonstrate the problems with the review process. :-(

Also, I've stopped working on the menu shadows bug due to yet more Mozilla.org politics (drivers, again).

They've gone and done it folks. Without any warning, they have suddenly decided that my branch-only ban-aid needs to land on trunk for baking. WTF?

It seems that only one regression has so far turned up from the unexpected trunk landing. That's a bit of surprise itself, but there you go.

I'm still expecting drivers to say "actually, no" to the whole thing landing on branch, even though Asa did set blocking1.8rc1+ on the 5th, but we'll see. Asa himself is already going and minus-ing quite a lot of stuff, so things don't look good.

I have now totally run out of patience with drivers, and I honestly don't know what I'll do the next time the screw me or any of 'my' bugs about.

Yes, they forced the theming patch on to branch, but they also screwed it up, in two ways. It is both impressive and unbelievably embarrassing.

Well, that's it folks. The patch is no longer in the branch, and the menus in Firefox 1.5 will look like crap unless you use the Windows XP default 'Luna' theme.

I wont go in to any more detail than I did in the bug, though I will say that I will continue with this work on trunk for 2.0, due next millennium.

Well, I was bored one night and as usual, the result is something useful, but only to me. Having 4 computers here makes things weird enough, but now I can check the status of my build box (and will soon be able to queue up commands) from the web browser on my main desktop - all via my web server box. Wheee!

This is just to outline my plans for working on native theming for menus and toolbars, and related bugs:

• First priority is to get the pure-CSS appearance in winstripe right. The target appearance is Windows XP Classic. This is being worked on in bug 313388. This is currently going well, and is nearing completion.
• One single native bit will be written with the pure-CSS version - -moz-MenuBarHoverText, which will be (at this stage) implemented (on platforms which use winstripe, or maybe all) to work exactly like the CSS colour chosen for the hover text colour.
• The above work will be checked in to trunk CVS (after reviews, etc.) and will remove the -moz-appearance properties currently there. This will mean everyone will see the pure-CSS appearance, and this is exactly what is intended.
• Any problems found with the pure-CSS appearance (excluding, obviously, "it's not themed!" which I know a few idiots will file) will be fixed at this point, as once the native code is re-enabled, only odd groups of people will ever see it again (OS/2 users, for example).
• At this point, there will be an expected regression with the Firefox Bookmarks toolbar, which will be fixed (the exact method is yet to be decided).
• Work will then begin on the native code necessary to support the theme engine in Windows XP. This may involve some minor tweaks to the CSS, but the ideal result is that only -moz-appearance properties are added. -moz-MenuBarHoverText will be adjusted (on Windows only) to follow the correct rules for menu bar text with themes.
• This will be reviewed and checked in, and that will be it done.
• Regressions will be fixed here, of course. :-)

It may seem like a long-winded way of doing things, but it will mean you get a top-quality result, as each key part will be written separately, tested separately, and checked in separately (for regression spotting).

I've noticed a few bugs and general issues with my weblog software today, so I'll just write it down so you know and I don't forget to fix it on Friday or at the weekend.

• RSS feed for comments is needed (both for each post, and globally).
• RSS feed for tag list, and for posts in each tag needed.
• RSS feed for each date grouping allowed, maybe.
• If you preview a comment post for a second time, the URL gains an extra "/", which messes up the stylesheet loading and the page title.
• Link to next month is broken when next month is December (the page title is right, but it is using month 00, instead of 12).
• Link to next/previous month doesn't change year if wrapping is involved.

Ever since bsmedberg landed bug 313309 part 2, I've been getting the following build error:

 nsIInterfaceRequestorUtils.cpp
 Building deps for ....../../source-HEAD/mozilla/xpcom/glue/nsIInterfaceRequestorUtils.cpp
 nsIInterfaceRequestorUtils.cpp
 m:\tree-firefox-main\objdir\dist\include\xpcom\nsIProgrammingLanguage.h(35) : warning C4003: not enough actual parameters for macro 'NS_DEFINE_STATIC_IID_ACCESSOR'
 m:\tree-firefox-main\objdir\dist\include\xpcom\nsIClassInfo.h(36) : warning C4003: not enough actual parameters for macro 'NS_DEFINE_STATIC_IID_ACCESSOR'
 ../../dist\include\xpcom\nsIInterfaceRequestor.h(41) : warning C4003: not enough actual parameters for macro 'NS_DEFINE_STATIC_IID_ACCESSOR'
 m:\tree-firefox-main\objdir\dist\include\xpcom\nsISupportsUtils.h(202) : error C2039: 'GetIID' : is not a member of 'nsIInterfaceRequestor'
        ../../dist\include\xpcom\nsIInterfaceRequestor.h(38) : see declaration of 'nsIInterfaceRequestor'

This is the same error that the 'creature' tinderbox was getting, but unlike that machine, it didn't go away after all the bustage-fixes.

After nuking objdir/dist and objdir/xpcom/base - neither of which helped - I just nuked objdir/xpcom and it finally looks like it might work, having got twice as far into the build as the error point (though it would not surprise me if I needed to nuke other totally random directories later).

The build system is just broken.

It's getting to the point where I'm tempted to make an auto-build-fixer, that just keeps nuking random objdir folders until it works. It would be a more productive use of my time than fixing all these damn problems by hand.

I've gone through and fixed all but one of the items listed previously. The only item remaining is the RSS for tags and the tag listing itself.

If you find anything is not working, please do comment, and I'll fix it. Please note that the comments feed is not linked from anywhere, as it is only useful for me monitoring new comments.

Continuing from my previous post about my Mozilla build tracker, I've added progress bars to the display while it is building. Naturally, it's all done with smoke and mirrors [1], and (perhaps surprisingly) doesn't mess up the display on Internet Explorer at all, though it doesn't show the progress bar.

Actually, thanks to the IE DOM Explorer, part of the IE Developer Toolbar (download from here), I've just fixed the progress bar to work in IE. Woo!

[1] Unofficially, it is all done with CSS, DIVs and PNGs, but we don't like to talk about them...

[2] Worryingly, it is more usable than Mozilla/Firefox's DOM Inspector, for me. I think it's partly that the select-by-click in the IE DOM Explorer totally trumps the same feature in Mozilla/Firefox.

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!

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.

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.

Well, I finally got around to nuking that annoying ".pl" in the weblog's URLs - all the URLs should now not include it. Naturally, I've put a redirect from weblog.pl to weblog, so no links should break.

It took quite a bit of thinking, but it works - not showing file extensions is not one of IIS' strong points, however, it has more than enough power to do it if you know what you're doing. :-)

Please comment here if you find any bugs or other issues with this change, or indeed any part of the weblog system.

It's nice to see a good bit of collaboration over something as visually important to users as icons. Since this is all good for the user, Feed Icons has sprung up to help everyone follow suit, and so my weblog now has those funky little orange icons in the top-right corner of every page with a feed.