Mozilla continues to work on further improvements for its flagship product: the free and open source browser, Firefox. Its many features include enabling the simultaneous browsing of multiple pages with its tab system, supporting most existing web standards, and offering a personalized experience with extensions, plugins, and themes created. Download Firefox and then open the disk image. Drag the Firefox application onto your desktop or some other location so that you can modify it. Step 2: Remove quarantine set by macOS. Before you modify any files in the Firefox application, you must remove the quarantine that macOS sets by default for applications downloaded from the Internet. Starting with Firefox version 49, Firefox requires Mac OS X 10.9 (Mavericks) or higher. Visit this Apple Support page to find your Mac OS version. Deploying Firefox on MacOS using PKG and Jamf This article is for IT Admins who want to configure Firefox on their organization's computers. Download the macOS.pkg for the release version and language you want to deploy. Gather in this interactive, online, multi-dimensional social space. Firefox Developer Edition. Get the Firefox browser built just for developers. Check out the home for web developer resources. Firefox Reality. Explore the web with the Firefox browser for virtual reality.

1. Download Free Mozilla Firefox Setup
2. Customizing Firefox On MacOS Using Configuration .. - Mozilla
3. Mozilla Firefox Mac 10.7.5
4. Mozilla Firefox Mac Os

For several years, Firefox support for the VoiceOver accessibility technology on MacOS was mostly non-existent. In 2020, the team is finally changing that. Here is some insight into what’s happening.

The kick-off

In late 2019, the accessibility team at Mozilla resourced work on improving MacOS accessibility support over the course of 2020. In January, several members gathered in Berlin during an all-hands to scope out the work. There was a lot of old, mostly dysfunctional, code lying around that needs to be modernized and brought up to today’s standards. We agreed to tackle the problem in two stages.

Two stages to success

The first stage, due by the end of June, aims to implement basic VoiceOver support. For the most part, this means correcting and completing specific properties for various HTML elements and widgets. This is to give VoiceOver and other accessibility features correct information about what is happening inside our web area.

The aim of this first stage is to give web developers the chance to test their web sites with VoiceOver. The output should be good enough so they can feel confident that users visiting their offerings with assistive technology will get an accessible experience.

In the second stage, which we plan to complete by the end of the year, the goal is to improve the user experience for visually impaired VoiceOver users. This encompasses performance, text editing, live region support, and rotor item support. It will also include other bits that might turn out missing as more users start testing what we have.

What we have so far

Firefox 75

Firefox 75, released in April, saw the first fruits of this work. Most notably, we learned our way around the Mac code base and the accessibility APIs. In the process we uncovered a small, but significant, piece we were missing that made us very fast all of a sudden. This small, but mighty, patch, enabled us to progress much more rapidly than we had expected. We also made the VoiceOver cursor visible, and made it follow focus. Also, if navigating with VoiceOver, we made focus follow it if VoiceOver’s setting for that was enabled. And, we also fixed some initial labeling inconsistencies across the board.

Morgan and Eitan also developed some testing and benchmarking utilities. These allowed them to compare the accessibility property output between Safari and Firefox. It also gave us some first measures of performance. And let’s just say, the numbers weren’t bad at all!

Firefox 76

Loaded with confidence, the team started into the Firefox 76 development cycle. They quickly made much more progress with various elements, events, and properties. But most importantly, they developed a testing framework. This framework allows us to automatically test the attributes on the Mac platform for correctness. So for each element, we can query things such as the AXRole, AXSubRole, and other items that VoiceOver might ask for. If anything breaks, we now get immediate notification from our continuous integration cluster. Firefox 76 saw a total of 28 bug fixes, many of which contained more than one patch. Firefox 76 was released in May. If you are a Mac user, you can turn on VoiceOver and try out what we have so far.

Firefox 77 and beyond

In Firefox 77, which is in beta at the time this is written, work continued on more testing coverage. The team also added more correctness for elements and modernization of the Mac specific accessibility code. This helps us to comply with current standards on the MacOS platform.

At the time of this writing, we are in the Firefox 78 development cycle. So far, we have already tackled some more complex widgets. Also, we now have a much better understanding of how the Mac accessibility framework works. We will therefore spend some time refactoring the code to streamline how we do things internally to make it more future-proof. Thankfully, our test coverage is so good by now that the team feels confident to do the refactor. Any breakage will get flagged immediately.

The final piece for the first phase will be the Firefox 79 cycle, which will happen in June. What we will work on depends largely on how well this 78 cycle is going. We are using some collections of accessibility samples, such as a11ysupport.io, to manually test how well we’re doing and where we still have gaps.

Phase 2: VoiceOver excellence

