Friday, January 22, 2016

38.6.0 available

TenFourFox 38.6.0 is available for testing (downloads, hashes, release notes). I'm sorry it's been so quiet around here; I'm in the middle of a backbreaking Master's course, my last one before I'm finally done with the lousy thing, and I haven't had any time to start on 45 so far. 38.6 does have some other fixes in it, though: I think I found the last place where bookmark backups were being mistakenly saved in LZ4 based on Chris Trusch's report, and the problematic fonts on the iCloud login page are now blacklisted, so you should be able to login again. I can't do much more testing than that, however, since I don't use iCloud personally, so other lapses in font functionality will require the font URL and I'll add them to the blacklist in 38.7. The browser will go live Monday Pacific time as usual. (The temporary workaround is to set gfx.downloadable_fonts.enabled to false, and switch the setting back when you don't need it anymore.)

Speaking of, downloadable fonts were exactly the same problem on the Sun Ultra-3 laptop I've been refurbishing; Oracle still provides a free Solaris 10 build of 38ESR, but it crashes on web fonts for reasons I have yet to diagnose, so I just have them turned off. Yes, it really is a SPARC laptop, a rebranded Tadpole Viper, and I think the fastest one ever made in this form factor (a 1.2GHz UltraSPARC IIIi). It's pretty much what I expected the PowerBook G5 would have been -- hot, overthrottled and power-hungry -- but Tadpole actually built the thing and it's not a disaster, relatively speaking. There's no JIT in this Firefox build, the brand new battery gets only 70 minutes of runtime even with the CPU clock-skewed to hell, it stands a very good chance of rendering me sterile and/or medium rare if I actually use it in my lap and it had at least one sudden overtemp shutdown and pooped all over the filesystem, but between Firefox, Star Office and pkgsrc I can actually use it. More on that for laughs in a future post.

It has been pointed out to me that Leopard Webkit has not made an update in over three months, so hopefully Tobias is still doing okay with his port.

12 comments:

  1. I am probably doing something that affects the stability of TTF on my G5. Too many tabs open, or some combination add-on makes the browser crash and forces multiple restarts of reopen it. Can you make any general suggestions? I may be overloading TTF and this is creating the instability. Many thanks for your great work!

    ReplyDelete
    Replies
    1. I'm not sure what to say. I have a very large number of tabs on my Quad and I haven't had it crash repeatedly, and I haven't received an abnormal number of such reports. I can only recommend the usual advice to see if it happens on a clean profile and act accordingly.

      Delete
    2. Could be a number of things. Faulty ram (I have a ram slot in my G4 that makes running any app unstable when there is a ram stick in it), memory leaks from addons, excessive addons, etc.

      There are also a number of about:config options you can configure to make the browser more responsive, less memory intensive and faster.

      Delete
    3. Thank you - all good suggestions. I'm a non-tech guy but plan to test all the items you mention. Again, many thanks!

      Delete
    4. This is by no means comprehensive, but worth a look as far as addons and settings in about:config.

      http://forums.macrumors.com/threads/my-tenfourfox-about-config-tweaks-and-my-addons.1838393/

      Delete
  2. I'm not sure what that was, but the core dates from October, unless he's uploading them somewhere else?

    http://sourceforge.net/projects/leopard-webkit/files/600/Leopard/PowerPC/

    ReplyDelete
  3. SPARC laptop? That's something I hadn't heard of!

    Thank you so much for all the work and happy new year!!

    ReplyDelete
  4. This comment has been removed by the author.

    ReplyDelete
  5. I don't feel motivated to backport WebKit 601 (Safari 9) or later to C++03 (gcc 4.2) mainly for the following reasons:
    - WebKit 600 is very stable
    - vast majority of web sites do still fully support WebKit 600
    - backporting might easily take some months (and it cannot be ported incrementally but needs to be almost completely done before the first test run)

    My original motivation for beginning with Leopard WebKit was unstable and outdated WebKit on OS X 10.5 - and that goal seems to have been accomplished now.
    But who knows - might be I'll finally try to get the JavaScriptCore JIT working.

    ReplyDelete
  6. It wouldn't be amenable to a later compiler?

    ReplyDelete
  7. Thanks for all your efforts! I have a couple questions if you've got a minute. When I have TFF running for a while with a bunch of tabs open, it starts to bog (G4 powerbook, 1.25GB ram). If I profile it, a lot of time goes into:

    XUL js::MemoryReportingSundriesThreshold()
    mach_kernel vm_map_lookup_entry

    This seems like it's running out of memory, but activity monitor still shows a bunch of "free" and "inactive" memory. Also, if I close other apps using memory, there is more "free" memory but no change in TFF. If I close the browser and restore the previous session the problem is solved for a while. Any thoughts on this? Perhaps I have some memory reporting setting enabled that should not be?

    What are your thoughts on the various configuration settings mentioned above?

    Also, (I know this is not TFF specific) how does google know it's not my default search engine? They're also doing weird stuff with their links that somehow change when you right click on them. Is this some javascript shenanigans? Basically, how can I neuter google.com so it behaves?

    ReplyDelete
  8. Thanks for that hint! In fact I had already given up gcc some years ago and didn't even consider trying that again.
    From gcc 5 on C++ lambdas in Objective-C++ are correctly recognized (gcc 4.9 didn't) which is used excessively in current WebKit sources.
    So I merged support for header-maps (Xcode technique for not having to add all source code directories to the include path) from Apple gcc 4.2 into 5.3, wrapped the Apple driver-driver around it by using macportsGCCfixup from github and I was able to compile JavaScriptCore.
    And thanks to you there's even a debugger available I can now use to get the C loop interpreter working again.
    I'm not sure whether or not I'll be able to build WebCore and WebKit but since quite some MorphOS people are waiting for PowerPC patches for JavaScriptCore that piece of work wouldn't be wasted.
    Thanks again for encouraging me to give non-Apple gcc one more chance - and I think the deeper C++ knowledge I acquired by backporting to C++98 will serve me a lot now.

    ReplyDelete

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