Important information for users of Mozilla Firefox

 

Overview

On November 14, Mozilla is expected to release a new version of its Firefox web browser. Firefox 57 represents such a significant technical and performance change that it’s going to be known as Firefox Quantum. Mozilla and mainstream reviewers of the beta code agree, the browser is much faster and more memory efficient.

The reason why mainstream users will see such a significant speed increase with Firefox Quantum is that it is switching to a multiprocess methodology. Unfortunately, Mozilla in their switch to multiprocess for Firefox has chosen an accessibility approach in which each call for JAWS to obtain information takes orders of magnitude more time.  We are disappointed that Mozilla has not at this time adopted the highly performant approach that Google took with Chrome to increase security while at the same time allowing screen readers to access information at unparalleled speed without needing to make any changes.

For now, we recommend switching to the Extended Support Release (ESR) of Firefox as work on the accessibility issues continues, because even when you are running assistive technology that supports Firefox Quantum, performance with Firefox will be much worse than you are used to. We’re working with Mozilla to improve the situation and are hopeful of further improvement.

We appreciate that if you’re a Firefox user, it’s software you are likely to use many times every day. We want by way of this post to explain the situation as it currently stands and how we got here, plus what we’re doing about it and steps you can take so that in the short to medium term, you can use Firefox with the same degree of responsiveness you’re used to.

Short-term Work-around

For now, there is a way to avoid upgrading to Firefox Quantum while keeping your browser updated with important security fixes. You can install Firefox ESR (Extended Support Release). The Quantum changes are not scheduled to be rolled out to this release until the second quarter of 2018, by which time we hope the accessibility situation with Firefox Quantum will have improved.

Compatibility

While we cannot recommend Firefox Quantum at this time, we appreciate that some people may be curious and want to experiment with it. Firefox Quantum will not work in any fashion unless you are running the latest versions of JAWS 2018, JAWS 18, ZoomText 11 and MAGic 14. Previous versions of our assistive technology are not compatible with Firefox Quantum.

To ensure Quantum will run at all, please ensure you are running the most current version of the above technologies. Please visit our downloads page for the latest software.

If going current with your assistive technology isn’t possible, the Firefox ESR release discussed above will continue to work at this time with the technology you have. This will not always be the case, so if using Firefox is important to you, you should make plans to bring your technology up-to-date over the next few months.

When it is installed, Firefox Quantum will be able to detect if older assistive technology is running that is not compatible. When this is the case, Firefox Quantum will alert you to this.

Performance

Unfortunately, even if you have an assistive technology product that has been updated to accommodate Mozilla’s new approach, you will notice a serious deterioration in performance. We would go as far as saying that at this point, you would not want to use Firefox Quantum for your daily browsing. Pages will take a long time to load, and navigating pages will be problematic.

The reason for this is that Firefox’s implementation of multiprocess has caused a marked deterioration in the speed of communication between the browser and assistive technology.

As our users who browse with Google Chrome, which has been using multiprocess for some time, can confirm, multiprocess browsers can provide a highly responsive experience comparable with what Firefox users are accustomed to, and it is still our hope that Mozilla might adopt a similar approach.

The problem created by Firefox Quantum is a complex technical one, but we believe all our users are entitled to an explanation, so here’s our best shot. To give you a browsing experience that is the most flexible available, as well as being intuitive and accurate, JAWS behaves a bit like an impatient child on a long car journey. It asks Firefox many questions on a regular basis, including “are we there yet”. In the past, Firefox had no difficulty answering all our questions quickly and patiently, meaning we could always give you up-to-the-second information about what was happening on the web page. For our readers with some technical knowledge, we did this through calls to MSAA and it wasn’t necessary to ration those calls.

Because of Firefox’s suboptimal implementation of multiprocess from an accessibility perspective, it’s as if the driver of the vehicle is tired. Firefox takes much longer to answer the important questions we need to ask it about what’s happening on the page. This manifests itself in a serious degradation of responsiveness that we fully accept is unpleasant.

Resolving the situation

We’re committed to our users being able to use whatever browsing solution works best for them. Ideally, that choice should be made based on feature-set, rather than accessibility considerations.

To that end, we’re attempting to address the performance issues with Firefox Quantum in two respects.

First, we’ll continue to work on minimising the calls we’re making to Firefox, the questions we’re asking if you will, ensuring they’re kept to a bare minimum without impacting on getting you the information you need.

Second, we’ll continue to reach out and work with Mozilla, encouraging them to make refinements to their approach that will improve accessibility over time.

Final thoughts on the future

For those with a technical interest in the future of screen reading, we believe it is important to have discussions about how we can ensure that we’re responding to the changing, more dynamic nature of the web, while never losing sight of giving users the great experience they’ve come to expect from JAWS.

We want to acknowledge Marco Zehe’s thoughtful post “Rethinking Web Accessibility on Windows.”  The approach Marco outlined is functionally what we’ve already done to support Microsoft Edge, because of similar performance issues that would be readily apparent with that browser had we tried to have a virtual buffer. Yet in Edge, we have retained where possible the current document-based paradigm, which works well on most pages and which provides users with a functional, proven, familiar experience.

We may conclude that we need to make that switch for Firefox as well to get performance back up to pre-Quantum levels, but we believe that the virtual buffer offers an opportunity for JAWS to innovate with features like Flexible Web that would be difficult or slow if most information gathering and navigating is left to the browser. Flexible web is a powerful feature, used by our customers to save time and be productive in environments that would otherwise be less efficient. JAWS is about more than accessibility, it’s about efficiency, productivity and the user experience.

Since Chrome has proven that multiprocess, virtual buffers, and screen reader performance can happily coexist, we see advantages to ensuring that virtual buffers continue to operate efficiently.

We will continue to update you via this blog and FSCast regarding the status of Firefox Quantum.

1 Comment

  1. Bim

    Is this all news? I and other JFW users are experiencing extreme power flux using FF56.1. Two examples are:
    1. When a new password is imput, there’s an alert inviting the user to save the password (Ctrl+S. Unfortunately before it gets to the point when the shortcut is announced, the alert has closed and is no longer available. In the meantime, users who try to be clever and use the shortcut immediately on hearing the first of many many repeated instruction blocks: “Do you want Firefox to save your …”, well, that’s worse. Total freeze; no Jaws output, no access to keyboard; several minutes before the keyboard can be used at all etc.
    2. Similar happens when using CtrlD to save page to bookmark. It freezes.
    Apart from the 2 people who’ve reported suffering the same symptoms, has this been reported before?

    Bim

Comments are closed.