1. Right click on the toolbar and select “Customize…”

   

2. Check the “Use Small Icons” checkbox and then click “OK”.

   

3. Enjoy!

   

A big thank you to everyone who helped, especially Keith, Rob and Ben.

Subversion began to fail looking up DNS requests. I could only reproduce the problem when buildbot was running svn. If I logged in, I could run the exact same commands myself. And even more curiously, telling buildbot to run nslookup svn.adiumx.com worked completely fine.

I “solved” this by having the buildbot master (on a Linux machine) doing the lookup and then telling the client to checkout svn://<ip here>. If the IP of the subversion server changes, we just need to do a clean build and it’ll pick up the change. It’s not a great solution, but definitely workable.

This worked either briefly or perhaps not at all, I don’t recall, because our automated tests began failing like so:

/Developer/Tools/RunUnitTests:298: note: Started tests for architectures 'ppc i386'
/Developer/Tools/RunUnitTests:301: note: Running tests for architecture 'ppc'
Wed Feb 13 02:07:40 smew.adiumx.com otest[41048] <Error>: kCGErrorRangeCheck : On-demand launch of the Window Server is allowed for root user only.
Wed Feb 13 02:07:40 smew.adiumx.com otest[41048] <Error>: kCGErrorRangeCheck : Set a breakpoint at CGErrorBreakpoint() to catch errors as they are returned
2008-02-13 02:07 otest[41048] (CarbonCore.framework) FSEventStreamStart: ERROR: FSEvents_connect() => (ipc/send) invalid destination port (268435459)
FAILED TO GET ASN FROM CORESERVICES so aborting.
/Developer/Tools/RunUnitTests: line 301: 41048 Abort trap              arch -arch "${TEST_ARCH}" "${TEST_RIG}" "${TEST_BUNDLE_PATH}"
/Developer/Tools/RunUnitTests:314: error: Test rig '/Developer/Tools/otest' exited abnormally with code 134 (it may have crashed).
** BUILD FAILED **

This is particularly strange because again, I can run these tests manually and get proper results. Same user buildbot is running in (and that user is logged in to the machine and has a window server connection), same checkout, same everything, near as I can tell.

This may or may not be superstition and it is probably just a coincidence, but sometimes these tests do run, and it seems that when I am logged in to the machine via ssh things work OK. But after I log out, things go screwy again. It’s something screwy with that particular machine — I had the buildbot slave running on a Mac mini while I was at Mozilla and it worked just fine.

I’ve run a permissions repair. It fixed some things. Still no dice. Buildbot is using the python installed by Leopard. The machine is fully updated, none of that fixed the problems (not even the Leopard graphics update). This machine is located at a colo somewhere inaccessible (Mars?), so while doing an archive and install would normally be my next step, I don’t have easy access to the machine.

I’ve done everything I can think of that I can do easily. Help me blogosphere, you’re my only hope.

I’m trying to say that Planet will only be syndicating the Mozilla category of my blog now, which will only contain boring, Mozilla-related entries, and none of the super awesome non-Mozilla related entries. BUY SUBSCRIBE NOW!

I’m hoping that having a more self-selecting audience will encourage me to post more, and about things other than programming — likely current events, things happening in my life, and just in general more. I really enjoy writing and would like to do more of it.

I also think I’m going to take a little bit different tone here. Daniel Jalkut and Brent Simmons, both at one time the author of the amazing app MarsEdit have said that one of the points of MarsEdit is to make blogging as easy as email. Well, I’ve been writing my blog with a different voice than I use when writing email, so that’s probably going to change too, again the intent being to get me to blog more.

I’ve got a lot to say, and this place is about to become quite the soapbox. So prep your feed readers and get ready to, uh, read some blog entries in a couple of days. Yes.

It’s been a good run, but I need to move on to see what other opportunities are out there. I’m honored to have had the fine folks at MoCo as my colleagues this past year.

I hope 2008 will be as wonderful and enriching as 2007 was.

So we decided to revert the changes to Pinstripe we made for beta 1. Here’s what beta 2 will look like on Tiger:

And Leopard:

Not the snazziest looking, but hopefully it should tide people over until Proto is finally ready :)

If you feel the need to digg/reddit this, use these instead of submitting a new one for this blog post.

See you on IRC!

First off, it seems like that information is stored in the com.apple.metadata:kMDItemWhereFroms extended attribute, which is a binary plist. Use mdls filename to view just the Spotlight information about a file. First item seems to be the URL, and the second is optional and contains the referrer.

That’s all well and good, but what’s actually causing that dialog to display, and then go away again later?

So using the shiny new xattr utility, I took a look around. I found the com.apple.quarantine key. For a typical Safari download, it looked something like this:

com.apple.quarantine: 0000;4727b833;Safari;211E2770-C08D-487B-A602-3EDBC7D34124|com.apple.Safari

For a Firefox (Minefield actually) download it looks more like this:

com.apple.quarantine: 0000;4727bb8d;Minefield;|org.mozilla.firefox

The GUID is probably related to the kMDItemWhereFroms, and is what the dialog is actually pulling the “Show Web Page” and “downloaded from” information. By the way, it turns out that attribute gets set for all writes, including caches, Firefox profiles, etc. Probably a good thing.

