08.20.08
Posted in Camino at 4:54 pm by Smokey
It’s been a busy couple of weeks for me, so once again I’ve fallen behind on weekly updates; here’s a quick catch-up on the first half of August.
- First up, we released Camino 1.6.3 on August 7. Due to scheduling (European summer vacations!), I ended up building the multilingual version of Camino 1.6.3 myself, so if there are any problems or the disk image looks out-of-the-ordinary, it’s my fault.
Mark Mentovai again handled our build and staging processes, Stuart Morgan readied the software update bits, and I handled website changes.
- Stuart again attacked the review queue, putting the anti-phishing patch through its paces as well as tackling a couple of smaller reviews. He also produced a patch to support the new certificate exceptions model in Gecko 1.9, which is the last major item blocking Camino 2.0 Alpha 1.
- Sean Murphy continued his work on fixing the main window key loop, focusing on a patch to add the tab bar to the key loop patch, and slipped in a small review as well.
- Chris Lawson spent time working on several bugs relating to “cleaning” pastes of undesirable characters. He also made a pass through our list of unconfirmed bugs.
- Christopher Henderson put together a version of his patch for content zoom that contained all of our changes, and he was also pressed into service reviewing some of Chris Lawson’s aforementioned patches.
- Peter Jaros dug into an toolbar script-related bug that I had filed recently, developed a hypothesis, and suggested a course of action that might resolve the bug.
- In addition to my work on releases and the usual triage, I (belatedly) organized the discussion on the content zoom UI and spent a good chunk of time doing a review of the UI in Stuart’s certificate exception patch.
Next up for us: Camino 1.6.4 and polishing off the last patches blocking Camino 2.0 Alpha 1.
Permalink
08.04.08
Posted in Camino at 2:36 am by Smokey
While it’s not quite as exciting as surviving manifold assaults on resort living that have been the main feature of late on Planet Mozilla (nor, for that matter, as exciting as the Norwegian version of a “sea-to-sky highway”), a round-up of Camino events in July is due. Though July was filled with travel, moving, new jobs, summer school, and other impositions of real life, the Camino team still managed to make progress during the month.
- Samuel Sidler and Mark Mentovai led us out of the long, dark months of no nightly builds and flaky G4 Mac mini build machines; they got our Xserve up and running again following the required brain transplant from Mozilla IT. Sam also exorcised some gremlins that had taken up residence in our web servers and had prevented a couple of auxiliary sites from working properly.
- Stuart Morgan recently made a couple of attacks on our growing review queue, knocking out several reviews or superreviews of upcoming features and smaller bug-fixes. He also landed the latest Sparkle beta and reworked our Sparkle integration to match; we’ll move to the final Sparkle 1.5 once it’s available.
- Sean Murphy spent time wrangling Cocoa and Gecko to generate a patch that finally hooks up a complete, correct keyboard loop throughout the main browser window (for the moment it only works tabbing forward, but that’s a huge improvement over the random state the loop is usually in today). He has also continued working on bugs related to the forthcoming anti-phishing feature.
- Bryan Atwood’s patch for the Flashblock whitelist underwent the latest round of review this weekend; it’s very close to being ready.
- While I was away, Christopher Henderson showed up with a patch to implement Gecko 1.9’s new full-page (or content) zoom in Camino, and it’s pretty slick. The patch went through superreview this weekend, and after a few small changes (and a few final design decisions by the team), it’ll be ready to land very soon. Thanks, Christopher, for working on this!
- Since returning from Europe, I’ve gone right back to the usual miscellany—bug triage (kept well under control by the rest of the gang in my absence), patch landings, and stability and security updates (we were able to spring mento from captivity for a bit this weekend, so there’s now a 1.6.3 release candidate ready for testing).
That just about covers July’s main events; I hope I didn’t forget anything—if I did, Sam will no doubt let me know! Hopefully as the summer winds to a close (some schoolchildren near here head back to school in the morning!) we’ll be able to provide changes on a more regular basis and get Camino 2.0 Alpha 1 into your hands soon!
Permalink
07.30.08
Posted in Camino at 3:04 pm by Smokey
Back around the mid-point of this decade, CamiTools was a popular, if poorly-designed and dangerous, third-party preference pane for Camino. In particular, CamiTools exposed a number of hidden preferences that caused Camino or parts of Gecko to stop working properly, and its user-agent spoofing was implemented in such a way that the spoofed user-agent—often some version of Internet Explorer, which caused websites to send incompatible code to Camino—persisted for years without the user realizing it. The “preference tweaks” caused Camino to stop working correctly in bizarre and difficult-to-discover ways, and CamiTools caused the Camino triage and QA teams no end of headaches. Nevertheless, CamiTools was the first widely popular third-party preference pane, and it was even one of the three featured add-ons that “you shouldn’t be without” at PimpMyCamino, if I remember correctly.
I’m not sure at what point CamiTools first became incompatible with Camino; the last reference to it I can find states “Camino 1.0.x only,” which means it hadn’t been compatible with nightly builds since early 2006, hadn’t been compatible with milestone (alpha/beta) builds since late 2006, and with official releases since mid-2007. Jump forward another year-and-change from that and one would hope that CamiTools, which hasn’t been updated in three years and hasn’t been publicly available in nearly two, would no longer be causing Camino users and developers problems. Alas, one would be sadly mistaken. In the last few months I’ve seen one ancient user-agent set by CamiTools, we still encounter users in Bugzilla with it installed, and last night while checking Talkback topcrash reports, I found almost 20% of the incidents I examined (which made up about a quarter of the total incidents for this one stack signature) were a “crash on launch” or “crash when opening preferences” caused by CamiTools. I shudder to think of how many more there might be. If that weren’t bad enough, CamiTools had a sister program, CamiScript (also discontinued and presumed incompatible with anything newer than Camino 1.0.x), that also caused a rash of crashes on launch with Camino 1.6.1.
It seems like just about every Camino release we discover—the hard and painful way, via angry users complaining about us in forums and on software update sites—some new Camino crash caused by an old or incompatible third-party add-on trying to initialize itself inside of Camino’s process. These are the worst kind of crashes; users believe that programs which crash at startup are pretty badly broken, and they shout that experience out to the world while rarely contacting or working with the developers to discover the true source of the crash. In Camino’s case, these crashes (or public reports of them) not only dissuade new users from trying the program, but the crashes/reports also cause users to stick with the last version of Camino that “worked properly” (i.e., the last version of Camino that an incompatible third-party tool did not reliably crash), causing users to miss vital bug-fixes and critical Gecko security fixes that we release in updates and in new major versions. It’s frustrating as a development team to be fighting problems caused by code that is completely out of our control but which nevertheless crashes our application.
Please, if you still have CamiTools, any of its predecessors, or CamiScript installed, remove them at once. They really are incompatible with any recent version of Camino, and if they haven’t yet caused you problems, they will soon.
Second, if you crash when Camino is launching, check for any third-party add-ons and remove them. You can try launching Camino using Troubleshoot Camino, which will disable many recent third-party add-ons (though many older add-ons which are known sources of crashes or incompatibility cannot be disabled using Troubleshoot Camino), but searching for, and removing, all traces of third-party add-ons may be necessary, depending on the add-ons you might have installed.
Third, if you’re experiencing any sort of persistent problem with Camino, please visit the Camino forum provided by our friends at MozillaZine, or file a bug, and work with us. We can’t diagnose problems we don’t know about, or don’t have information about, so we can’t help make it stop (no matter whose code might be at fault).
Finally, let me repeat myself once again: CamiTools and CamiScript are incompatible with all recent versions of Camino. If you still have them installed, please remove them immediately. If you don’t think you have them installed, please check carefully and make sure they are not installed. (While you’re looking, please make sure any other Camino add-ons you have installed are up-to-date and not discontinued.) You’ll save yourself, and the Camino team, a lot of time and hassle, either now or sometime in the future.
Permalink
07.20.08
Posted in Life, Software at 8:11 pm by Smokey
Unsurprisingly, a new version of WordPress appeared while I was away in Europe. Once returning, one of the first things on my agenda was upgrading from WordPress 2.5.1 to the new version 2.6. This was going to be my first upgrade using SimpleScripts (a replacement for the once-vaunted Fantastico), and an upgrade to an entirely new version, not simply a small security release, at that, so I was interested to see how the process would play out.
First off, I read the WordPress release announcement and learned that there were very few changes that would adversely affect plugins and themes (the latter very good news, since I’m using a somewhat-customized version of the Ocadia theme and the theme’s author, Becca Wei, seems to have vanished shortly after I installed her theme way back with WordPress 2.0 
). Database backups in hand, I then popped over to my host’s cPanel and opened SimpleScripts; the WordPress 2.6 upgrade was waiting for me. Since I was abroad, I’m not sure when the new version appeared in SimpleScripts, but by my count it’s been five days (two of them a weekend) since the WordPress release announcement, and that beats the best performance I ever saw with Fantastico. I switched back to my WordPress admin page, disabled plugins, and then started the upgrade process. About a minute later, I was running WordPress 2.6. 
So far everything seems to be working fine, the only “side-effect” being a spam comment that snuck in while Akismet was disabled for the upgrade. That’s more bad luck than the fault of SimpleScripts.
The verdict: SimpleScripts does indeed seem to make upgrades simple!
Permalink
06.24.08
Posted in Camino at 12:05 am by Smokey
Just a brief report on some of last week’s progress:
- Sean Murphy posted an updated version of his anti-phishing patch, as well as a patch that adds the ability for Camino to perform useful action when a user clicks on a XUL button in the content area (buttons which have been proliferating with the move to introduce new error pages for every error type).
- Chris Lawson worked on a few Preferences window-related bugs again last week.
- Over the weekend Samuel Sidler switched one of our G4 minis over to build the
MOZILLA_1_8_BRANCH (as we continue to await the return of our Xserve, which went AWOL in late May), so we once again have nightly builds of what will become Camino 1.6.2 in the near future.
- Towards the end of last week, I gave Ted Mielczarek a few ideas about how to address bug 406088 (make the Mozilla Crash Reporter work better for right-to-left languages) on Mac OS X. I also began preparations for the Camino 1.6.2 release, including compiling the release notes and putting them up for review. Over the weekend I also created a patch that causes Camino to use some
.css files from toolkit/themes/pinstripe/ instead of from the old mozilla/themes, which will lead to better appearance of the aforementioned XUL buttons, among other things.
That’s all for week 25. If I have the time, there might be another summary next weekend; otherwise, this feature will resume after my return from Europe.
Permalink
06.16.08
Posted in Camino, Uncategorized at 10:57 pm by Smokey
I mentioned previously that WWDC and the Camino Meet-Up would probably lead to less Camino work last week, but that wasn’t exactly the case; there was still enough interesting activity for me to write up a brief weekly summary.
- Mike Pinkerton, Stuart Morgan, Nick Kreeger, Jeff Dlouhy, and Peter Jaros all attended WWDC and presumably learned lots of valuable information under NDA. Our fearless leader also pulled a tree on whatever laptop he had with him for the conference, so it’s possible he’s up to something.
- About two-thirds of our active development team made it to California for Saturday’s second-annual meet-up. In addition, Desmond Elliott was patched in from across the pond via voice and video chat, and I joined the video chat during the afternoon. Samuel Sidler will write more about the meet-up, and post a summary to the wiki, in the coming days. There were many fruitful discussions, but, as I understand, the real highlight for Jeff was finding out that I was not, in fact, a figment of everyone’s imagination or some form of artificial intelligence.
- Chris Lawson worked on various bugs over the course of the week, including a patch to remove more Windows ampersand shortcut marks from Core strings that are passed to our alerts. He also worked on fixing a few bugs in our HTML bookmarks importer until Stuart decided to take the old importer out behind the woodshed and put it out of its misery.
- Stuart started fixing some of the lingering problems preventing our chrome from being completely compatible with Apple’s accessibility API, moved most of our menu code over to a newer API, and started working on a replacement for the aforementioned HTML bookmarks importer.
- When he wasn’t on the job or representing Camino at WWDC parties, Sam continued bringing up our replacement tinderboxen (with help from Mark Mentovai on a pesky Ts timeout); we now have two G4 minis cranking out builds while we await the return of our Xserve.
- My contributions for the week were some assistance with the tinderbox configs, a handful of checkins, and finishing the May ad-blocking bug, as well as a bit of the usual triage.
In spite of all the conferring taking place, we weren’t standing completely still on the code front last week. Hopefully this week will see an end to our tinderbox woes and development on Camino 2.0 Alpha 1 can resume in earnest!
Permalink
06.15.08
Posted in Camino, Life, Software at 4:28 pm by Smokey
Ever since I upgraded to Mac OS X 10.5, I’ve been unable to share my 10.5 Mac’s files with any of the other Macs on my local network. This is despite the firewall claiming that AFP is an “allowed service” and happens regardless of whether the firewall is on or off. (My “solution”: continue sharing the disk in my 10.3 Mac, where enabling file sharing Just Works™, and mount that shared volume on the 10.5 Mac.)
By contrast, I joined the second annual Camino Meet-Up remotely yesterday afternoon, and though I’d never used iChat before, all I had to do was open the app and tell Sam my old mac.com username. Poof, there were pink and the gang in San Francisco and Desmond across the pond, all staring back at me and chatting away. No messing with the firewall required.
It’s obvious which task Apple believes is common and therefore optimized. I have no arguments with making video chat completely seamless, either; it’s just that file sharing used to be the same way, from early Mac OS versions all the way up until the arrival of 10.5—why did Apple have to break that?
Permalink
06.10.08
Posted in Camino at 1:38 am by Smokey
Some of you may have noticed it’s been some time since I’ve posted a weekly update on Camino—just over two months, in fact, although there have been a few Camino news posts in the interim. It’s been a busy couple of months for me, so the updates haven’t been on the top of the stack for a while. For the moment, here’s a brief update on what we’ve been doing.
- We released Camino 1.6 and 1.6.1, in 13 languages (though we’re still missing British English and Slovak from the 15 that were in 1.5.x). Samuel Sidler and I updated the website for all the changes and new features in Camino 1.6.
- Sean Murphy fixed a number of issues with our OpenSearch implementation for 1.6.1. When not working on those bugs, he has been hard at work at our phishing and malware prevention implementation; he attached a complete patch last week.
- Chris Lawson jumped back into our preference pane documentation and updated both the text and sample code. He also helped restore our support for a much-used but deprecated AppleEvent in 1.6.1 and has been working on some preferences window and location bar bugs.
- Bryan Atwood recently posted an updated patch for implementing the Flashblock whitelist; it’s currently awaiting review.
- Desmond Elliott (of scrollable tabs fame) has started looking into getting OCUnit set up and some tests written so that we can start unit-testing our own code.
- Stuart Morgan tag-teamed with Sean on the OpenSearch bugs, supplied a few other fixes for 1.6.1, and has been driving the Camino 2.0 Alpha 1 bug list. He landed a few Tabsposé fixes and is currently working on upgrading our version of Sparkle and rewriting our security UI to adapt to trunk changes. Stuart also continued providing milk and cookies to the update system on release days.
- As always, Mark Mentovai has been our fearless build-wrangler, build-stager, tinderbox guru, and the final word on the text of our release notes.
- Sam has been wearing his IT hat recently, coaxing better performance from our webserver and helping track down problems with our tinderboxen. With some help from Mark, Sam restored trunk nightlies by coaxing our 1.24 GHz G4 Mac mini into building. Whenever Sam is done with his IT hat, Philippe Wittenbergh has a few improvements to the website content and style waiting for him to review. In his free time, Sam has also been organizing our second annual contributor meet-up this weekend.
- When I’ve had blocks of time for Camino that haven’t involved releasing new versions, I’ve been fixing a number our various website content bugs. I’ve worked on a few miscellaneous bugs as well.
Whew! That’s a quick summary of the past two months of Camino development.
Most of the team is in California this week, either for WWDC, our second-annual meet-up, or both, so between that and our run-away tinderboxen, it’s unlikely to be a busy week, code-wise.
I hope to get back to updating on a more frequent basis, but regular weekly updates are unlikely to resume until I return from Europe in August, at the earliest.
Permalink
06.08.08
Posted in Life, Software, Uncategorized at 1:03 am by Smokey
Some time ago, Gravatar announced the first round of “improvements” added to the service after having been bought by Automattic (the company behind WordPress, the software that powers افكار و احلام). Among those changes was a buried, but rather unpopular, one: Gravatar had dropped support for images in PNG format and, with that, transparency. Worse, the new Gravatar service had converted all existing PNG images into JPEG images, turning any transparent sections into pure black!
Automattic’s initial responses to the first questions about the deleted PNG support were a bit brain-dead, as others pointed out. I was flabbergasted at how clueless Automattic seemed, and I started working on my own post about the subject. Fortunately, I quickly got distracted with the run-up to Camino 1.6, and the mostly-finished post sat around, awaiting some polish and a conclusion. In the meantime, I also discovered that Automattic had attempted to unify Gravatar and WordPress.com, replacing email-based Gravatar logins with WordPress.com username-based logins. Initially, however, there seemed to be no way to prove you owned a WordPress.com username after Gravatar reported the username was in use.
Since I was busy with Camino releases, I just let my Gravatar complaints sit, the critical post still unfinished, hoping that at some point “soon” Automattic would come back from 1995 and rejoin the PNG era. In addition, I’m not overjoyed at writing involved criticisms of people whose work I’m otherwise fond of, so if I never needed to finish the post, I would be just as happy. Finally, today I happily discovered that Gravatar had indeed come back from 1995 and had restored support for PNGs and transparency. Even better, when I attempted to log in, I could supply my WordPress.com password to prove I owned the username I wanted to use. After that, it was just a quick upload, and my old gravatar plagued with a black line was back to a nice transparent PNG. Nice work, Automattic!
Now, if I could just figure out a good way to add gravatars to this theme, everything would be perfect.
Permalink
06.07.08
Posted in Camino, Software at 5:05 pm by Smokey
It’s pretty rare that I write about a technical topic (or even a mostly-technical topic), since I’m not really what most people would consider a “developer.” When I have written about such things in the past, it has generally been surrounding our feed handler applications, and this time is no different.
Because the feed handlers function as faceless background applications (they simply receive an open location/GURL event, do a tiny bit of processing, then send Camino a open location/GURL with the URL of a web-based feed reader and a feed, and quit), users have the best experience when they don’t even really know the handlers exist. That is, users don’t see the feed handlers launching, and the apps don’t steal focus from what the users may be doing when the apps launch.
Often Mac developers use the LSUIElement key with a value of 1 in their application’s Info.plist to make their application “hidden”—it won’t appear in the Dock or the application switcher—but this doesn’t make an application a real background-only application; if the application has windows, those will still appear (for example, the Mac OS X crash reporter behaves like this), and applications like this can still steal focus. If you have an application that periodically launches and “does stuff,” like Camino’s feed handlers, there are lots of chances for unfortunate focus-stealing.
The solution to this is an alternate property list key, LSBackgroundOnly, for “faceless background applications.” Set this to key to 1 and all is well, right? In most cases, yes; all is well. However, if your application is an AppleScript, as Camino’s feed handlers are, you’ve just set yourself up for a world of random hurt. AppleScript has this old feature where applications configured not to show a “startup screen” (as faceless background applications would be) can still be forced to show the startup screen on launch (if your application does not have a custom startup screen because you never intended for it to show a startup screen, you get a startup screen like this gem 
).
This override-the-decision-not-to-show-a-startup-screen is triggered by whether or not the Ctrl key is pressed when the application launches. In an LSBackgroundOnly application, any UI displayed by the application is stuck in this limbo z-layer, where it is sort-of visible if you move other applications out of the way, but never focusable (on 10.3.9, the startup screen isn’t even visible at all!). As a result, if your LSBackgroundOnly AppleScript application launches when the user is pressing the Ctrl key (in any application: Camino, Finder, Terminal, etc.), the startup screen appears and can’t be dismissed, preventing your application from running or quitting. Yikes! The only way to terminate a stuck LSBackgroundOnly AppleScript application is to use a terminal command or Activity Monitor; neither is very user-friendly, and both assume that your users can figure out what’s happened in the first place.
As a result of this old AppleScript (pointless—why would you ever want to show a startup screen in an application you’d explicitly saved to not have one?) behavior, the user-friendly, impossible-to-notice faceless background-only application becomes a very visible, very unfriendly application staring your users in the face, taunting them because it can’t easily be closed—and, to top it all off, your application isn’t really running, so it can’t even perform whatever function it’s been designed to perform. Unless you can be perfectly sure that your users will never be pressing the Ctrl key when your application might launch, you will find that AppleScript is unsuitable for creating faceless background applications.
Ultimately, someone else will probably rewrite Camino’s feed handlers as tiny Cocoa apps, but for any Apple types out there, I did log this behavior as rdar://5962612 and suggest that LSBackgroundOnly AppleScript applications ignore the Ctrl-to-force-startup-screen behavior (though based on other, less painful, problems this causes, I don’t think many would cry if the Ctrl behavior were sent the way of Mac OS 9).
Permalink
« Previous entries
