01.28.08

Camino 2008 Week 4

Posted in Camino at 1:27 am by

All those weeks of “two-dozen-plus bugs fixed” are finally catching up with us; this week we’ve slowed down a bit and have taken some time to restore our collective sanity. ;)

  • The big news of the week was the landing of Bryan Atwood’s patch for saving (and using) multiple sets of account information for a single website. In addition to his last-minute work to get that patch ready for landing, Bryan fixed four follow-up bugs related to the multiple accounts support last week, and he also found some time to update his patch for a Flashblock whitelist (“Exceptions List” in Camino parlance) now that we’ve put the Web Features preference pane on a diet.
  • Mark Mentovai landed a fix this week for the dreaded “symbol-stripping” bug that was rendering crash logs useless, and he switched the PPC builds on the MOZILLA_1_8_BRANCH to use GCC 4 as the compiler (as a side effect, ✈ will now require Mac OS X 10.3.9 or higher). Mark also did some more work on fixing keyboard focus defaults in alerts, improving the localized display of dates, and making our build system friendlier.
  • Stuart Morgan took on some clean-up work in addition to his usual complement of reviews. He also wrote a patch to make incremental search in the new Find bar function more like a sane person would expect. ;)
  • Jeff Dlouhy posted a more functional version of his patch to integrate Quick Look into the Downloads window. Unfortunately the patch currently only works in shared builds, so the feature is a long-shot for making Camino 1.6.
  • I kept busy with non-Camino things this week, but I did continue to do reviews on some of Mark’s build-related patches, worked on a few website bugs, and patched about:license to be ready for the third-party code Jeff’s tab drag-and-drop patch includes.

That’s about it for this week. The next security release for Camino 1.5.x beckons, so some of us (at least me) will be focused on that instead of ✈ for all or part of next week—and those efforts won’t be nearly as exciting to many of you as the new features that we’ve been turning out lately. ;)

01.23.08

Camino 1.6b3pre now requires Mac OS X 10.3.9

Posted in Camino at 3:21 pm by

Mark Mentovai just checked in changes to make branch nightlies (Camino 1.6b3pre builds) require Mac OS X 10.3.9. Camino 1.6b3 and Camino 1.6 will obviously also require Mac OS X 10.3.9 as a minimum. (If you’re still using a version of Mac OS X 10.3 other than 10.3.9, I urge you to download and apply the Mac OS X 10.3.9 Combo Update from Apple, as well as subsequent security updates.)

For those of you who build Camino branch, you will need to make distclean in your tree before building the next time you update (PPC-only builds), or make distclean and update your .mozconfig before building (Universal builds).

A sample Universal .mozconfig for Camino 1.6b3pre/MOZILLA_1_8_BRANCH now looks like this:

. $topsrcdir/build/macosx/universal/mozconfig
. $topsrcdir/camino/config/mozconfig
ac_add_app_options ppc --with-macos-sdk=/Developer/SDKs/MacOSX10.3.9.sdk
ac_add_app_options ppc --enable-macos-target=10.3
ac_add_options --disable-shared
ac_add_options --enable-static
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../CaminoBranchUni

Note that the default Camino mozconfig is now sourced after the default Universal mozconfig in order to allow the new Camino defaults to override the PPC defaults from the Universal mozconfig.

Multiple accounts, multiple accounts, get your multiple accounts right here!

Posted in Camino at 12:37 am by

Just a quick update on yesterday’s report…

Apparently the third time really is the charm, as today I successfully landed1 Bryan Atwood’s patch to allow Camino to save (and use) multiple sets of account information for a single website.

In the works for over 10 months, we’re excited to finally have this feature in the ✈ nightlies (what will become Camino 1.6 Beta 3 and, of course, Camino 1.6 itself). Huge thanks to Bryan for working on this, bearing with the Camino 1.5 Keychain rewrite, our aversion to adding more uses of the the old Core autocomplete interfaces, and the many extended reviews2 on his sizable patch (thanks also to Stuart and Mark for providing said reviews)!

