This version also enables MP3 audio support by default (we use the minimp3 decoder, which I hacked for our purposes since AudioToolbox in 10.4 does not understand MP3). There are already some known files that don't play in it that do play in QuickTime, so this appears to be a bug in minimp3. If you report MP3 files that don't work, please include the encoder so we have at least a chance at something analysable. If you don't, I'll still accept the report, but I may not do much with it unless it's glaringly obvious what about the file it doesn't like.
With 38.5, Firefox 45, the next ESR, moves out of nightly into aurora. Since Mozilla is only up to the point of doing A/B testing for multi-process Electrolysis in Fx44 beta, it seems unlikely that 45ESR will make Electrolysis mandatory, so that means I would be foolish to not make at least an attempt at porting it. This will require another toolchain upgrade like we did for TenFourFox 19. Fortunately, we do have a working gcc 4.8 in MacPorts and it does build and run 38 successfully without our current gcc 4.6 shim, and I'm working with Sevan Janiyan to get the Tiger pkgsrc gcc 4.9 functional (it seems to need updates to as and ld, since it will parse the source, but currently builds a defective XUL). I'm also looking into using Misty DeMeo's Tigerbrew gcc as an alternative. Either way, after the update for TenFourFoxBox and its official release I'll probably start working on trying to adapt 45ESR, which should give us plenty of time to have a functional beta out by 45.1, assuming it doesn't blow up in my face.
I am, however, going to call 45 the end of source parity, and this time I mean it. I know I've said "the end" lots of times in the past, but besides the fact Electrolysis won't compile as-is on 10.4 (and quite possibly will be a net negative even if it works), and Electrolysis will almost certainly be mandatory by 52ESR now, Mozilla is now importing code written in Rust into Gecko, not just C/C++. Although Rust allegedly supports PowerPC, it is only known to work on Linux (and there isn't a snapshot, rustc or cargo for it even there); it is not known to work, or have a snapshot available, for OS X/ppc, and then there's the matter of llvm on our same platform. Mercifully it does not appear any of the existing Rust code (which is already in the tree) will be required for 45ESR, but it does appear that new Rust code will replace a number of older C/C++ modules by 52ESR once Mozilla works out the build system kinks, making Rust a build requirement. This would be a showstopper for us and any other Tier-3 platform that lacks a Rust compiler (Solaris on SPARC? the remnants of OS/2?). It would also probably signal the end of 10.6 support in the near future, since by default the Rust standard library requires features Snow Leopard doesn't have (though there are ways around it).
Frankly, I'm not going to maintain a completely new compiler for a language I'm not fluent in and its runtime platform on top of a browser and debugger I'm already maintaining singlehandedly when we're already facing two other portkillers (loss of 10.6 support, whenever that comes, and E10S). Assuming this trajectory continues unchanged we will drop source parity after 45ESR, but there will of course still be updates; besides new features we can now release since we're not worried about maintainability against Mozilla source anymore, we'd still get a fair chance to import later updates to the core that were still in C/C++, and we'd be still a very advanced browser for at least a couple years. We'd be better off than Goanna in Pale Moon, anyway, which is still 24.x-era with various patches.
It had to happen for real sooner or later.