Firefox 52 Adds WebAssembly

Subject: General Tech | March 8, 2017 - 04:00 PM |
Tagged: mozilla, webassembly, javascript, firefox

Mozilla’s latest browser version, Firefox 52, was just released to the public on Tuesday. I wasn’t planning on putting up a post about it, but I just found out that it includes the ability to ingest applications written in WebAssembly. This is client-side language for browsers to be a compile target for C, C++, and other human-facing languages (such as Rust). Previously, these applications needed to transpile into JavaScript, which has several limitations.

Honestly, I haven’t heard much from WebAssembly in several months, so I was figured they were still quite a ways off. Several big engines, like Unreal Engine 4, not really putting their weight behind HTML5 as much as they were about three years ago, during the Windows 8- and iOS-era. Now I see the above video, which starts with Tim Sweeney and goes on to include others from Mozilla, Autodesk, and Unity, and I am starting to assume that I just wasn’t looking in the right areas.

Some features of WebAssembly include native 64-bit integer types and actual memory management. In JavaScript, the "number" type basically exists in a quazi-state between int32 and FP64. WebGL added a few containers for smaller data types, but it couldn't go larger than what "number" allowed, so int64 and uint64 couldn't be represented. Also, JavaScript requires garbage collection to be run on the browser's schedule, which limits the developer's control to "don't generate garbage and hope the GC keeps sleeping".

According to the video, though, it sounds like application startup time is the primary reason for shipping WebAssembly. That could just be what they feel the consumer-facing message should convey, though. I should probably poke around and see what some web and game developer contacts think about WebAssembly.

Firefox 52 is now available.

Source: Mozilla

Mozilla to Require Rust (and Dependencies) for Firefox

Subject: General Tech | February 7, 2017 - 02:47 AM |
Tagged: mozilla, firefox, web browser, Rust, llvm

Firefox 52 will be the company’s next Extended Support Release (ESR) branch of their popular web browser. After this release, Mozilla is planning a few changes that will break compatibility, especially if you’re building the browser from source. If you’re an end-user, the major one to look out for is Mozilla disabling NPAPI-based plugins (except Flash) unless you are using Firefox 52 ESR. This change will land in the consumer version of Firefox 52, though. It’s not really clear why they didn’t just wait until Firefox 53, rather than add a soft-kill in Firefox 52 and hard-code it the next version, but that’s their decision. It really does not affect me in the slightest.

mozilla-rust.png

The more interesting change, however, is that Mozilla will begin requiring Rust (and LLVM) in an upcoming version. I’ve seen multiple sources claim Firefox 53, Firefox 54, and Firefox 55 as possible targets for this, but, at some point around those versions, critical components of the browser will be written in Rust. As more of the browser is migrated to this language, it should be progressively faster and more secure, as this language is designed to enforce memory safety and task concurrency.

Firefox 52 is expected in March.

Firefox 51 and Chrome 56 Launch with WebGL 2.0

Subject: General Tech | January 27, 2017 - 03:55 PM |
Tagged: webgl, webgl2, firefox, chrome, google, mozilla, Opera

After quite a bit of anticipation, both Mozilla and Google have just shipped compatible implementations of WebGL 2. This feature was unlocked to the public in Firefox 51 and Chrome 56 for the desktop, both released this week, while Opera will push it out to desktop and mobile on their next version, Opera 43. Microsoft currently has the API “under consideration” for Edge.

As we’ve highlighted in the past, this new version of the graphics API pushes the platform up to OpenGL ES 3.0, with a few exceptions that are typically made for security reasons. This update allows quite a few new features like off-screen render targets, which is useful for deferred rendering. The shading language is also significantly larger, and can now operate natively on integer types and 3D textures.

WebGL 2.0 does not include compute shaders, however, which is a bit unfortunate. That said, it is (at least last I checked) a highly-requested feature and the browser vendors are interested in providing it.

Mozilla Unveils Quantum Project

Subject: General Tech | October 30, 2016 - 01:09 AM |
Tagged: mozilla, servo, gecko, firefox

One of the big announcements at Mozilla Summit 2013, despite Firefox OS being the focus of the event, was their research (with Samsung) into a new rendering engine, Servo. Rendering HTML5 is horrifically complex, so creating a new rendering engine from scratch is a big “nope!” for basically all organizations. Mozilla saw this as a big potential, because current engines are very difficult to scale to multiple cores, so they went in to this as a no-assumptions experiment.

mozilla-architecture.jpg

