tenfourfox.com/floodgap.com temporarily offline starting 31 July

Starting tomorrow, Floodgap and all domains hosted on it (including tenfourfox.com) will go dark thanks to my new business ISP, Time Warner, who promised me two weeks for the buildout which has since ballooned into four weeks, beyond my contract with my current provider. Allegedly the buildout will be complete by the end of next week; during that time www.floodgap.com and gopher.floodgap.com will be dark, but you can still access the Google Code project and this blog, of course. E-mail sent during this time will fail over to my mail peer, but I will not be able to receive it until I'm back online.

I apologize for the downtime and I'll be happy to post the rep's cell number if this takes longer than a week, since I have a signed contract with them and I'm pretty steamed.

2 6 4 H what browser do we 'preciate

So Lion came out today and as expected it only serves to make Macs stupid. So maybe we were the smart ones for sticking with PowerPC after all. Still, Walt Mossberg likes it, in the way he likes most things Apple puts out, as I found out from watching his H.264 video at the Wall Street Journal. ... Oh, snap! Did I not tell you? Let's watch H.264 videos from TenFourFox! Not even Firefox can do this trick!

Because Flash or Safari are obviously the only ways to watch H.264 video online from a Power Mac, and we're trying to jettison Flash, an idea I'd had kicking around for awhile was to enable a QuickTime window so that you could watch the video, at least, even if it wasn't composited into the browser. While fiddling around with 6.0, I realized that Firefox's js-ctypes module could allow the browser to do this kind of manipulation in JavaScript. Better still, it could be implemented as an add-on so that people who want to play with it can. Even better still, Mozilla had a supported example of feeding images to iPhoto which I could modify to feed videos to QuickTime. It just needed to be updated to be a restartless Jetpack, which I've done too.

The trick is QuickTime Media Links (.qtl), a little-used feature of QuickTime classic -- but notably not QuickTime X -- which lets you build lightweight Internet "media shortcuts" and feed them to QuickTime Player, which then goes and fetches the video online for you. So this add-on is, in essence, quite simple: select a media element (video, audio and images are supported), determine its source and write up a temporary .qtl file, and then feed that to QuickTime Player. QuickTime handles all the streaming and playback. No mucking around with AppleScript, just "clean" CoreFoundation code. In practice it's not quite that simple, but we'll talk about the limitations in a bit after you've had a chance to play.

1. Download the add-on. Don't install it yet. Remember, this is alpha software. It has not been well-tested on 10.5 or on a large number of sites.
   
2. These make good demos: either Walt Mossberg's Lion video review, which won't play at all in TenFourFox, or this HTML5 video test, which will normally play WebM in TenFourFox (but has H.264 as an alternate). Open it up for the standard behaviour to see what it does without the add-on.
3. Drop the add-on on the TenFourFox window. This extension is only supported for TenFourFox 6. I do not plan to support it in 5 or 4. You will be prompted to confirm its installation. It will install without a restart.
4. Now, right-click or Ctrl-click the video. There's a new choice: Open Media in QuickTime. Click it. A dialogue will tell you the new destination (mostly for debugging purposes). Then QuickTime Player will open, and ...
   
5. OMG!

The extension works for images, HTML5 audio and HTML5 video (although audio is not well tested yet). It will scan the available choices and prefer MPEG-4 (or MPEG-4 in an MOV container) since MPEG-4 can be hardware accelerated in QuickTime; otherwise it will go with what it can get. Images work too, mostly for purposes of demonstration. I'm considering making it prefer MP3 audio, but haven't decided about that yet.

Here's what doesn't work:

• WebM video for some reason won't play, even with Perian 1.2.2 installed, and I'm not sure why (QuickTime objects to the video format). I'm not really too concerned about this since the browser can play it, but it would be nice because it would expand the number of machines that can handle WebM video. I'm wondering if its media sniffing code is failing and I have to hint it a bit more.
  
• Autoplay doesn't work, even though I'm asking QuickTime to do it.
• Not all elements are detected by Firefox's context menu code as qualifying selectors, so some video elements will not offer you the option. I may need to simply ask for 'everything' and then filter it myself rather than relying on the browser.

I don't plan to make this a part of the browser for awhile, mostly because it needs a lot more testing and because even when it will be working it's still somewhat of a hack. Still, it does work, and gives us another way to keep our Power Macs supported with modern Web video. Please give it a try and let me know your thoughts. Remember, this is very alpha and very unfinished.

