Silver's Simple Site - Weblog - Tags - Mozilla
Users Who Don't Want Help
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...
Permalink | Author: Silver | Tags: Mozilla, Users | Posted: 07:03PM on Friday, 03 June, 2005 | Comments: 0
Permalink | Author: Silver | Tags: Mozilla, RDF | Posted: 09:14PM on Friday, 03 June, 2005 | Comments: 0
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!
Permalink | Author: Silver | Tags: Mozilla | Posted: 01:24PM on Saturday, 04 June, 2005 | Comments: 0
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.
Permalink | Author: Silver | Tags: Mozilla, ChatZilla, Bugs | Posted: 03:32PM on Sunday, 05 June, 2005 | Comments: 0
File, Edit and View
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).
Permalink | Author: Silver | Tags: Mozilla, ChatZilla, Bugs | Posted: 05:05PM on Sunday, 05 June, 2005 | Modified: 05:41PM on Sunday, 05 June, 2005 | Comments: 0
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: Leaving directory `/cygdrive/m/tree-firefox-debug/objdir/gfx/cairo/cairo/src'
make: Leaving directory `/cygdrive/m/tree-firefox-debug/objdir/gfx/cairo'
make: Leaving directory `/cygdrive/m/tree-firefox-debug/objdir/gfx'
make: 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.
Permalink | Author: Silver | Tags: Mozilla, Firefox | Posted: 09:51PM on Sunday, 05 June, 2005 | Modified: 01:28AM on Monday, 06 June, 2005 | Comments: 0
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:
what to filter with, and
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)
run some JS?
Update: Draft spec is here: http://hannibal.digitalrice.com/msgfilter/
Permalink | Author: Silver | Tags: Mozilla, ChatZilla, RFE | Posted: 04:13PM on Friday, 10 June, 2005 | Modified: 09:57AM on Tuesday, 14 June, 2005 | Comments: 0
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.
Permalink | Author: Silver | Tags: Mozilla, XPCOM | Posted: 10:38PM on Sunday, 12 June, 2005 | Comments: 0
I Never Could Get the Hang of Thursdays
- 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.
Permalink | Author: Silver | Tags: Life, Mozilla | Posted: 07:57PM on Friday, 08 July, 2005 | Comments: 0
What's in a Menu?
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.
Permalink | Author: Silver | Tags: Mozilla, ChatZilla, Bugs | Posted: 04:45PM on Tuesday, 12 July, 2005 | Comments: 0
Mozilla Update FTS
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.
Permalink | Author: Silver | Tags: Mozilla, UMO | Posted: 03:12AM on Monday, 01 August, 2005 | Modified: 03:12AM on Monday, 01 August, 2005 | Comments: 0
Branching on Friday?
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.
Permalink | Author: Silver | Tags: Mozilla | Posted: 12:44PM on Wednesday, 10 August, 2005 | Modified: 03:29PM on Wednesday, 10 August, 2005 | Comments: 0
RSS is dead, long live Feedview
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.
Permalink | Author: Silver | Tags: Mozilla, Firefox | Posted: 09:34PM on Friday, 12 August, 2005 | Comments: 0
To be themed or not? That is the question
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.
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 03:10PM on Saturday, 10 September, 2005 | Comments: 0
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.
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 09:19PM on Sunday, 11 September, 2005 | Comments: 0
It'll Never Make It
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).
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 01:02AM on Monday, 03 October, 2005 | Comments: 0
Drivers Pull Stupid Stunt
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?
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 01:11PM on Thursday, 06 October, 2005 | Comments: 0
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.
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 11:04PM on Monday, 10 October, 2005 | Comments: 0
There Is No Headline That Adequately Explains This
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.
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 01:00PM on Wednesday, 12 October, 2005 | Comments: 0
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.
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 07:31PM on Friday, 14 October, 2005 | Comments: 0
Building the Builder
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!
Permalink | Author: Silver | Tags: Mozilla | Posted: 10:46PM on Saturday, 22 October, 2005 | Comments: 0
Native Theming on Windows
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).
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 12:56AM on Wednesday, 02 November, 2005 | Comments: 0
Mysterious Build Errors
Ever since bsmedberg landed bug 313309 part 2, I've been getting the following build error:
Building deps for ....../../source-HEAD/mozilla/xpcom/glue/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.
Permalink | Author: Silver | Tags: Mozilla, XPCOM | Posted: 02:26AM on Saturday, 12 November, 2005 | Comments: 0
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 , 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!
 Unofficially, it is all done with CSS, DIVs and PNGs, but we don't like to talk about them...
 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.
Permalink | Author: Silver | Tags: Mozilla, IE | Posted: 03:23AM on Friday, 18 November, 2005 | Comments: 0
The Mozilla Foundation are really trying my patience with two issues right now:
No tinderbox graphs.
No despot (user accounts thing).
In both cases, the relevant pages have simply been blocked, returning error 403 or 500 and no information whatsoever has been provided. The closest I got was after filing a bug for the first one, where I got a comment from one admin of "That's on purpose. The script has issues.". The only information on the Despot issue is "security" - fat lot of good that is!
I'm am going to assume that both things are currently exploitable, which means that they should be fixing them, which they do not appear to be doing. If they know they can't fix them fast (or don't care), as appears to be the case, where's the bloody message saying so? It's absolutely appalling.
Permalink | Author: Silver | Tags: Mozilla | Posted: 07:51PM on Saturday, 07 January, 2006 | Comments: 0
Technology vs. Common Sense
If you ever thought e-mail <--> newsgroup gateways were a good idea, think again. I think the following quote sums it up absolutely perfectly:
This is horrible. It feels like I’m playing some 21st century Web 2.0 version of “telephone”.
Permalink | Author: Silver | Tags: Mozilla, Newsgroups | Posted: 12:36PM on Thursday, 30 March, 2006 | Comments: 0
And So It Begins
Here we go again, and this time I'm not in the mood for any shit. I just want to warn everyone that if I get messed about with this again, I'm just going to stop. They can find some other deluded soul to fix their mistakes next time.
Permalink | Author: Silver | Tags: Mozilla, Theming | Posted: 04:09AM on Sunday, 09 April, 2006 | Comments: 0
It's not a good day, and there's plenty to piss me off:
Someone broke the authentication for Trac (wants-to-be-Bugzilla when it grows up thing) for the IRC bot I work on.
Possibly same someone put a disrespectful message on the test version of the new Computing Society website.
Still no-one wants to review the patch which is blocking my theme work.
My ISP is dropping my ADSL connection an average of 15 times a day for the last two weeks.
Permalink | Author: Silver | Tags: Mozilla, Theming, Bugs | Posted: 02:14PM on Saturday, 20 May, 2006 | Comments: 0
Debugging Hung Scripts
There's some good fun work out on in bug 341764 allowing you to just smack "Debug" on the ultimate in annoying dialogs. I'm going to love that when it's done.
(Only two days to go!)
Permalink | Author: Silver | Tags: Mozilla, Venkman | Posted: 01:49PM on Saturday, 17 June, 2006 | Comments: 0
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.
Permalink | Author: Silver | Tags: Mozilla, ChatZilla | Posted: 03:43PM on Wednesday, 21 June, 2006 | Comments: 0
The Art of the Proxy Configuration
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]
(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...
Permalink | Author: Silver | Tags: Mozilla, ChatZilla | Posted: 03:48PM on Tuesday, 04 July, 2006 | Comments: 0
What Value Tinderboxes
The Mozilla Foundation did a major colo move on Saturday. Naturally, all the tinderbox trees were closed from Friday evening so that no-one tried to do anything silly during the move.
Now, it is Monday and the current tree has the following tinderboxes:
Linux comet Dep release
Linux lhasa Dep release (gtk2+xft)
Linux nye Dep bloat
MacOSX Darwin 7.9.0 planetoid Dep (temporary)
MacOSX Darwin 8.7.0 bm-xserve02 Dep Universal release
And the only reason the tree is currently still closed is this:
"The tree is CLOSED until we get luna or btek tinderbox up, for reliable Tp coverage."
Both luna and btek are Linux tinderboxes. That means that no-one cares that there are no Windows build boxes currently up and running properly. Seriously. That is just lame.
There is no way I am checking a single thing in until we have a decent set of builds testing the most-used tier 1 platform.
Permalink | Author: Silver | Tags: Mozilla | Posted: 07:46PM on Monday, 17 July, 2006 | Comments: 0
Have a nice day. You bitches.
Permalink | Author: Silver | Tags: Mozilla | Posted: 09:01AM on Wednesday, 23 August, 2006 | Comments: 0
Time for a New Roadmap
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.
Permalink | Author: Silver | Tags: Mozilla, ChatZilla, XULRunner | Posted: 03:19PM on Monday, 14 May, 2007 | Comments: 0
Mozilla Error Lookup now has LDAP and CMS
For many years, the code behind the Mozilla Error Lookup has been unable to correctly include the LDAP and CMS error codes, as the C++ definitions used the IDL constants and the script is just not smart enough for that.
It is now.
That means that all the error code definitions it can find are now correct and can be found from their numeric forms. Enjoy.
Permalink | Author: Silver | Tags: Mozilla | Posted: 11:58PM on Friday, 03 August, 2007 | Comments: 0
Powered by the Content Parser System, copyright 2002 - 2020 James G. Ross.