Best of all, if you have multiple accounts already saved in the Keychain by Safari in addition to one saved by Camino, you’re now able to access all of the accounts in Camino.

As with many large feature landings, everything may not quite be perfect and polished right now, but the feature is very stable and fully functional. We have a number of follow-up bugs filed already, but if you find other issues, please file bugs and we’ll do our best to fix them before Camino 1.6 ships.

Enjoy (and be sure to thank Bryan next time you run into him ;) )!

        

1 Mark Mentovai added one final quick bustage fix on the branch. ↩

2 There were no fewer than 19 patches and 125 comments in the bug when all was said and done. ↩

01.22.08

Camino 2008 Week 3

Posted in Camino at 2:31 am by

Week 3 was another big week for us…but maybe “hectic” is a better word for it.

  • First off, we released Camino 1.6 Beta 1 and Camino 1.6 Beta 2 this week (well, sort-of).
    • We “soft-released” Beta 1 on Thursday afternoon (EST) to software update and planned to publicly announce the release on Tuesday. Late Friday afternoon we were able to connect the dots about some common crashes people had started reporting on Wednesday. Since we knew at that point a fix was available, we decided to ship Camino 1.6 Beta 2 ASAP with the fix for the crash in order to prevent another crashy beta. Thanks to all the team for the hard work that made this possible (more on that below)!
    • Beta 2 will be officially and publicly announced soon, but if you’re using Alpha 1 or a recent branch nightly, please use the “Check for Updates…” option in the Camino menu to let software update do work its magic. We’ve done some testing and it works (with a few pain points) in our personal set-ups, but the more testing we get, the better. Please let us know if you experience any problems.
  • Mark Mentovai served as our fearless and tireless build and release engineer, as always. In addition, he spent some time working on early issues we’ve spotted in the software update process. He also devised a solution that will solve the problem where symbols are being stripped erroneously, which currently makes it extremely difficult for us to read crash logs; Stuart and I reviewed that patch and hopefully it will land soon.
  • Stuart Morgan spent more time this week working on our preference panes, polishing the Web Features and Tabs panes. He also worked on cleaning up code related to the History menu and the site icon cache.
  • Sean Murphy continued to work on follow-ups to the new OpenSearch support this week.
  • Peter Jaros wrote patches for a couple of follow-up bugs from this summer’s AppleScript enhancements.
  • Bryan Atwood made it through the super-review process with the patch to allow Camino to store (and access) credentials for multiple accounts on the same site, but some last-minute issues are keeping the patch out of the tree for now.
  • Jeff Dlouhy continued working on tab drag-and-drop and posted a new WIP patch on Friday.
  • I spent time doing reviews, checking in patches, and fixing bugs on the website again this week. I also took on the task of backing out, checking in, and watching the tinderbox for test results as we worked on an odd startup time regression related to changing the capitalization of “for” in the “Check for Updates…” menu item. Ultimately, we’ve decided that Interface Builder 2.5.6 (which ships with Xcode 2.5 on Mac OS X 10.4 and 10.5) creates .nib files that can be slower to load. (If the multiple-versions-support in Apple’s developer tools weren’t annoying enough already, this bug just compounded the problems.) In between, I also found time to update my patch for web-based feed readers, which is now up for super-review, and to create a new Universal version of the CaminoViewsPalette framework for our localizers.

Camino 1.6 Beta 2 by the (wall-clock) numbers

In the tradition of other “by the numbers” posts, here is a brief run-down of the time it took to release Camino 1.6 Beta 2 to software update. All times US Eastern Standard Time (EST).

