Saturday, August 1, 2015

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.

17 comments:

  1. Quick test: I can confirm that all bugs are fixed. I haven't been able to trigger the exit crash so far.

    Is the darker bookmarks toolbar intentional?
    http://s16.postimg.org/xnrojx4tx/bookmarks_bar.png

    ReplyDelete
    Replies
    1. That wasn't a change I introduced myself (that I know of). I'll see if it can be changed back to match.

      Delete
    2. I think that chrome://browser/skin/Toolbar-background-noise.png is now (by accident?) also color-managed and/or incorrectly tagged. If I set gfx.color_management.mode to 0, the problem is gone. As a workaround one could darken the url bar gradient a bit in browser.css to match the bookmarks toolbar.
      linear-gradient(hsl(0,0%,93%), hsl(0,0%,83%));
      -> linear-gradient(hsl(0,0%,89%), hsl(0,0%,79%));

      Delete
    3. Good spot. I may simply just change it to use a solid colour instead.

      Delete
    4. Thank's Chris for this trick. I changed a little bit the css for a smoother gradient.
      -> linear-gradient(hsl(0,0%,94%), hsl(0,0%,79%));
      http://s13.postimg.org/rf31tqown/Bar_Perso.jpg

      after a first test of the new update, I have no problem with RAM when I leave TenFourFox ... All work fine for me ;o))

      just one small bug in the "about:preferences#privacy"
      http://s13.postimg.org/wdje85sqf/Setting_Panel.jpg

      Thank's for the great job

      Delete
    5. I know about that bug, and currently I can't fix that without breaking the help button on other dialogue boxes. (Admittedly it's sort of useless because the backend doesn't yet exist, but anyway.)

      Delete
  2. I can report the Facebook issue as fixed. Looks great so far. This version seems more stable than the last.

    ReplyDelete
  3. One very minor issue I have found in 38.1.1:

    In bookmark management, if you sort them in some other way besides the default, you then cannot drag them into folders. Closing the bookmark manager window and reopening is the only way to get full sorting ability back.

    Like I said... it's very minor.

    ReplyDelete
    Replies
    1. I tried this and it seemed to work fine here. Can you give me the exact steps you took to reproduce? I was able to change the sort order, and have it alternatively sorted, and still drag and drop into bookmark menu folders.

      Delete
    2. I opened the management window - sorted by location - then could drag, but not drop items into folders. Once I closed the window and opened it again all was well.

      It's on Leopard (10.5.8) and I am specifically running the 7450 build.

      I just tried it again, and got the same result. Odd that you can't recreate it.

      Delete
    3. I set it to location, and I can still drag and drop on folders. However, this is 10.4, so perhaps someone on Leopard can try (though any change is probably too late to make final; Mozilla already has build tags down for 38.2).

      Delete
    4. "though any change is probably too late to make final"

      I'm all good with that. It's far from a deal breaker for me. It's not like I constantly sort my bookmarks. It's something I normally do as I save them, but I just get a bit sloppy with organizing things at times.

      This is a twice a year type of task for me.

      Delete
    5. I should also add that sometimes I cannot even drag things after sorting by location.

      Delete
  4. I can reproduce this both on Tiger and on Leopard.

    ReplyDelete
    Replies
    1. Are you referring to my issue? You have it on both OS?

      Delete
    2. I'm referring to the bookmarks sorting issue. Sorry, hit the wrong "reply". I have TFF on 10.4 and 10.5 on three different Macs, one G4 and 2 G3s.

      Delete
    3. I tried it on the iMac G4 (7450) and it works there too. I'll try it on the iBook when I get to the hotel, but I must be doing something different than you guys, because I still can't reproduce it here.

      Delete

Due to an increased frequency of spam, comments are now subject to moderation.