And then, we will start with phase 2, which will be all about making Firefox on MacOS fit for use by heavy VoiceOver users, such as visually impaired users. This will offer them another choice of an accessible browser on the Mac giving them all the features that they might already know from Firefox on Windows or Linux. We aim to enable full text editing support and live regions. By the end of this project, the rotor (VoiceOver Modifier+U) will no longer come up empty. Consequently, the rotor gestures and quick navigation will work as you’d expect.

We’ll need your help

At some point later in this project, we will want your help in finding and fixing edge cases or user scenarios we didn’t anticipate. Right now, we are still very much aware that the support has gaps, and we’re working furiously on closing them. But as our Mac accessibility support matures, it will become important that you, who might have a Mac and be a VoiceOver user, try out what we have and give us feedback. We can test a lot of things, but we cannot test everything. We want to hear from you what you think, what bugs you might encounter, or what paper cuts make your lives difficult with Firefox on the Mac.

When the time comes, we will publish a call to action on this blog and in our Discourse forum. Until then, feel free to follow along our detailed progress. Links to all the open and fixed bugs are on our dedicated project wiki page. And if you’re curious and not afraid of cutting edge technology, by all means try it out for yourself. The first improvements are in either Nightly or Beta, or even on the current release.

Are you excited? We certainly are! And we always welcome your thoughts and comments.

The release of Apple Silicon-based Macs at the end of last year generated a flurry of news coverage and some surprises at the machine’s performance. This post details some background information on the experience of porting Firefox to run natively on these CPUs.

We’ll start with some background on the Mac transition and give an overview of Firefox internals that needed to know about the new architecture, before moving on to the concept of Universal Binaries.

Download Free Mozilla Firefox Setup

We’ll then explain how DRM/EME works on the new platform, talk about our experience with macOS Big Sur, and discuss various updater problems we had to deal with. We’ll conclude with the release and an overview of various other improvements that are in the pipeline.

Apple Silicon Approaching

Speculation that Apple would switch its Mac lineup to use ARM CPUs had been ongoing in the industry for several years. As early as 2013, Apple had referred to the custom ARM chips they were putting in the iPhone as “desktop-class” designs.

While the claim initially met some scepticism, near the end of 2018 computer hardware magazine AnandTech published the results of running the industry-standard SPEC benchmark on the iPhone XS, showing that even workloads that reflect real-world desktop use cases reached desktop chip performance, and were doing so at significantly better power efficiency. This provided us with some warning that Apple might be ready to start the transition to the ARM architecture in the near future.

From the perspective of Mozillla’s platform team, an area of particular interest for such an architecture change on macOS is Firefox’s use of macOS APIs. Firefox and Gecko’s roots go back to the Netscape codebase, which already supported the Mac as it was in 1994.

Although continuously updated, Firefox still uses a wide range of macOS APIs that followed the Mac’s evolution over the years (Carbon, Cocoa, HITheme, Quartz, …).

Apple has generally kept them — the code is there and working, after all — and has even added compatibility shims in some places where behavior has changed. But they’re not willing to keep compatibility forever, and in fact had removed 32-bit support in the previous macOS Catalina which had an impact on applications that were relying on this, among them many games.

As such, we were concerned that not all APIs would still be supported on the new architecture and we’d have to go in and rewrite some amount of widget, toolkit or theming code in short order.

Based on the performance from the aforementioned benchmarks and Apple’s historical release schedule, the platform team estimated in March that “macOS 10.16” was likely to appear around September or October 2020 and that there was a significant risk it could involve API changes in order to add ARM support, which we took into account in our planning.

The Announcement

On the 22nd of June 2020, Apple confirmed it would begin moving its Mac hardware to their own ARM chips – referred to as Apple Silicon. They also confirmed that the machines would ship with an Intel x64 emulator (Rosetta 2) and would support iOS apps.

The latter led to some guessing within Mozilla’s platform team as to whether the new Macs would have a touchscreen. While we were — and still are — quite ready to support it, at least the eventual first Apple Silicon-based Macs didn’t end up having one.

Together with the announcement of the transition, Apple also announced the availability of Developer Transition Kits (DTK), essentially containing the iPad Pro’s chip in a Mac Mini housing. What Apple didn’t share was when exactly the final machines were coming to market.

Based on the timing of the DTK availability and Apple’s hint that it would be “by the end of the year”, we guessed this was likely to be somewhat before the Christmas holidays.

Looking back, we noticed that Apple has very consistently been able to make hardware available near immediately after announcing it, so we figured that any next planned announcement should be taken as a release date.

When another announcement was planned for November 10th – about a month before our original estimate – we took it as the shipping date. And indeed, Apple did end up shipping the first hardware one week later on November 17th.

First Steps

Of all the work needed to support the new hardware, porting Firefox to the 64-bit ARM architecture was not actually something we needed to do: we’ve supported 64-bit ARM on Android and Linux for years.