18 Jan, 3:08 PM: Stuart mentions he’s gotten “two reports now of people with persistent gmail crashes,” which adds to the scattered noise about random branch crashes we’ve been hearing since late Wednesday.
18 Jan, 4:20 PM: Sam goes to set up Talkback reports for Camino 1.6 Beta 1 (which we had released to software update on Thursday afternoon), and I start comparing crash the logs that we have.
18 Jan, 4:35 PM: Sam announces this Gmail/random crash is already the “topcrash” for 1.6 Beta 1, and he informs us of the Core bug that covers the crash.1
18 Jan, 4:39 PM: After verifying that the Core bug in question was the one causing the crashes we had crash logs for, we begin debating the course of action to take.2
18 Jan, 4:48 PM: We decide to release and begin debating what to call the new release.
18 Jan, 4:52 PM: We’re calling the release Camino 1.6 Beta 2, and I start updating the Beta 1 release notes.
18 Jan, 5:02 PM: Mark super-reviews the release notes and notes that it’s 5 PM on Friday.3
18 Jan, 5:05 PM: I check in the release notes while Mark changes the version numbers on the existing Camino 1.6 Beta 1 mini-branch and lands the Core patch on the mini-branch.
18 Jan, 5:20 PM: I file a bug on renaming the 1.6b2 flags in Bugzilla to 1.6b3 flags and a bug on updating the appcast and the website for the coming release.
18 Jan, 5:27 PM: Our release tinderbox cb-xserve01 begins building Camino 1.6 Beta 2.4
18 Jan, 6:12 PM: cb-xserve01 announces that the build is complete and has passed basic tests (42 minutes elapsed).
18 Jan, 6:14 PM: The 1.6b2 build is staged on ftp.mozilla.org.
18 Jan, 6:15 PM: Mark files the bug to get the release into Bouncer, mozilla.org’s release mirror management system.
18 Jan, 6:21 PM: We have verification the Gmail, Blogger, etc., crashes have ceased in the 1.6b2 build.
18 Jan, 6:33 PM: Mark leaves work and goes home for the weekend.
18 Jan, 6:37 PM: I have the appcast and all the website changes made locally.
18 Jan, 6:45 PM: Mozilla Corp build engineer Nick Thomas informs us the release is in Bouncer; we now have to wait for the changes to propagate to the mirrors.
18 Jan, 7:21 PM: Nick Thomas informs us that Bouncer is ready for our release.
18 Jan, 7:23 PM: I push the website and appcast changes to the live site.
18 Jan, 7:24 PM: Sam downloads 1.6 Beta 2 via software update!

Total time elapsed from the time we decided to release a new version to fix the Core crash until Sam downloads the release via software update: 3 hours 36 minutes.

Special thanks to Mozilla’s Nick Thomas for expediting the Bouncer work for us on a Friday before a long weekend (preventing hundreds, if not thousands, of crashes that would have happened in Beta 1 just this weekend) and to our own Mark Mentovai, who stayed at work for an extra hour and a half on Friday evening5 to get the build-and-release part of the 1.6 Beta 2 release done.

        

1 Ironically, the bug had been filed nearly three years ago by a Camino user, but it had been rare until another Core change on Tuesday caused the crash to become fairly common on certain websites. ↩

2 Since the patch to fix the crash had been appropriately reviewed and had landed on the MOZILLA_1_8_BRANCH that morning and since we had not officially announced Camino 1.6 Beta 1 (only “soft-released” it to software update), we had the option to pick up the fix for the Core bug and do a quick (re-)release to avoid a crashy beta. ↩

3 About half of the Camino team is based on the US East Coast (with the other half split between the US Midwest, California, and Europe), and those with real jobs at open-source-friendly companies usually stick around IRC and do checkins and release work only during business hours. ↩

4 The period between the checkins and the start of the build is filled by tagging the source code and configuring the tinderbox to make an official release. ↩

5 See footnote 3 above. ↩

01.14.08

Camino 2008 Week 2

Posted in Camino at 4:37 am by