At the time, they didn't know whether Servo would be built up into a full rendering engine, or whether it would be picked apart and pulled back into their current engine, Gecko. Mozilla has now unveiled Quantum, and the first sentence of its MozillaWiki entry is “Quantum is not a new web browser.” They go on to say that they will be “building on the Gecko engine as a solid foundation”. So it seems pretty clear that, like they've recently done with their media file parser in Firefox 48.

While this will likely not have the major impact that “boom, new engine” would, in terms of performance, this piece-wise method should be quicker than bulking up Servo. Mozilla expects that big changes will begin to land next year.

Source: Mozilla

About the "Firefox Is Eating Your SSD" Story

Subject: Storage | October 5, 2016 - 07:57 PM |
Tagged: ssd, mozilla, google, firefox, endurance, chrome

A couple of weeks ago, I saw a post pop up on Twitter a few times about Firefox performing excessive writes to SSDs, which total up to 32GBs in a single day. The author attributes it mostly to a fast-updating session restore feature, although cookies were also resource hogs in their findings. In an update, they also tested Google Chrome, which, itself, clocked in over 24GB of writes in a day.

mozilla-2016-donothurt.png

This, of course, seemed weird to me. I would have thought that at least one browser vendor might notice an issue like this. Still, I passed the link to Allyn because he would be much more capable in terms of being able to replicate these results. In our internal chat at the time, he was less skeptical than I was. I've since followed up with him, and he said that his initial results “wasn't nearly as bad as their case”. He'll apparently elaborate on tonight's podcast, and I'll update this post with his findings.

Mozilla Discontinues Firefox OS for All Devices

Subject: General Tech, Mobile | September 29, 2016 - 02:15 AM |
Tagged: mozilla, Firefox OS, firefox

Update: There has been a little confusion. The web browser, Firefox, is still going strong. In fact, they're focusing their engineering efforts more on it, by cutting back on these secondary projects.

Less than a year after their decision to stop developing and selling smartphones through carriers, Mozilla has decided to end all commercial development of Firefox OS. Releases after Firefox OS 2.6 will be handled by third parties, such as Panasonic, should they wish to continue using it for their smart TV platform. Further, source code for the underlying operating system, Boot-to-Gecko (B2G), will be removed from their repository, mozilla-central, so it doesn't hinder development of their other products.

Mozilla_Foundation_201x_logo.png

Obviously, this is quite disappointing from a platform standpoint. Many applications, especially for mobile and similar devices, can be created in Web standards. At this point, we usually get comments about how web browsers shouldn't be app platforms, and that JavaScript is too inefficient. The thing is, Web is about the best, ubiquitous platform we have, and it will only get better with initiatives such as WebAssembly. Also, native applications don't necessarily perform better than Web-based ones, especially if the latter are packaged standalone (versus sharing resources with other tabs in a browser).

Regardless, Mozilla needs to consider their long-term financial stability, and throwing resources at Firefox OS apparently doesn't return enough value for them, both directly and for its impact on society.

Source: Mozilla

Mozilla Launches Firefox 49

Subject: General Tech | September 20, 2016 - 04:51 PM |
Tagged: mozilla, firefox

While it was originally scheduled for last week, some last-minute issues preventing the software non-profit organization from releasing it until today. Also, for some reason, Firefox for Android doesn't want to update from within itself, but triggering an update from the Google Play store works. This might be temporary and/or happens with every Firefox for Android update; I'm new to this platform.

Mozilla_Firefox_logo_2013.png

This version is expected to expand their multi-process support, which separates UI updates from site updates. Typically, Firefox disables the feature with add-ons, because they are given the tools to make decoupling these two spaces... glitchy. Under typical situations, JavaScript and other tasks that run in the page shouldn't affect the browser's interface. You can see how this could be a problem if, for instance, an add-on loops between tasks on both at the same time. As such, Mozilla is pulling access to a few APIs when multi-process is enabled.

With Firefox 49, VentureBeat is reporting that Mozilla is allowing a “small initial set of compatible add-ons” to be enabled alongside multi-process. If you don't have any non-compatible add-ons installed, then you should see Multiprocess Windows enabled in about:support. Otherwise, it will be disabled and you won't see any difference.

Interestingly, Mozilla is promoting "Refresh Firefox" at their site if you have the latest version. This basically cleans all the add-ons out of your user profile, but maintains browsing history, bookmarks, and the like. It might have been around for a while, but, if it's new, it times nicely with the multi-process rollout. On top of cleaning out old, crufty add-ons, a user should see a bigger jump when Mozilla's enhancements are (I'm guessing) enabled.

Mozilla has also changed a few things here and there, too. While many of our readers will probably have hardware acceleration for video, they have just added in SSSE3 enhancements if GPU support isn't available. I'm not sure all of the use cases for this, but I'd expect it would help in virtualized environments and certain, older PCs (ex: Intel Atom and Via Nano). I'm just speculating, though.

Source: Mozilla

Mozilla to Publish First Rust-based Module in Firefox 48

Subject: General Tech | July 16, 2016 - 05:41 PM |
Tagged: mozilla, Rust, firefox

Mozilla has been working on the Rust language for several years now. It is designed to be extremely fast, memory-safe, and easy to parallelize on multi-core processors, doing so by having a compiler that's not afraid to tell you “Nope.” Mozilla (and others, like Samsung) want a language with those characteristics because it will make an extremely fast, yet secure, web browser (although there's a lot of single-threaded design choices tangled in the Web specifications).