We refrained from publishing the 64-bit Android builds until late 2019 because before that point our JavaScript JIT was not fully optimized for 64-bit ARM, and the resulting 64-bit version would have been slower than the 32-bit one. There wasn’t much demand for the browser to be able to use over 4GB of memory on phones either! In 2019, we released the first Firefox version for Windows on 64 bit ARM which gave us some additional experience in exactly the kind of effort we were facing now.

While Windows on ARM hardware has failed to catch on with our users so far, expectations were for the Apple transition to be very different. Not only was there a good reason to expect hardware performance to be groundbreaking as explained in the first section. Apple made it clear they were switching their entire lineup and not releasing a single device as a “feeler”. To top it off, they had a proven track record of successful architecture transitions on the Mac.

So with 64-bit ARM support already in the codebase, the first pass of work was to go through all the Firefox code, dependencies, and various third-party build systems to see if they correctly dealt with the novel idea that a Mac could have an ARM chip inside.

Secondly, we needed to adapt and fix the various parts of the Firefox codebase that deal with low-level calling conventions and particularly the interfaces between the JavaScript and C++ (and nowadays Rust) parts of the code.

Rust in particular was a concern. Firefox depends on Rust code, and we require a working Rust compiler to build the browser. Although Apple Silicon support for Rust was underway, it took until mid-August for there to be functional compiler builds, which limited the amount of progress possible for Firefox.

Once the compiler was working, a similar exercise needed to be done with all the Rust crates we depend on. The need to update the compiler and the reliance of some crates on the exact compiler version, especially parts dealing with SIMD support, would end up biting us later on as it made it hard to push Apple Silicon support forward to an earlier release of Firefox without potentially affecting other platforms.

Universal Binaries

An important decision to be made was whether to produce separate builds for Intel- and ARM-based Macs, or to generate Universal Binaries which bundle both builds and select the correct version at runtime. Producing Universal Binaries is a bit more complicated, but we had existing tooling in place dating back to the time when Apple supported both 32-bit and 64-bit binaries, which could be adapted.

It greatly simplifies things for the user — there is no risk of downloading the wrong version — and also meant that our download pages and some infrastructure like localization could remain unchanged.

The main downside is the installer significantly increasing in size, not just for ARM users but also for Intel ones. As this only affects the initial install, and users typically receive new versions through updates that are much smaller, we felt that this was an acceptable downside and proceeded along this route.

Netflix and DRM

While we can port the open-source parts of Firefox to 64-bit ARM ourselves, Netflix and some other video streaming services such as Hulu, Disney+, or Amazon Prime require their video to be decoded with closed source, proprietary DRM software.

If the user visits such a site, Firefox will automatically download and install such a proprietary EME/CDM module. This presented a problem to us as we would be dependent on those third-party vendors to publish ARM64 versions of those decoders.

We did not manage to get a commitment to a release date for such updates, and even if we did, there was no guarantee that they would be before the unknown release date of the Apple Silicon hardware. As a significant number of our users use the browser to watch video online, this presented a potential showstopper for a native Apple Silicon release.

We ended up leveraging a technique that we are also using for the Windows on ARM version of Firefox. The DRM video decoder already executes in a separate process so we can sandbox the proprietary code from the user’s system.

If we force this decoding process to run under emulation, we would be able to use the existing Intel x64 decoder modules and have them communicate with the main browser that was running natively.

There were a few catches to getting this to work: because the process that loads the Google Widevine DRM module itself depends on some runtime libraries, we needed Intel x64 copies of those as well.

Luckily, due to the Universal Binary containing both versions of Firefox, we were able to pick them up directly from the Application Bundle.

Secondly, Apple did not actually ship their Rosetta 2 emulator preinstalled on the Apple Silicon machines but its installation is triggered when the user tries to run an Intel application.

Happy wheels unblocked games google sites. So while it is very likely in practice that Rosetta is installed on the user’s system, we could not rely on this always being the case. Triggering the installation of Rosetta programmatically works, but some of our colleagues found out the hard way it is not very reliable, so we backed off on doing this in our first release and fell back to referring people that hit the relevant error to a support article.

macOS Big Sur

The macOS Big Sur betas arrived independently of the Apple Silicon hardware and allowed us to get an early look at the compatibility story. To our relief, no APIs we depended on were deprecated and any backwards compatibility problems or missing shims were limited to small cosmetic issues, which we typically managed to fix quickly. Other open-source projects with a similarly old codebase were not as lucky.

Bumping the version numbers from 10.x to 11.0 – somewhat predictably – produced errors both in our code and in external websites relying on UA sniffing, despite Apple’s attempts to mitigate the problem by returning the old version number in apps built with older SDKs.

Update Woes

Pushing the updated Firefox application bundle to users – which was now a Universal Binary supporting both types of Apple hardware, instead of only Intel x64 as before – revealed some further complications.