2008 continues to roll forward at a brisk pace. In the span between last week’s meeting and this week’s, we fixed a total of 32 bugs (mostly for ✈, but some trunk-only and website bugs), and so far we’ve fixed 19 bugs this week, including two of the major new features left. I personally had lots of fun dealing with merge conflicts and landing big patches. ;)

  • Sean Murphy finished up work this week on two of our remaining new features, a simple editor for search engines and support for the OpenSearch engine format. In the process of fixing some follow-up bugs, he also found and fixed a 10.5-compatibility bug in our table view code. Practically speaking, all of this search work means in current nightlies and in the upcoming Camino 1.6b1, you’ll be able to:
    • Add search engines by clicking links on web pages that offer to install OpenSearch-based engines for you (for example, some of the collection of engine plug-ins from the Mycroft Project), thanks to some XPCOM wrangling by Stuart Morgan.

    I’m looking forward to saying good-bye to this technical documentation that explains the intricate steps one has to perform to add a search engine in Camino 1.5.x and older.

  • In addition to his part of the search engine enhancements, Stuart also fixed a series of annoying bugs related to printing and saving as PDF that caused Camino to suggest “Untitled.pdf” or “.pdf” or even “.pdf.pdf” for filenames instead of the page title. We hope to be able to get approval to include this fix in ✈.
  • Mark Mentovai spent some time this week fixing bugs related to how our bookmarks display their last-visited dates and changed how we display the version in the About window. The new version scheme is both more Mac-like and more detailed, so it’s easier to see version information that used to be hidden away in places like the user-agent string. He did a number of reviews, an extensive super-review of the “multiple accounts in the Keychain” patch, and worked a lot of Makefile magic!
  • Markus Magnuson posted two WIP patches this week, one for showing a pop-up menu in the titlebar showing the current page in the “folder hierarchy” of the website, and another that revives a five year-old patch to allow auto-completion of form fields as you type, based on information in your Address Book (e.g., email addresses, friends’ names, or addresses).
  • I had a lighter load this week (whew!). I landed Sean’s two huge search patches, the branch version of Markus’s patch from last week, and threw together the OpenSearch code for caminobrowser.org. I also bit-rotted everyone’s existing project changes on Sunday when I finished up our campaign to standardize on .tiff instead of .tif as the extension for our image files. After Mark provided me a great magic Makefile and Peter Jaros reviewed my AppleScript code, I sat down to assemble a final patch for supporting web-based feed readers, only to find that a number of changes in Camino and common web-based readers meant my code didn’t work as well as it did when originally written. What a fun way to end the evening and the weekend. :P

I think that pretty well covers everything for Week 2; with all the fixes, it seems like we’re much further into the year than we are. It’s a bit hard for me to accept we’re only just beginning Week 3….

01.07.08

Camino 2008 Week 1

Posted in Camino at 12:40 am by

For those of you tuning in to “Camino $YEAR Week $WEEK” for the very first time, this is a weekly/semi-weekly feature in which I provide a brief (sometimes not-so-brief) recap of what members of the Camino team have been working on over the previous week.