mozilla-rust.png

The first example will arrive next month for Windows, though (64-bit OSX and Linux already had it). Firefox 48 will replace a small portion of the code, originally written in C++, with a Rust-based equivalent. The affected component parses media files, getting values like track id, duration, resolution, and so forth. Because it's written in Rust, this ingestion should be resilient to memory-based vulnerabilities.

This probably will not be noticeable to end-users, but it's a few thousand less lines of code that Mozilla should need to worry about hijacking the browser. Mozilla is also planning on bringing URL parsing to Rust, and has already done so with Servo. You would think that the C++ code has been battle-hardened by now, but, I mean, 15-year-old open-source bugs do exist, hiding in plain sight.

Source: Mozilla

Mozilla Will Begin Electrolysis with Firefox 48

Subject: General Tech | June 9, 2016 - 01:08 AM |
Tagged: mozilla, firefox

Electrolysis (e10s) is Mozilla's codename for their multi-process initiative in Firefox. The main goal of this is to separate the content of the website from the user interface. This means that, if a site has long-running JavaScript or layout, Firefox will not lock up. This seems like a simple idea, except that it undoes over a decade of assumptions that were made during Firefox's development. Imagine, for instance, that you have an extensions which modifies both the browser UI as well as the page content -- that's a single script that needs to be run across multiple threads. Whoops!

Mozilla_Firefox_logo_2013.png

This roll-out won't necessarily be immediate, though. You can install Firefox 48 and, only some weeks later, get Electrolysis turned on retroactively. They are starting with about 1% of eligible users, which will ramp up to all eligible users over time or even be disabled if alarm bells start to ring.

Speaking of eligible users, there are quite a few conditions that will prevent you from getting Electrolysis. Namely, if you use extensions (it's unclear if they're talking about all extensions, or just ones that use certain APIs) then you will be kept on single-process. They don't specify why, but it could very well be the situation that I mentioned in the first paragraph.

Firefox 48 is scheduled to be released in six weeks (the first week of August).

WebGL2 Is On Its Way

Subject: General Tech | December 31, 2015 - 10:25 PM |
Tagged: webgl2, webgl, mozilla, firefox

The Khronos Group created WebGL to bring a GPU-accelerated platform to web browsers. With a few minor differences, it is basically JavaScript bindings for OpenGL ES 2.0. It also created a few standards in JavaScript itself to support things like raw buffers of data that could be assigned types in an unmanaged way. Basically every latest-version web browser supports it these days, and we're starting to see it used in interesting ways.

webgl2-2015-particles.jpg

The next step is WebGL2. OpenGL ES 3.0 adds a bunch of new features that are sorely needed for modern games and applications. For instance, it allows drawing to multiple render targets, which is very useful for virtual cameras in video games (although the original WebGL software could access this as an optional extension when supported). The addition of “Uniform Buffer Objects” is a better example. This allows you to store a bunch of data, like view transformation matrices, as a single buffer that can be bound to multiple applications, rather than binding them one at a time to every draw that needs them.

It's hard to describe, but demos speak a thousand words.

The news today is that Mozilla Nightly now ships with WebGL2 enabled by default. It was previously hidden, disabled by default, behind an option in the browser. This doesn't seem like a big deal, but one of the largest hurdles to WebGL2 is how the browsers actually implement it. The shading language in WebGL was simple enough that most browsers convert it to DirectX HLSL on Windows. This is said to have the added advantage of obfuscating the ability to write malicious code, since developers never directly writes what's executed. GLSL in OpenGL ES 3.0 is much more difficult. I'm not sure whether the browsers will begin to trust OpenGL ES 3.0 drivers directly, or if they finally updated the GLSL translator, but supported implementations means that something was fixed.

Unfortunately, OpenGL compute shaders are not supported in WebGL2. That said, the biggest hurdle is, again, to get WebGL2 working at all. From my talks with browser vendors over the last year or so, it sounds like features (including compute shaders) should start flying in easily once this hurdle is cleared. From there, GPGPU in a website should be much more straightforward.