Sunday, June 28, 2015

Hello, 38 beta, it's nice to meet you

And at long last the 38 beta is very happy to meet you too (release notes, downloads, hashes). Over the next few weeks I hope you and the new TenFourFox 38 will become very fond of each other, and if you don't, then phbbbbt.

There are many internal improvements to 38. The biggest one specific to us, of course, is the new IonPower JavaScript JIT backend. I've invested literally months in making TenFourFox's JavaScript the fastest available for any PowerPC-based computer on any platform, not just because every day websites lard up on more and more crap we have to swim through (viva Gopherspace) but also because a substantial part of the browser is written in JavaScript: the chrome, much of the mid-level plumbing and just about all those addons you love to download and stuff on in there. You speed up JavaScript, you speed up all those things. So now we've sped up many browser operations by about 11 times over 31.x -- obviously the speed of JavaScript is not the only determinant of browser speed, but it's a big part of it, and I think you'll agree that responsiveness is much improved.

JavaScript also benefits in 38 from a compacting, generational garbage collector (generational garbage collection was supposed to make 31 but was turned off at the last minute). This means recently spawned objects will typically be helplessly slaughtered in their tender youth in a spasm of murderous efficiency based on the empiric observation that many objects are created for brief usage and then never used again, reducing the work that the next-stage incremental garbage collector (which we spent a substantial amount of time tuning in 31 as you'll recall, including backing out background finalization and tweaking the timeslice for our slower systems) has to do for objects that survive this pediatric genocide. The garbage collector in 38 goes one step further and compacts the heap as well, which is to say, it moves surviving objects together contiguously in memory instead of leaving gaps that cannot be effectively filled. This makes both object cleanup and creation much quicker in JavaScript, which relies heavily on the garbage collector (the rest of the browser uses more simplistic reference counting to determine object lifetime), to say nothing of a substantial savings in memory usage: on my Quad G5 I'm seeing about 200MB less overhead with 48 tabs open.

I also spent some time working on font enumeration performance because of an early showstopper where sites that loaded WOFF fonts spun and spun and spun. After several days of tearing my hair out in clumps the problem turned out to be a glitch in reference counting caused by the unusual way we load platform fonts: since Firefox went 10.6+ it uses CoreText exclusively, but we use almost completely different font code based on the old Apple Type Services which is the only workable choice on 10.4 and the most stable choice on 10.5. ATS is not very fast at instantiating lots of fonts, to say the least, so I made the user font cache stickier (please don't read that as "leaky" -- it's sticky because things do get cleaned up, but less aggressively to improve cache hit percentage) and also made a global font cache where the font's attribute tag directory is cached browser-wide to speed up loading font tables from local fonts on your hard disk. Previously this directory was cached per font entry, meaning if the font entry was purged for re-enumeration it had to be loaded all over again, which usually happened when the browser was hunting for a font with a particular character. This process used to take about fifteen to twenty seconds for the 700+ font faces on my G5. With the global font cache it now takes less than two.

Speaking of showstoppers, here's an interesting one which I'll note here for posterity. nsChildView, the underlying system view which connects Cocoa/Carbon to Gecko, implements the NSTextInput protocol which allows it to accept Unicode input without (as much) mucking about with the Carbon Text Services Manager (Firefox also implements NSTextInputClient, which is the new superset protocol, but this doesn't exist in 10.4). To accept Unicode input, under the hood the operating system actually manipulates a special undocumented TSM input context called, surprisingly, NSTSMInputContext (both this and the undocumented NSInputContext became the documented NSTextInputContext in 10.6), and it gets this object from a previously undocumented method on NSView called (surprise again) inputContext. Well, turns out if you override this method you can potentially cause all sorts of problems, and Mozilla had done just that to handle complex text input for plugins. Under the 10.4 SDK, however, their code ended up returning a null input context and Unicode input didn't work, so since we don't support plugins anyhow the solution was just to remove it completely ... which took several days more to figure out. The moral of the story is, if you have an NSView that is not responding to setMarkedText or other text input protocol methods, make sure you haven't overridden inputContext or screwed it up somehow.

I also did some trivial tuning to the libffi glue library to improve the speed of its calls and force it to obey our compiler settings (there was a moment of panic when the 7450 build did not start on the test machines because dyld said XUL was a 970 binary -- libffi had seen it was being built on a G5 and "helpfully" compiled it for that target), backed out some portions of browser chrome that were converted to CoreUI (not supported on 10.4), and patched out the new tab tile page entirely; all new tabs are now blank, like they used to be in previous versions of Firefox and as intended by God Himself. There are also the usual cross-platform HTML5 and CSS improvements you get when we leap from ESR to ESR like this, and graphics are now composited off-main-thread to improve display performance on multiprocessor systems.

That concludes most of the back office stuff. What about user facing improvements? Well, besides the new blank tabs "feature," we have built-in PDF viewing as promised (I think you'll find this more useful to preview documents and load them into a quicker viewer to actually read them, but it's still very convenient) and Reader View as the biggest changes. Reader View, when the browser believes it can attempt it, appears in the address bar as a little book icon. Click on it and the page will render in a simplified view like you would get from a tool such as Readability, cutting out much of the extraneous formatting. This is a real godsend on slower computers, lemme tell ya! Click the icon again to go back. Certain pages don't work with this, but many will. I have also dragged forward my MP3 decoder support, but see below first, and we have prospectively landed Mozilla bug 1151345 to fix an issue with the application menu (modified for the 10.4 SDK).

You will also note the new, in-content preferences (i.e., preferences appears in a browser tab now instead of a window, a la, natch, Chrome), and that the default search engine is now Yahoo!. I have not made this default to anything else since we can still do our part this way to support MoCo (but you can change it from the preferences, of course).

I am not aware of any remaining showstopper bugs, so therefore I'm going ahead with the beta. However, there are some known issues ("bugs" or "features" mayhaps?) which are not critical. None of these will hold up final release currently, but for your information, here they are:

  • If you turn on the title bar, private browsing windows have the traffic light buttons in the wrong position. They work; they just look weird. This is somewhat different than issue 247 and probably has a separate, though possibly related, underlying cause. Since this is purely cosmetic and does not occur in the browser's default configuration, we can ship with this bug present but I'll still try to fix it since it's fugly (plus, I personally usually have the title bar on).

  • MP3 support is still not enabled by default because seeking within a track (except to the beginning) does not work yet. This is the last thing to do to get this support off the ground. If you want to play with it in its current state, however, set tenfourfox.mp3.enabled to true (you will need to create this pref). If I don't get this done by 38.0.2, the pref will stay off until I do, but the rest of it is working already and I have a good idea how to get this last piece functional.

  • I'm not sure whether to call this a bug or a feature, but scaling now uses a quick and dirty algorithm for many images and some non-.ico favicons apparently because we don't have Skia support. It's definitely lower quality, but it has a lot less latency. Images displayed by themselves still use the high-quality built-in scaler which is not really amenable to the other uses that I can tell. Your call on which is better, though I'm not sure I know how to go back the old method or if it's even possible anymore.

  • To reduce memory pressure, 31 had closed tab and window undos substantially reduced. I have not done that yet for 38 -- near as I can determine, the more efficient memory management means it is no longer worth it, so we're back to the default 10 and 3. See what you think.

Builders: take note that you will need to install a modified strip ("strip7") if you intend to make release binaries due to what is apparently a code generation bug in gcc 4.6. If you want to use a different (later) compiler, you should remove the single changeset with the gcc 4.6 compatibility shims -- in the current changeset pack it's numbered 260681, but this number increments in later versions. See our new HowToBuildRightNow38 for the gory details and where to get strip7.

Localizers: strings are frozen, so start your language pack engines one more time in issue 42. We'd like to get the same language set for 38 that we had for 31, and your help makes it possible. Thank you!

As I mentioned before, it's probably 70-30 against there being a source parity version after 38ESR because of the looming threat of Electrolysis, which will not work as-is on 10.4 and is not likely to perform well or even correctly on our older systems. (If Firefox 45, the next scheduled ESR, still allows single process operation then there's a better chance. We still need to get a new toolchain up and a few other things, though, so it won't be a trivial undertaking.) But I'm pleased with 38 so far and if we must go it means we go out on a high note, and nothing says we can't keep improving the browser ourselves separate from Mozilla after we split apart (feature parity). Remember, that's exactly what Classilla does, except that we're much more advanced than Classilla will ever be, and in fact Pale Moon recently announced they're doing the same thing. So if 38 turns out to be our swan song as a full-blooded Mozilla tier 3 port, that doesn't mean it's the end of TenFourFox as a browser. I promise! Meanwhile, let's celebrate another year of updates! PowerPC forever!

Finally, looking around the Power Mac enthusiast world, it appears that SeaMonkeyPPC has breathed its last -- there have been no updates in over a year. We will pour one out for them. On the other hand, Leopard Webkit continues with regular updates from Tobias, and our friendly builder in the land of the Rising Sun has been keeping up with Tenfourbird. We have the utmost confidence that there will be a Tenfourbird 38 in your hands soon as well.

Some new toys to play with are next up in a couple days.


  1. All of this if for 7450 with my Powerbook G4 1.33 GHz.

    Google V8 (v7) in TFF 31: 209
    Google V8 (v7) in TFF 38: 2039
    This is reflected very nicely in the snappiness of the user interface, also on sites like Tumblr and Twitter, and in pdf.js. Thank you :-)

    Two issues:

    I see problems with dynamic page loading on Facebook. The Facebook timeline doesn't load completely in many cases (missing elements), and then doesn't start loading additional stuff when I scroll down. If I set javascript.options.baselinejit to false, the site behaves correctly. (This also happens with fresh profile, also on G3).

    When quitting the browser, shortly after hitting cmd+Q, RAM usage (which otherwise is moderate) sometimes goes up to 1.4 GB or more. Then the system will start to page out, prolonging exit time.

    I'll have a look at localizations this weekend.

    1. I don't/won't use Facebook, so I can't really confirm this. Does this happen on other sites which can be rectified in the same way? (Disabling Baseline will hurt Ion performance since it uses it for type inference, so it's definitely not a general solution. Interesting that it's Baseline-specific, though.)

      I haven't observed the RAM spike with quitting on any of my systems, but they all run 10.4. Maybe it's a 10.5 issue.

    2. I've looked into this more closely. If I set *either* javascript.options.baselinejit *or* javascript.options.ion to false (or both), Facebook works completely as it should (but slowly). If both are set to true, they don't seem to work together well on Facebook. I haven't found another site with the same issue yet. I see this on both my PowerBook G3 (10.4) and the G4 (10.5).

    3. Interesting. If someone with a G5 can try, does Facebook do the same thing for them? If the G5 doesn't do it, that narrows down the field substantially.

    4. You don't need a FB accout to test this. The Help Center page has the same problem.
      The search box "How can we help?" doesn't even load most of the time. Hit reload a few times to see what I mean. Then disable the baseline jit and try again.

    5. I can confirm it, but it even happens on the G5. This means there's a bug here the test suite isn't covering and Facebook's JavaScript suite is way too big for me to minimize. I need a smaller site that exhibits a similar problem to debug this with.

    6. Can you explain "javascript.options.baselinejit *or* javascript.options.ion to false" for the non programmers ?
      (how to enable, and any drawbacks).

      I have just started using the (wonderful) Powerbook G4 and - apart from Facebook - T4F 38 is good enough.

    7. The JavaScript JIT in 38 is two-stage. Both compile JavaScript to PowerPC machine code, but the Baseline compiler is designed to do so very quickly. The code it generates, however, is comparatively poor because it is not optimized (the browser does not have enough information to make assumptions about the code it generates). Baseline runs for awhile, takes notes on the code path, and then calls Ion with the likely code path to make an optimized version. Ion generates the code that runs most of the time, which is optimized for the code path it believes most likely to run based on what Baseline discovered. If a violation of those assumptions occurs, Ion bails out back to Baseline to get more information. This jumping back and forth occurs transparently. Chris' report implies the jumping back and forth is what is going wrong here.

      If you disable Baseline, Ion will spend a lot of time generating code that may immediately violate its internal assumptions. Sometimes it will guess right, but much of the time it will guess wrong, and do much unnecessary work.

      If you disable Ion, Baseline will always generate "correct" code but it will be much less well-performing, essentially rolling you back to 31 (but about 20-25% worse because 38 is tuned with the expectation Ion will run most of the time).

      Neither of these are good options. If you can't live without Facebook and you are new to TenFourFox, I recommend you use 31.8.0 until this is figured out. If you want to help, what would help me most is finding a *different* site that is fixed in the same way, because Facebook is too large for me to debug.

    8. THANKS a lot, very good answer. I will see if I find another site with the same problem, for the moment I appreciate the fact that Airbnb now is ok (was not usable with 31)

    9. hello,
      thanks a lot for this great work.

      As Chris, I have sometimes the same problem with the RAM when I leave. (PowerMac G4 OS X 10.4.11)

      Enclosed an extract from firefox.crash.log:
      "Command: firefox
      Path: /Applications/
      Parent: WindowServer [64]

      Version: 38.0.1 (3815.6.27)

      PID: 2242
      Thread: 0

      Exception: EXC_BAD_ACCESS (0x0001)
      Codes: KERN_INVALID_ADDRESS (0x0001) at 0xafffffe0

      Thread 0 Crashed:
      0 XUL 0x0503afc4 mozilla_dump_image + 6100
      1 XUL 0x050337a4 std::vector, std::allocator > >, std::allocator, std::allocator > > > >::reserve(unsigned long) + 344516
      2 XUL 0x04ffddf8 std::vector, std::allocator > >, std::allocator, std::allocator > > > >::reserve(unsigned long) + 124952
      3 XUL 0x04ffde28 std::vector, std::allocator > >, std::allocator, std::allocator > > > >::reserve(unsigned long) + 125000
      4 XUL 0x05032970 std::vector, std::allocator > >, std::allocator, std::allocator > > > >::reserve(unsigned long) + 344516
      506 XUL 0x04ffddf8 std::vector, std::allocator > >, std::allocator, std::allocator > > > >::reserve(unsigned long) + 124952
      507 XUL 0x04ffde28 std::vector, std::allocator > >, std::allocator, std::allocator > > > >::reserve(unsigned long) + 125000".

      I just finished the French translation, where can I send it?

      Best regards

    10. For the French translation, see issue 42 on the Google Code site.

      I can't reproduce the RAM spike on any of my systems still. The dump you produced is a null pointer response which says the system exhausted memory, and crashed. Under the circumstances that is probably not too surprising.

  2. A bit longer latency, but much faster once pages have loaded - GREAT work!

    This is the first time I have been able to get Hotmail to empty the trash in 2 years (I normally, have to select all on each page and delete).

    The only glitch so far is that Facebook video do nothing when clicked-on (even html5).

    A quick question on off-mainthread. How does it determine whether to use it or not? Is it only on launch, or does it check every so often, and what about on DP systems, where one processor is switched off (in C.H.U.D)?

    My machine runs in SP mode most all the time, accept for certain apps, where I have a stay-open script that switches over to DP when needed and then back when not (keeping heat/fan-noise down).

    1. Off-thread compilation is always enabled, even on a single CPU, since bug 941827. The OS is responsible for scheduling it like any other thread (Firefox is fairly pervasively multithreaded nowadays).

    2. (and if you mean off-thread compositing, same thing)

  3. BTW - did you get the right-click video player module code I sent the support group? Might be a great permanent solution to the video playback issue (and since it doesn't download, NO TERMINAL WINDOWS!!!!!)

    I just tried youtube and the webM isn't bad at 360p on my MDD-DP, but a quick-click and it was running flawless 720p of the same video.

    Just sayin' ;0)

    1. I see a "PS" post from you, but nothing else. It's possible their malware detector ate it.

    2. No worries, if you want it, I have a shortened 'play only' version of the PPCMC app that you could set as a "right-click" item, that could enable any youtube-dl supported video to be handed off to QuickTime. No Terminal, just the Quality selector and its onto play. Verified it still works in this form with all the same sites (Vimeo, Dailymotion, Youtube, and nearly 100 others) and even the multi-segmented videos like Comedy Central. There are only a few of issues to sort out:

      1) To use it, the right-click would simply need to copy the link to the clipboard. The app automatically runs from there. If it detects that the copied text does not contain "http", it simply exits.

      2) The users - to have much chance of success really need Perian. Graham Booker and his group have been great about allowing me to bundle it in my installer, the would certainly allow you too as well (could just set up a test that checks if it is installed or not).

      3) You had been worried about the insecure form of curl that youtube-dl used to intall, but the easy work-around is just to bundle it and have a first-run of TFF copy/chmod it to /usr/local/bin and then update it (that is how my new installer does it - their license fully allows this). The script itself auto-updates from there, by checking a dummy file with the date in its title, and on first run each day deletes/recreates the folder and checks for updates (that way Githubs servers don't get bogged down).

      4) PYTHON - this is the big one. While youtube-dl states it is cool with 2.6, there are a lot of bugs in that version with the script. You might be able to bundle just the executable of 2.7.8 inside TFF and then call it explicitly from the app (this way, it wouldn't even conflict with Macports/Homebrew, and it isn't very big by itself.

      Anyway, let me know if you want the code to check it out. It is very efficient and the youtube-dl people are RELENTLESS at maintaining compatibility.

    3. Please don't take this badly, but there is absolutely no way I will bundle Python inside of TenFourFox. We're already a 135MB application. I don't mind writing an optional enabler for your script a la the old MacTubes Enabler (it passes URLs through Launch Services), but these prerequisites really need to be encapsulated in your binary package, since it's the script you provide that depends on them. I don't see why your script couldn't reference them inside the app package instead of requiring the user to install them to his or her system -- I agree that's preferable, but it should not be mandatory.

    4. I totally understand, as it would add about 5MB. As for me offering this up, from this end, there is no point, as there are, according to ppcluddite, and the other mirrors hosting this 1300+ who have already installed the full thing, but as a simple, self-maintaining framework, it seemed like an easy thing to incorporate into TFF.

      Perhaps a bit of granularity in this might be better anyway. In practice, I usually use TenFourKit or OmniWeb to find the videos watched in the player, because of TFF's higher resource requirements, and after trying it out today, it seems a fair bit heavier on my G4 (though this is certainly welcome, it can now do the the more critical/mundane tasks better that we all need a browser for, when it matters).

      So perhaps it is best not to have everything under one roof.

      Great work none-the less! The browser is much more responsive to JS intensive tasks than before.

  4. But it's perfect as it is!

    The Classilla easter egg changes regularly, mostly because OS 9 has so much more fertile ground to roast the modern Apple over.

  5. TFF 38.0.1b1 feels more snappy to me in general than 31.7.0. The improvement in pdf.js is very noticeable and appreciated!

    The following message is displayed when I attempt to connect to the web-based GUI for a specific piece of Nexsan storage hardware, but I believe this is a Firefox, not TenFourFox, issue:

    Secure Connection Failed
    An error occurred during a connection to security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

    I'm also having an issue with password saving for the FireFTP add-on. FireFTP works fine with TFF 31.8.0. I'm mostly using FireFTP for FTPS connections to I updated FireFTP to version after starting TenFourFox 38.0.1b1, but am unable to connect to my Box account. FireFTP logs the following messages, which I don't believe are out of the ordinary:

    220 Service ready for new user.
    234 Command AUTH okay; starting TLS connection.
    PBSZ 0

    I checked the password manager and noticed that the previously stored passwords are no longer listed. I tried starting with a fresh Firefox profile, installing FireFTP, then configuring an account. I'm asked for the security device password when I attempt to save the account info, but the password manager doesn't seem to want to store the password.

    For what it's worth, FireFTP works fine for connections to when used with Firefox 38.0.5. Maybe this is a Firefox issue that was resolved between 38.0.1 and 38.0.5, but I don't see anything pertinent in the release notes.

  6. and also use dynamic page loading that works just fine.

  7. TFF 38.0.1b1 feels significantly more snappy to me than 31.x.0. The improvement in pdf.js is quite noticeable and much appreciated! Thanks for your efforts, Cameron.

  8. Trying again, this time in the correct location: I encountered a problem with 104fx 38.0.1b1. This problem is not present in 104fx 31.4. When trying to get a webpage that requires authentication the authentication dialog shows up, but authentication is never successfull. I actually managed to get my account locked out temporarily, which implies the user name gets across right but the password does not. The specific case is a Sharepoint page. This is on Mac OS X 10.5.8 PPC dual G5.

    1. I'm sorry to hear that, but for obvious reasons I won't be able to fix that since I don't have (nor do I want) a password to that system. Hopefully it gets repaired as part of other fixes.

  9. Essentially this is a buggy server that Firefox 37+ no longer overlooks by default. You can override it with these steps (I just tested it):

  10. I uploaded a test installerr for the German localization.

    Some bugs in 38 (general, not related to localization):

    - The password manager works when browsing, but Preferences>Security>Saved Passwords… is empty.

    - Occasionally crashes on exit, especially when the brwoser has been used for a while, always with
    0 XUL 0x0460ef00 NS_UnregisterXPCOMExitRoutine + XXXXX

    - Facebook JS bug: I haven't found another site yet that suffers form the same bug, unfortunately.


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