exacerbate and incapacitate (and, apparently, progress)

Ah, software. S for stupid, O for OMGWTF?!, F for [expletive deleted] etc.

Weird, weird bugs. Profoundly weird. So, converting from .ico to .png causes the same buffered stream bug(?) to throw a hissy fit and explode ze Prism into tiny shards of glass that hurt your soul. But, the other day when testing I chose a local .ico file, and for some reason it actually converted without crashing. To top things off, the /etc/mime.types entry for .ico was "image/x-ico" which isn't a standard MIME type. So, using a local .ico file caused the MIME service to report "image/x-ico" which in turn actually made Prism convert the .ico to a .png. Even though there is no decoder for "image/x-ico"!

Furthermore, adding a ~/mime.types file (overrides the global in /etc/) and putting the correct "image/x-icon" type there caused the thing to explode once again.

[some time passed here when I started fooling around with my imaginary girlfriend an idea, instead of writing this blog post]

My hunch paid off. Increasing the buffer size for the nsIBufferedOutputStream from 1024 to 4096 (larger than the size of the file that's being converted, it's 1920 bytes) magically disappears the crashiness (this is for .ico to .png with the correct MIME type). And, trying to convert a larger file (21941 bytes) with that 4096 byte buffer still causes a crash (this is from .png to .png). I'd allow myself to call this progress.

I might just add that this crashes a nightly Firefox when using Refractor, so it's not just my XULRunner tree that's covered in ectoplasm. Naturally, I can't recall if all this actually worked earlier.

webrunner webrunner, going faster miles an hour

Oh yeah, the tray code for Linux now has feature parity with the Windows implementation. I never could get a native GtkWindow out of Mozilla, but instead of the whole InterfaceRequestor/Docshell/BaseWindow dance I just called nsIDOMWindowInternal's Focus method and called it a day. (SetZLevel only focuses the window currently.)

I'm contemplating menus for tray icons now. Hacked together some code that builds, but I haven't hooked up the plumbing through JavaScript. My thinking is to pass a menu's nsIPopupBoxObject to the tray code to attach it to an icon that way. Since Prism uses a 1.9 XULRunner, it will have the openPopupAtScreen method, and by getting the position of the tray icon that was clicked to bring up a menu, it can be opened at a reasonably proper location (modulo problems unknown at this time).
If I could get the actual GtkMenu out of Mozilla in some way I could use GTK's own menu positioning code for tray icons, but I don't see that happening.

Since XUL overlays can be loaded on-demand using document.loadOverlay, there's no reason why there couldn't be a webapp.xul overlay for more advanced usage of Prism (like for tray icon menus). But that's not up to me to decide. Perhaps using an extension is preferable in that case.