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.