38.2.1 is available

TenFourFox 38.2.1 is available (release notes, hashes, downloads). Due to the fact this is a chemspill and we're already delayed, it will become live by this evening. Other than the Mozilla fixes, issue 306 is also repaired. Further work on 38's MP3 support is being deferred until the replacement hard disk arrives (should be early next week).

Don't forget to test 38.2.1 with incremental GC disabled. See the previous post. Enjoy our new sexy wiki, too. Sexy. Yes.

38.2.1 delayed due to hardware failure

TenFourFox 38.2.1 was supposed to be released to you today but the hard disk used for compiling it blew up sometime yesterday and I've been recovering data from the drive and the last backup instead. The G5 version was built before the disk died, and does check out, but the other three builds haven't been yet. Let this be a reminder that DiskWarrior can fix a lot of things but not hardware failure (and people complaining of random faults in TenFourFox, please check your hardware first -- the symptom here was random freezes because the electronics kept dropping the drive off the SATA bus unexpectedly), so Data Rescue is busy getting the recoverable pieces off it and the rest I can restore from the file server. Both tools belong in your Power Mac bug-out bag and both still support PowerPC, so please support those vendors who still support us. It should be repaired enough to resume builds hopefully late tonight but I don't have an estimated time of release (hopefully no later than Sunday). It includes two Mozilla fixes and will also include a tweak for TenFourFox issue 306.

In the meantime, a fair bit of the wiki has been updated and rewritten for Github. I am also exploring an idea from bug 1160228 by disabling incremental garbage collection entirely. This was a bad idea on 31 where incremental GC was better than nothing, but now that we have generational garbage collection and the nursery is regularly swept, the residual tenured heap seems small enough to make periodic full GCs more efficient. On a tier 1 platform the overhead of lots of incremental cycles may well be below the noise floor, but on the pathological profile in the bug even a relatively modern system had a noticeable difference disabling incremental GC. On this G5 occasionally I get a pause in the browser for 20 seconds or so, but that happens very infrequently, and otherwise now that the browser doesn't have to schedule partial passes it seems much sprightlier and stays so longer. The iBook G4 saw an even greater benefit. Please note that this has not been tested well with multiple compartments or windows, so your mileage may vary, but with that said please see what you think: in about:config set javascript.options.mem.gc_incremental to false and restart the browser to flush everything out. If people generally find this superior, it may become the default in 38.3.

Okay, you want WebExtensions API suggestions? Here's three.

Not to bring out the "lurkers support me in E-mail" argument but the public blog comments are rather different in opinion and tenor from the E-mail I got regarding our last post upon my supreme concern and displeasure over the eventual end of XPCOM/XUL add-ons. I'm not sure why that should be, but never let it be said that MoFo leadership doesn't stick to their (foot)guns.

With that in mind let me extend, as an author of a niche addon that I and a number of dedicated users employ regularly for legacy protocols, an attempt at an olive branch. Here's the tl;dr: I need a raw socket API, I need a protocol handler API, and I need some means of being able to dynamically write an document/data stream and hand it to the docshell. Are you willing?

When Mozilla decommissioned Gopher support in Firefox 4, the almost universal response was "this shouldn't be in core" and the followup was "if you want it, it should be an add-on, maintained by the community." So I did, and XPCOM let me do this. With OverbiteFF, Gopher menus (and through an analogous method whois and ph) are now first class citizens in Firefox. You can type a Gopher URL and it "just works." You can bookmark them. You can interact with them. They appear no differently than any other web page. I created XPCOM components for a protocol object and a channel object, and because they're XPCOM-based they interact with the docshell just like every other native core component in Necko.

More to the point, I didn't need anyone's permission to do it. I just created a component and loaded it, and it became as "native" as anything else in the browser. Now I need "permission." I need APIs to do what I could do all by myself beforehand.