During an update, after updating the files on disk, Firefox will relaunch the updated version of itself. Any application on Apple Silicon that is running under Intel x64 emulation and launches another process will also cause that process to be launched under emulation.

So when the old Firefox 83 – running under emulation – launches the new Firefox 84 with native support, it would not launch the new native binary but end up forcing it to be run under emulation as well, at least until the application was fully restarted.

While we developed a workaround for this, we didn’t feel it was sufficiently tested by the release date for the marginal benefit it gave and ended up simply adding a release note to cover this case.

More of a concern was user reports that some antivirus software was flagging all our Universal Binaries as malware, and corrupting the Firefox installation the moment the update arrived.

The software was using machine learning techniques and presumably observed that our combined Universal Binaries didn’t quite look like any other legitimate software it had ever seen before.

Attempts to contact the vendor through regular support channels were unsuccessful so we ended up searching LinkedIn and managed to find an engineer working on the core antivirus detection.

They immediately understood the seriousness of the problem and took prompt action to get a fix shipped, thus preventing quite the disaster for the users of this product. It’s notable that without this last-ditch effort we would have been effectively blocked from releasing a native Apple Silicon version for an indefinite period.

This wouldn’t be the first time that browser makers are exasperated at the misaligned incentives for anti-virus vendors when anti-virus software and browsers don’t get along.

Release Calls

Comparing the Firefox release schedule with the predicted release date from Apple meant that our Firefox 83 – scheduled for November 17th – aligned with the availability of release hardware.

While it would have been nice to announce native support in the stable version as soon as the first production machines arrived to customers, this would also have meant that it would be completely untested on the real hardware. Whatsapp pocket keygen.

We decided to be conservative here and keep our initial support to the Firefox 84 beta, which was released the same day as Firefox 83, giving both us and our users a window of time to evaluate the stability of the product on the actual Apple Silicon hardware.

Though somewhat disappointed that after being one of the first to announce native support in Nightly we ended up delaying a stable release slightly, the difficulties experienced by other browser vendors with shipping a working version supported our decision. Firefox with native Apple Silicon support went into the wider world when 84 beta rolled into the Firefox 84 release, on December 15th, 2020.

While most benchmarking of Apple Silicon indicated that the performance impact of Rosetta emulation was typically low and that applications could be expected to run at about 70-80% of native performance, we saw much larger gains when testing the native Firefox build, including doubled performance on some key benchmarks and a spectacular 2.5 times faster startup.

One reasonable explanation for this faster startup could be that many parts of Firefox itself are written in the web’s own languages – JavaScript, CSS, and HTML – and thus use a JavaScript JIT for much of its own functionality.

On startup, the JIT has to translate the JavaScript to machine code and while this is typically a very fast operation when running under emulation Rosetta has to then translate this JIT-generated machine code to machine code for another architecture.

Apple introduced a translation cache that likely removes this overhead completely for most applications but it does not work for code that is output by a JIT. With the native build, this second translation is avoided completely and we’re back to having a snappy browser.

Future Support

With the initial release out, there are a number of further improvements that we can and will make to the Apple Silicon version, some of which will already be available in Firefox 85.

First of all, we had to disable WebRender in the initial version because it triggered graphics driver bugs in the first Big Sur releases for Apple Silicon. Now that these have been addressed and we’ve validated WebRender on the final hardware, we have re-enabled it and it will ship in 85.

Customizing Firefox On MacOS Using Configuration .. - Mozilla

Secondly, Firefox currently uses the baseline compiler for WebAssembly on 64-bit ARM. There is a faster optimizing compiler called Cranelift available for testing on Firefox Nightly, and in a few weeks, we expect to finish the 64-bit ARM port of our own optimizing compiler, Ion, which is likely to become the new default.

The Apple Silicon chips are one of the first desktop chips that are a heterogeneous design with distinct performance and efficiency cores. We’re revising much of our core threading and thread pooling architecture to handle the distinction better, improve efficiency, and eventually be able to schedule less performance-critical tasks on the efficiency cores.

Finally, we’re cleaning up and modernizing our usage of legacy macOS drawing APIs, and in some cases, removing our custom drawing code entirely. This is expected to help with some of the outstanding glitches in dark mode support, as the legacy macOS APIs simply don’t support it and the color values must be obtained via newer APIs. It will also remove some of our deprecation worries!

Mozilla Firefox Mac 10.7.5

We hope you enjoyed this inside view of how the Firefox team experienced the Apple Silicon transition and we’re looking forward to pushing the Firefox experience on macOS to even higher levels in the year to come.

Thanks to Mike Hommey and Haik Aftandilian for their substantial input to this post. They also did a lot of the engineering work described here. Further editorial suggestions were provided by Andrew Overholt, Sylvestre Ledru, and Selena Deckelmann.

Mozilla Firefox Mac Os

About Gian-Carlo Pascutto