I have not heard much noise from Mozilla about the next 6.0 release. I am presently in the process of moving to a new house, so I will not able to generate builds for about a two-week period starting next week as the G5 is in transit. With luck this should coincide with the 6.0RC, since there have been no major problems reported thus far. Your patience is appreciated.

6.0b1 available

6.0b1 is now available, based on Firefox 6.0 "beta 2" internally (Mozilla, realizing the liability that rapid release is becoming, is trying to play down these numbers but ultimately I think that horse has already left the barn).

People like 5's speed; 6 is not IMHO appreciably faster, but does not appear appreciably slower either. It is a bit more busy, however. Recent patches to garbage and cycle collection have calmed this down, supporting my theory that more aggressive garbage collection is the reason, and on my G5 5.0 used around 3% CPU at baseline whereas 6.0b1 now uses around 6-7%. This is less on my iBook, which went from 2% to about 4%, but still higher. Fortunately this does not seem to translate to poor responsiveness, and the browser in my informal measurements does seem to be hanging on to less memory, so at least it's achieving its purpose. The big changes for memory usage, however, will not emerge until Firefox 7.

As mentioned, 6 adds mostly under-the-hood features again, chief amongst them Mozilla's personal flavour of WebSockets; more HTML5 features; media query support; and some handy but unspectacular developer tools. There is also about:permissions, which doesn't really do much for me compared to the (much faster) Preferences tab and isn't exposed in the UI which implies it's not doing much for Mozilla either. Still, these are necessary changes, and at least they're out in our hands faster, so rapid release is at least achieving that goal even if it's cheesing off the rest of the known galaxy over the version number creep in the process.

There are some slight improvements to JavaScript performance due to code reorganization, but most of this is barely above the statistical noise threshold and probably isn't noticeable in practice.

In the bug fix department, 6.0b1 fixes the issue with 10.5 and Java that Apple deliberately caused (see bug 668639), as well as Twitter's site redesign that causes the browser to stall out on fat regexes (issue 77) and cut down on spamming the console log with debug information (issue 70).

Also, I managed to get ahead of schedule with my move and sit down with some custom code. Specific to 6.0 are two AltiVec-enhanced changes for text and HTML processing: a VMX text fragment scanner, which improves dynamic operations on pages by 10-15%, and AltiVec-accelerating UTF-8 to Unicode conversion. Because OS X usually hands us 16-byte aligned memory allocations, even though we have no equivalent for the SSE2 unaligned store code in that routine we're still usually able to use the AltiVec fast path.

In addition, a double-pumped 128-bit algorithm is now available for AltiVec WebM YCbCr conversion, improving over 5.0's algorithm by 30-40% and translating to a real 5-10% improvement in video playback. Speaking of, Mozilla is futzing around with the buffering algorithm again. In 5.0, Mozilla would hold video in favour of audio, even if that meant stuttering the video. In 6.0, Mozilla will "pump video," even if the audio can't keep up, more along the way that 4.0 used to do it. I prefer the former, but I know some people prefer the latter. There is no easy way to switch between them and I bet 7.0 will change this around some more, but have your say in the comments.

Speaking of video, this is what you will now see by default if you go to a Flash-enabled player or application:


That brings us to plugins. Plugins are disabled, as warned. By default, this is what happens now:

• Sites will think you have no plugins installed. This is the correct behaviour, because that allows the site to present you with alternate (hopefully HTML5) content.
  
• If the site is hard-coded to use an applet, object or embedded plugin instance, the message above (or one like it) will appear. If the element is positively identified as a plugin, the "More information ..." link will take them to this wiki page on the subject.
  
• Both about:addons and about:plugins will show no plugins installed; about:addons will explain why.
  

Without rehashing earlier arguments on the subject, plugins aren't being maintained for PowerPC, aren't secure, already can't access some content requiring later versions (such as Flash 10.2 and 10.3), already have bugs, and are being changed in Mozilla in ways that will likely make them incompatible anyway. I assume that if you read this blog, you are already aware of all this. It is not my intention to specifically break plugins, but I want it clear that I won't support them further and people use them at their own risk. Furthermore, the browser must ship in a safe configuration out of the box rather than expecting people to install things like Flashblock (which I heartily recommend). That said, plugin code is an integral part of the codebase, so there will always be plugin code in TenFourFox. There's just no guarantee that it will work, and 6.0 already has at least one change that will break compatibility with certain older plugins.

Regardless, I did promise you that you can still opt back in. Before you do, understand the following caveats:

• The browser will always ship with them disabled. Your previous setting will stick, of course, should you choose to opt-in, but by default they will not function.
  
• No bug in plugin support, even a serious or crippling one, will ever hold a release back. While I may try to fix bugs if I have some spare cycles (as if!), I make no guarantees or promises.
  
• Application issues with plugins in operation, even crashes, may be WontFixed as bugs if other issues have precedence or for any other reason. However, bug reports with patches are welcome -- strongly encouraged, even. If you want something fixed and you can fix it, contribute. I've got enough work to do just fixing all the stuff Mozilla breaks in 10.4.
  
• Finally, plugin code may stop working at any time without warning. I'll reasonably endeavour to prevent this, but if plugin code is preventing the browser from functioning I reserve the right to stub it out entirely to get the rest of the browser to operate, and even if it does compile it may be utterly bogus.

The relevant plugin settings are in, natch, about:config. There are five specific settings related to plugins:

1. The master switch is tenfourfox.plugins.enabled, which by default ships set to false. In this mode, the browser pretends as if there are no plugins at all and all of the other settings are irrelevant. You can dynamically switch it to true and reload the page to instantiate the plugin, but it's best to restart the browser afterwards after flipping the switch to true to make sure that all of your plugins are re-enumerated properly.
2. Embedded plugins are controlled by tenfourfox.layout.hideplugins. This ships also set to false, so embedded plugins are not hidden by default, assuming plugins are enabled. If set to true, this only prevents the plugin from starting up and operating; a placeholder will still appear on the page (usually blank space), and the page will still think that the plugin is operational in most cases. This setting is the riskiest one to enable, as it can facilitate drive-by instantiation of plugins.
   
3. Scrolling plugins is controlled by tenfourfox.layout.smooth_scroll_plugins. This ships set to true, so that any instantiated plugin in that window will force smooth scrolling on to reduce graphical artifacts. This can be annoying on slower systems, so for them you may wish to set this to false.
   
4. Full-page plugins, such as QuickTime objects and PDF files, are controlled by tenfourfox.layout.hide_fullpage_plugins. This ships set to false, so full-page plugins are not disabled by default, although due to painting bugs you may need to interact with them blindly to get them to start. If set to true, the plugin will simply not start when instantiated in full-page context, although it may still work embedded (such as QuickTime).
   
5. The Java plugin is controlled specifically by tenfourfox.layout.hide_java_plugin, which ships set to true and applets requiring the plugin will not start (though other applets may). However, depending on your system, the Mozilla Java Embedding Plugin may not be what you want anyway; you may want the Apple provided Java Plugin. Remember that Java is deprecated and will become unsupported by TenFourFox when 10.5 is unsupported by Apple (which will be very soon now). Check that your applet works without plugin support before messing with this option, as certain Java applets will crash the browser within the plugin context.

For the record, I am putting my money where my mouth is. I'm watching my videos in MacTubes or over WebM, I view my PDFs outside of the browser, and listen to music files in QT Player and watch Flash videos with Perian. Security must come first, even at the cost of functionality or convenience. I hope you will agree, and even if you don't, I hope that you'll appreciate I've tried to meet you halfway with this back-door option.

Release notes and builds:

• G3
• G4/7400
• G4/7450
• G5

5.0.1 = 404

While I finish rebuilding 6.0b1, a parenthetical note that there will be no TenFourFox 5.0.1. We aren't affected by the font issue on 10.7, obviously (and the code is riskier on 10.4), and the 10.5 Java issue can be worked around using the Terminal tips in bug 668639. Since releases are expensive for us, a single workaround-able issue is not enough to force a new version on our end. While I will revise the 5 changesets to deal with the font issue changes, that will occur after the beta comes out, or they can be applied to the original 5.0 source tarball instead of the current hg tree tip.

Sweet 6 point oh een (or something)

The reason it's been quiet here lately is, of course, that I was working on porting Firefox 6.0, which hit the beta channel on Tuesday, and there it is. In fact, this post was written up in it.

6.0 is the first full iteration of Mozilla's rapid release strategy (i.e., a full 6 weeks at each stage), and yet, if Firefox 5 should really have been Firefox 4.1, this still feels like 4.2. Out of the box, the only major user facing feature is "highlighting" domain names in the URL bar (really, dimming the rest of the URL). This is another Chromism and I'm not really very fond of it personally. Mozilla is also introducing, as a trial balloon, a Permissions Manager accessible under about:permissions. However, if you're like me and have a lot of specific cookie permissions, it takes forever to load and is not significantly better than the old way with preferences; it's also not exposed in the UI anywhere.