What I worry is that Mozilla leadership is going to tick the top 10 addons or so off as working and call it a day, leaving me and other niche authors no way of getting ours to work. I don't think these three APIs are either technically unrealistic or lack substantial global applicability; they're foundational for getting new types of protocol access into the browser, not just old legacy ones. You can innovate nearly anything network-based with these three proposals.

So how about it? I know you're reading. Are you going to make good on your promises to us little guys, or are we just screwed?

Mozilla's future footgun add-on policy (or, how MoFo leadership is getting it totally wrong)

So long, Firefox. It was nice to know you.

First, Electrolysis. As mentioned, we won't support it in TenFourFox; we would need to implement a userland spawn implementation for 10.4 from scratch for starters, and I suspect that the overhead required will end up performing substantially worse on old Macs plus the inevitable OS bugs it will undoubtedly uncover. Currently Mozilla is predicting Electrolysis will reach the release channel by Fx43, which I find incredibly optimistic given predictions for Australis which slipped deadline after deadline, but it's clear Electrolysis' public unveiling in the relative near future is inevitable. Once it becomes no longer possible to launch the browser in single-process mode, likely one or two versions after, that's the end of source parity. My suspicion is that it will actually reach release by Fx45, which is the next ESR anyway, and there should be an emergency fallback to single-process that we can exploit to keep us running at ESR parity for the last time.

To facilitate addons in the new e10s world, Mozilla is effectively announcing that XPCOM/XUL-based addons are now deprecated because of their highly synchronous nature. (Technically, they'll be deprecated six months after Electrolysis goes golden master, and completely unsupported and/or incompatible within six months after that, but as far as I'm concerned announcing a future deprecation is the same as deprecating it now.) This sucks because the use of XPCOM and XUL in the Mozilla Suite and later Firefox and SeaMonkey meant easy cross-platform add-ons that could do powerful things like implementing a completely new protocol within the browser. Although jetpack addons will still work, sort of, any jetpack addon that requires chrome features is subject to this policy also. Mozilla will be enforcing this brave new XUL-free world by refusing to sign addons that rely on XPCOM or XUL in this later timeframe, which dovetails nicely with not allowing unsigned addons starting with Firefox 42. (Parenthetically I don't agree with the mandatory signing policy, and if there is a TenFourFox 45 it will disable this feature. I don't port Gecko code for the walled garden, guys, thanks.)

Calling this a footgun and the future death of Firefox is not merely hyperbole. I suspect, and I suspect Mozilla is ignoring the fact, that many Firefox users use it because of the presence of such powerful addons that just can't be replicated in other browsers. Chrome, for example, doesn't have near the functionality because it doesn't expose it, and its addons are much less useful in general. But Mozilla is not content to merely shoot themselves in the foot here; they've emptied the whole magazine into their leg by making the new add-on world based on the almost completely different WebExtensions API. WebExtensions is Blink-compatible, the engine powering Chrome. That means an author can easily create a much less functional addon that runs not only on Firefox but also on Chrome. Yup, you read that right: soon the only functional difference between Firefox and Chrome at this rate will be the name and the source tree. More to the point, many great classic addons won't work in the new API, and some addons will probably never be made to work with WebExtensions.

Riddle me this, Batman Mozilla leadership: if the addons are the same, the features are the same, the supported standards are the same, the interface is converging and Mozilla's marketshare is shrinking ... why bother using Firefox? I mean, I guess I could start porting SeaMonkey, although this announcement probably kicks the last leg out from under that too, but does Firefox itself, MoCo/MoFo's premier browser brand, serve any useful purpose now? Don't say "because it makes the web free" -- people can just go download and compile WebKit, which is open source, well understood and widely available, and they can even usefully embed it, another opportunity Mozilla leadership shortsightedly threw away. They can fork it like Google did. They can throw a shell around it. Where's the Gecko value now?