It’s the first week of the new year, and despite holidays and vacations, we got off to a running start; we’ve fixed over 20 bugs since our weekly meeting on Wednesday. Looking over the fixes, the themes of the week seem to be “accessibility” and “preference panes.”

  • Over the holidays Mark Mentovai continued to build up a backlog of patches for us to review, and with Stuart Morgan and I catching up on reviews, Mark’s responsible for most of the week’s bug fixes. He fixed some nagging bugs involving setting up the key loops and first responders in our preference panes (important for Full Keyboard Access users). He also fixed a very old, very vexing bug with the Appearance preference pane—a bug that caused us to have to be very careful when making changes to the pane, and which caused Ian and I no end of trouble over the past couple of years. The other major change Mark landed this week is a way to edit the list of sites for which you’ve prevented the Keychain from saving information; no more quitting and editing a .plist when you make a mistake! He also started working on some bugs covering the Fonts side of the Appearance preference pane this week, along with the usual complement of reviews and super-reviews.
  • Stuart finished reviews of three of the five major new features that could possibly appear in ✈ (Camino 1.6): a search engine editor, support for OpenSearch engines, and Keychain support for multiple accounts at the same site. In addition to reviews for those major features and his share of reviews on Mark’s patches, Stuart also improved sorting in our cookies UI and added the ability to select a cookie exception for a sub-domain and make the exception apply to the entire domain (useful when you start accumulating “Deny” exceptions for ad1.adserver.com, ad3.adserver.com, … ad299.adserver.com). He also made changes to our permissions wrapper code to make it easier for third-parties to develop preference panes for manipulating settings related to cookies, pop-ups, images, scripts, and so forth without having to talk to Gecko themselves.
  • Jeff Dlouhy posted a new WIP patch for tab dragging this week, addressing the review comments Håkan Waara provided last week and cleaning up some more of the dragging code.
  • Sean Murphy (who fixed a number of bugs related to spell-check and the pop-up bar for Camino 1.5) quickly addressed the review comments Stuart left on the search engine editor and OpenSearch patches and readied new versions for super-review.
  • Bryan Atwood (who brought us Flashblock in Camino 1.5) went through two rounds of review with Stuart on the patch to support multiple accounts for a single site with the Keychain, and he provided a patch for super-review as the weekend came to a close. (pinkerton will have a busy week of super-reviews ahead of him! ;) )
  • New developer Markus Magnuson’s third patch was a simple fix to make the cursor disappear when pressing the Page Up or Page Down keys, like all good Mac apps. This patch actually required a trip into the bowels of Gecko, but Markus survived. His patch was reviewed and super-reviewed this week, and I checked the patch in to the trunk yesterday. It’s a very small change, so we’re hoping we can get approval to include it in Camino 1.6 as well.
  • Samuel Sidler’s main project for Camino this week was to develop an updated set of default bookmarks. Our default bookmarks have only been thoroughly updated once since Dave Hyatt’s original February 2002 Chimera set, but that update was in October of 2002! Five-plus years later, the internet (and Camino’s audience) have changed tremendously, and our bookmarks needed to catch up. Sam managed a stream of feedback from our team and put everything together into a final set.
  • For me it was another week of assorted work, as usual. I upgraded our Flashblock code to use the latest version in advance of Camino 1.6 Beta 1 and did a number of reviews and some work on the website. I also spent some time this week following changes to the mozilla.org website and provided Ted Mielczarek a detailed series of comment on the “Revision 2” UI for the Mac version of the Mozilla Crash Reporter.

I doubt we’ll be able to keep up this crazy pace much longer, but the last few weeks have put us in good shape for the upcoming Camino 1.6. I’m starting to be able to see the light at the end of the tunnel (and no, it’s not an oncoming train!), and we hope to have many of these goodies ready for you in Beta 1 in a couple of weeks.

(If you missed last week’s round-up due to the holidays, you can catch the 2007 year-end review here.)

01.01.08

Requiem for a rendering engine

Posted in History, Software at 9:57 pm by

While the rest of the web is marking the ignominious final death of the browser bearing one of the greatest names of the pre-War Internet, I want to lament the death of a very different thing, a remarkable yet unheralded rendering engine.

Today marks the public release of iCab 4.0, which uses WebKit as its rendering engine. The accompanying notice urging anyone using Mac OS X 10.3.9 or higher to use iCab 4 is a pretty good sign that the iCab 3 rendering engine has reached the end of the line.

iCab 3 made its semi-public debut (to registered iCab users) towards the end of December 2004, with a completely rewritten engine that boasted of CSS 2.x support second-to-none and rendered the web as it was intended in 2004. Given the hype surrounding Safari’s support of the CSS text-shadow property in those days, iCab went one better and supported the property more correctly and completely.

Other things I remember about iCab 3.0’s HTML/CSS support were the inline-block property (not available in Gecko until the forthcoming Gecko 1.9) and proper rendering of the <q> element per-language, with no additional work required by the author (which neither Gecko nor WebKit could do) beyond actually specifying the language of the element. And, unlike in WebKit or Gecko, text content inserted via CSS pseudo-selectors (like properly localized quote marks, necessary for correct display in WebKit and Gecko) was selectable and copyable, so none of the content, which was unfortunately shoehorned into presentation to work around other bugs in those rendering engines, would be lost.