fs_usage data supports the theory that that mdworker is seeing the kMDItemWhereFroms attribute and setting com.apple.quarantine appropriately, but I can’t really be sure yet (I haven’t tried DTrace).

I was still a little confused (and concerned) as to how Apple was setting this bit on writes from Firefox, which has no special code, or regular writes from Safari, so I tried an experiment: I copied Minefield, edited it’s CFBundleIdentifier to be something non-sensical (in this case org.hello.world) and tried downloading a file. The attribute wasn’t set.

So Apple’s doing bundle ID sniffing. Awesome. For the sake of completeness, I tried something else. I tried the same trick on Safari (this time used org.cooldude.CoolBrowse). I was further surprised to find that again all writes from CoolBrowse have the attribute set.

Really, I’m not sure what is going on here.

It looks like the xattr is actually set somewhere in the kernel (perhaps in seatbelt.kext?) I’m still curious as to how Safari’s getting special treatment here, and if other apps need (or want) to opt in.

I’m definitely not done figuring out what’s going on here, but I figured I’d put what I know so far up. Big thanks to Mike Ash and Alexander Strange for helping out.

Edit: Well I’ll be damned. Check out LSQuarantine.h. It speaks volumes about either me or Apple (or both!) that I didn’t even think to check for anything public.

Pretty cool, but there’s just one problem: there’s no way to detect that if the user isn’t using WebKit. Zac West used this table of WebKit version numbers to determine what OS a given user was running, based on which version of Safari shipped with that release.

That works well for browsers that come bundled with your system, but what about a third party browser? Gee, it’d be cool if there was a way to find out information about the browser being used to view your website.

Fortunately, the browser’s [User Agent string] (often just called its “UA”) is exactly the place for this sort of information to go, and indeed, that’s where those WebKit version numbers come from. Unfortunately, Firefox’s UA does not currently include which version of Mac OS X the was running on, despite Firefox’s Windows UA offering the ability to detect major releases of Windows.¹

So eventually, after ranting about this several times on IRC, Dave Townsend mentioned that he’d be willing to write the patch if I shut up and filed the bug ;) So I did. He checked in his patch this morning, and it should be available in tomorrow’s nightly. On Intel Macs, our UA now looks something like:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9a9pre) Gecko/2007102604 Minefield/3.0a9pre

On a PowerPC machine running an equivalent build, we’d a little bit more crufty.²

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O 10.4; en-US; rv:1.9a9pre) Gecko/2007102604 Minefield/3.0a9pre

Including this information in our UA is something I’ve heard requested a number of times, and I’m glad it’s finally in.

The Bugzilla bug above is quite long and very technical, so I’ll lay out what it means a few different groups of people (feel free to skip section that don’t apply to you):

End Users

There are immediate visual changes as a result of this patch. The default titlebar appearance now defaults to the same style as iTunes or Leopard, which is a much darker gray than normal Tiger windows. It doesn’t look so hot with Pinstripe, unfortunately, but you’ll have to bear with me.

Fortunately, good news is on the horizon. When bug 397723 lands, Firefox users will, for the first time in a while, have an interface that looks more or less at home on the Mac platform. Even better news is that it’s (as far as I know) going to happen for beta 1, so you’ll only have to wait a couple of days.

Thee changes will be a huge win for visual integration on Mac OS X, especially on Leopard. I definitely think it was worth doing.

Theme Authors

If you’re writing a Firefox theme on the Mac, you can now set the titlebar color of a window to be a flat, uniform color. There’s a new attribute for top level XUL elements, titlebarcolor. It only works on Mac, but shouldn’t cause too many problems.

Here’s an XBL trick you can use (courtesy of Boris Zbarsky) to apply this attribute to an existing top level element:

<binding id="unified">
    <content titlebarcolor="orange">
        <children/>
    </content>
</binding>

Then in your css you set the -moz-bidnding rule as usual, e.g.

window {
    -moz-binding: url(chrome://some/chrome/url/here/unified.xml#unified)
}

Mac Developers

For the curious, the technique I’m using here is a bit more advanced than the usual “set the background color of a metal window” trick that made the rounds on blogs in 2005 or so. Here’s a summary:

• First, we create a custom NSColor subclass that knows about our window, a titlebar color, and a background color, and override set.
• From the set method, we create a CGPattern with a tile size as tall as the window and one pixel wide (YMMV), and set it as the pattern fill.
• In the pattern’s draw callback, we draw our titlebar color in the upper 22 pixels of the tile and the background color everywhere else. This allows us to do neat things like have a transparent content area with our custom titlebar, which is needed for Gecko platform parity.
• In the case where we don’t want our own custom titlebar, but want the default appearance, there’s code that draws a Leopard-style titlebar, (since you can’t change the window mask of a window after it’s ben created).

You can check the code out here. It’s available under the terms of the MPL/LGPL/GPL, whichever you choose — contact me directly if you need help understanding the licenses.

The Future?

If all of this seems a little bit extreme and evil, don’t worry too much! Asaf Romano and I are scheming about implementing the titlebar completely in XUL, so themes could then style it however they wanted. It’s a much cleaner way to implement this than having a huge widget-leve API.

To do it though, we need bug 307204 to land. If anyone can give Håkan a hand getting his patch to work, many people would be very thankful :)