Under the hood there are additional HTML5 elements now supported, most notably <progress>; WebSockets (which were pulled for security reasons in Fx4); enhanced developer tools, and MatchMedia support. And, well, that's about it.

The build is not going entirely smoothly. Tobias Netzel has shipped me a 64-bit version of the ported Xcode linker we use while I try to get a debug build mounted, but optimized builds do function, obviously. However, the debug build is exhausting the memory on the 8GB G5 buildhost, so this appears to be a 32-bit limitation. We may have to add a build requirement that the debug build be built with the 64-bit version of the linker, which would limit the machines that can build it, unfortunately. More on that as we sort this problem out.

Specific to us, I'm phoning this release in because Mozilla landed a lot of crap that tripped up porting our changesets. Among the new changes was splitting off some of the text handling features in the Cocoa widget code (bug 519972), which naturally upset the Tiger customizations I had made. I believe I've successfully dragged back all the 10.4-specific code that we need into the new places, but I'm still not convinced everything is correct. This took several days to rewrite, and we will have another set of rewrites to do in Firefox 8 related to it. On top of that, Mac OS X 10.7, which went golden master and is expected to emerge "any day now," has serious bugs in its implementation of ATSUI (bug 663688, currently sec-locked), which we must use in 10.4 because 10.4's secret Core Text support is incomplete. Mozilla thus rewrote much of the legacy font handling code we rely on in terms of Core Text, which blew up the compile on 10.4. I've hacked this back into submission, but it will break again because that whole section will be revised when 10.5 support is dropped from Firefox and I am unfortunately all but certain that will occur somewhere around Firefox 9, early next year. After all that work, and trying to move to a new house, I really haven't had time to work on more TenFourFox optimizations for this release. We should get a break in Firefox 7 (if we're still able to build it, of course), so if we get Fx7 to stand up as 10.4Fx 7, then I'm going to work on some more AltiVec improvements at that time.

That brings us to plugins. Mozilla has made the first change which will break some legacy plugins in bug 468678, which was a long-warned threat to disable resource files as a data exchange method in Mac plugins. Cursorily Flash and QuickTime don't seem affected in their recent versions, but people using old versions might not be so lucky, and other plugins depending on this will break. This is the first change of many that will erode plugin operation, so as threatened, this version turns plugins by default off and support for plugins ends. I have wired up a preference to reenable them which will be posted here, as I assume if you follow this blog that you are technically versed enough to understand they are no longer supported, may not work correctly, may not work at all in the future, and already have known bugs. More about that when I get 6 beta 1 polished for release, hopefully next week.

On the 5 front, Mozilla is ruminating about a 5.0.1 release to address the 10.7 issue I explained above. This is not decided yet, but my insiders tell me it's probably going to happen and would be a Mac-only release fixing that bug only. This does not affect us right now, but because it has the font changes in it, it requires us to backport our fixes for 6 to 5 which could be iffy if we need to build more versions from 5 (such as we find some showstopper in TenFourFox 6 that requires an interim 5.x security release to be made). This will also snarl our home builders, so we may need to issue a workaround for you folks as well. We'll deal with this if action is required. As a point of completeness, 4.0.3 remains the terminal release for TenFourFox 4.

Speaking of 5, David Fang, our indefatigable Fink porter, reports that TenFourFox 5 now builds on 10.5 and 10.4 from the Fink unstable tree, and he and his crew are getting 10.5 support backported to TenFourFox 4. So those of you who want to continue making custom builds, but are allergic to MacPorts, continue to have that option. Strong work!

Finally, Chris Trusch's legwork on the Java and TenFourFox 5 issue has culminated in Apple essentially admitting that they broke Java on 10.5 on purpose in bug 668639 (except, of course, for Safari). The solution is, natch, to upgrade to Snow Leopard, and Apple says that the problem is a "non-issue for PPC users, because Firefox 5 and Chrome only run on Intel Macs." Don't we just love those guys? If we end up releasing a 5.0.1, we will have a workaround in it, or you can use the symlink fix detailed in the thread. The code for it will be in 6, but Java will also become unsupported, as I expect Update 10 to be the final Java update for PowerPC.

Watch for builds next week, hopefully. There will be a period of brief downtime on Floodgap while I physically move the hardware to a new network and new data center, but the Google Code page and this blog will obviously remain in operation. I don't expect the network downtime to be more than 12-24 hours.