To be sure, iCab 3 had its fair share of bugs, some of which persisted right to the end. Nevertheless, the belated appearance of iCab 3’s first semi-public preview (some two years, I think, after its first announcement as iCab 2’s forthcoming successor) turned a lot of heads. Beyond saying ”you can no longer write iCab off as a ‘not a modern browser,’” iCab 3 ran on versions of the Mac OS as old as 8.5 (yes, that’s the “classic” Mac OS; 8.5 was released in October of 1998), promising modern browsing to all PPC Macs (the first of which were released in April 1994!).

The other notable feat accomplished by the iCab 3 rendering engine was to become the second rendering engine, and the first to release a semi-public or public build (available to all registered users on May 20, 2005), to pass the Acid2 test of various web standards in May 2005.

Having laid out these feats of strength, it is time to remind everyone of the most shocking fact about iCab: all of this was done by one person, Alexander Clauss.1

In spite of all the obstacles the modern web threw at browser developers, the fact that one man could single-handedly write an entire rendering engine that “kept up with the Jonses” and ran natively on Mac OS 8.5-Mac OS X 10.5 inclusive is nothing short of miraculous.

iCab the browser UI was never a thing of great beauty, but it was functional and included innovative features, many of which, to my knowledge, still have not been copied.

  • Most renowned for its powerful if clumsy filter manager, iCab was one of the first to provide configurable ad, script, and pop-up blocking.
  • iCab also could detect if a local web page you were working on had changed and would reload it automatically, which shaved hundreds of thousands of keystrokes or clicks off of website development. That, and the built-in HTML checker (behind the famous “smiley”) made iCab an author’s friend.
  • iCab also was a pioneer of an “open,” portable web archive format; unlike Gecko, iCab didn’t rewrite pages, forget to include referenced files, or require collecting files and folders before transfer, and unlike Internet Explorer, an iCab web archive was a .zip file that could be carried to any computer, unzipped, and used effectively.
  • iCab’s download manager was homely and complex, but it was one of the first web browsers to support resumable downloads (by contrast, the forthcoming Firefox 3 will finally support this feature). You could also choose to “download” all or part of a site, either as individual pages or as a web archive.
  • iCab got “don’t load images”/“load images” correctly; it was possible to turn off image loading by default and then load individual images if desired, something modern browsers have forgotten. And iCab’s “offline mode” was actually still functional in the mid-2000s.
  • One of iCab’s more recent innovations was the ability to visually indicate the target of an anchor when arriving via a link (e.g., the footnote link above that points to the footnote anchor below). Proposed in the iCab mailing list by user Daniel Beardsmore, this was implemented in iCab 3 as a light blue bar that fades out over the location of the anchor on the page.

All of this while keeping up with the ever-changing world of rendering web pages.

Amazingly, it seems most of these browser features have been tacked on to the new WebKit-based iCab 4, and perhaps freed of the job of writing a rendering engine, Mr. Clauss can continue to innovate more quickly—if fighting the quirks and bugs of three versions of WebKit doesn’t eat up this time.

In the end, the waves of browser sniffing that plague “Web 2.0” and a slow and somewhat buggy Javascript/DOM implementation (technologies on which “Web 2.0” is built) likely proved too much for iCab’s home-grown rendering engine.

Still, it is a day of sadness for the three-year life2 of one of the most amazing rendering engines the world has ever seen—and for the end of browser development for the classic Mac OS. Let us raise a glass to the passing of one of the last independent rendering engines, to its successes, and to the good years of browsing it gave us. Adieu….

        

1 iCab 3 used the external InScript JavaScript engine, written by Thomas Much. ↩

2 The iCab rendering engine is much older, of course, originating in CAB on the Atari (TOS) in the mid-90s and arriving on the Mac in late 1998/early 1999. Similar to how Gecko was an entirely new rendering engine than the engine in Netscape 0.x-4.x, it’s exceedingly likely that the engine in iCab 3 shared nothing with its predecessor, save for the fact it powered the iCab browser. ↩