Maybe this is a sign that the great Mozilla experiment has finally outlived its usefulness. And frankly there won't be much value in a Gecko-based browser or even a Servo-based one that works exactly the same way as everything else; notice the absolute lack of impact Firefox OS is having on mobile, although I use and prefer Firefox Android personally just because I don't trust Chrome. Maybe that trust will be the only reason to keep using Firefox on any platform, because I certainly can't think of anything else.

Meanwhile, this weekend I'm rewriting TenFourFox wiki documentation on Github ahead of the impending read-only status of Google Code. Since this is true Markdown, I'm using Nathan Hill's SimpleMarkPPC since it works pretty well for simple documents of this type and runs on 10.4. I won't be copying over all the old release notes, but starting with 38.3 all future ones will be on Google Code as well. After that we'll work on the MP3 support to finalize it, and I've got a secret project to share hopefully next week.

38.2 available, and Google Code ain't

TenFourFox 38.2 "final" is now available (downloads, release notes and hashes). This will be the last release with documentation on Google Code because I punched the button today to start moving data over to the new TenFourFox Github repo. Please note that the repo won't have a lot in it currently because Google Code is still dumping stuff over and we're still on source parity with 38ESR (we'll see about what happens next, but we have bigger fish to fry in the interim). Please do not modify issues or update wiki pages on Google Code any longer -- they will not be reflected on Github. If you have issues to file, note them here or on Tenderapp.

Langpacks for 38 are also available.

The next step will be updating the home page with the new URLs, then starting work on the revised FAQ, hashes and release note templates. As usual, 38 will become final on Monday afternoon-ish Pacific time.

TenFourFox and MFSA 2015-78

Mozilla released Firefox 39.0.3 and ESR 38.1.1 to fix an underlying vulnerability in security principals that can be exploited through the built-in PDF viewer. The bug does not enable arbitrary code execution (that we know of) but can insert JavaScript into a local file context and enable certain privileged behaviours.

TenFourFox 31 does not have the PDF viewer enabled by default, so it is not known to be vulnerable in the shipped configuration. Several diligent attempts to exploit it through other means last night were fruitless, so while it may be possible, I doubt some bright person will manage to do so before the general availability of TenFourFox 38 this coming week. On the other hand, if you have enabled PDF.js in 31.8 through about:config, your browser is now in an unsupported and exploitable configuration, and you should turn it off. This is not true of regular Firefox ESR 31.8, which is vulnerable, and due to the impending end of support for that branch will not be updated.

The TenFourFox 38 betas are vulnerable. If you're using a vulnerable version of TenFourFox (or Firefox ESR, though you should really just update if you're on a Tier-1 platform), you should disable in-browser PDF viewing by setting pdfjs.disabled to true temporarily until 38.2 final is available, which is building as we speak and should be available to testers sometime tomorrow Pacific time. It includes minor cosmetic fixes for the gradient over the URL and bookmarks bars (I used Grafik's numbers since they seemed to work the best; thanks!), fixes the update interval and removes the unsupported Marketplace button from about:home.

TenFourFox 38 beta 2 available

The next TenFourFox beta is now available (downloads, release notes, hashes). Officially, the version number is 38.1.1b2 due to the revbump on that ESR branch.

The most important bug this fixes is, of course, our new IonPower JavaScript JIT compiler backend wreaking havoc with Faceblech and Farceboink-derived sites such as Instacrap. Near as I am able to determine, as a conscientious objector to the Zuckerbrat Amalgamated Evil Empire, this fixes all outstanding issues with these sites. Oddly, the edge case responsible for this was not detected by Mozilla's JIT tests, which is probably why most sites were unaffected; the actual problem was diagnosed only by a couple of weird failures while running the strict ECMA conformance suite. Also, as mentioned, the engine has been tuned a bit more for improved overall throughput, and is approximately 4-5% faster than beta 1.

Some of you complained of a quit bug where memory usage would skyrocket while exiting the browser, causing it to crash after exhausting its addressing space instead. I cannot confirm this specific manifestation on any of my test systems. However, I did find another bug in the webfont cache that may be possibly related: if you close a window with webfonts loaded in it that are slated for cleanup, the browser can get stuck in an infinite call loop while freeing those resources, which will exhaust the processor stack. This issue is specific to our Apple Type Services font code. On TenFourFox the stack allocation is an entire gigabyte in size because of ABI stack frame requirements, so completely using it up may well freak out systems with less memory (all of my test machines have at least 1.25GB of RAM). In any case, that bug is fixed. Hopefully that's actually what you're seeing, because I still can't reproduce any problems with exiting.

A Leopard-only crash observed on the New York Times is now fixed by implementing a formal webfont URL blocklist; Tiger users don't crash, but get various weird and annoying font errors. This is caused by yet another underlying ATS bug. Safari on 10.5 is subject to this also, but it (and Leopard WebKit) get around the problem by turning the ATSFontRef into a CGFontRef and seeing if it validates that way (see issue 261). This is clearly a much better general solution, but while these functions exist as undocumented entry points on 10.4 they all call into ATS, so 10.4 users still get the weird messages. The only way to solve this fully on both operating systems is to just block the font entirely. Previously we did this by blocking on the PostScript name, but the New York Times, because it is old and senile, uses webfonts with the supremely unhelpful PostScript name of - and blocking that blocked everything. Fortunately, various reorganizations of the Gecko font system make it easy to wedge in a URL blocker that looks at the source URL and, if it is a known bad font, tells Gecko the font is not supported. The font never loads, Gecko selects the fallback, and the problem is solved. This problem also affects 31.8, but the solution is much different for that older codebase and there won't be another 31 anyway.

In the non-showstopper category, the issues with saved passwords not appearing in preferences and checkmarks not appearing on context or pull-down menus are both corrected. In addition, I reduced window and tab undo limits to hold onto less memory (back to what they were in 31), forced tenured objects to be finalized on the foreground thread to get around various SMP problems (again, as in 31 and in 17 and previous), tweaked media buffering a bit more, fixed a nasty assertion in private browsing mode with saved logins, and turned on colour management for all the things as politely requested by Dan DeVoto. The blank saved passwords list is actually due to the fact we can't yet compile ICU internationalization support into XUL because of issue 266, which also appears to be why Zotero started failing, since it also depends on it. For 38.2 final, both of these issues are worked around using trivial stubs and some minor code changes. Hopefully we can get it to make a shared dylib for a future release of 38.x and remove these hacks.

There are two changes left for final: put the update interval back to every 24 hours, and possibly remove the Marketplace icon from the Start page since we don't really support the webapp runtime. (The Apps option was already removed from the drop-down menus.) No one has complained about the faster/lower quality downscaler, so that will remain as is; about the only place it annoys me personally is favicons. Full MP3 support is being deferred to a feature beta after 38.2.

Builders will want the new versions of strip7 and gdb7. In fact, you'll need the new strip7 to build 38.1.1, because it fixes a crash with setting section flags. Although the gdb7 update to patchlevel 3 is optional, it is much faster than patchlevel 2, and will cause you to go less crazy single-stepping through code. Now that all the known build problems are dealt with, I am hopeful our builder in the land of the Rising Sun can make the jump to Tenfourbird 38 along with us.

Finally, many thanks to our localizers; the current list is English (natch), Spanish, French, Italian, Russian, German, Finnish and now Swedish. We still might need some help with Polish, and I cannot find an old copy of the Japanese language pack, so it is possible that localization will have to be dropped. Please help us with Polish, Japanese, or your own language if you can! Localizations must be complete by midnight August 5 so that I have enough time to upload and write the new page copy ahead of the formal general release of 38.2 on the evening of August 10. See issue 42 if you'd like to assist.

Once 38 launches, we will transition from Google Code to Github (leaving downloads on SourceForge). All of our project activity on Google Code will be frozen on August 5 after the last localization is uploaded. More about that shortly.