Pick of the Month: Tabliss
by tabliss.io
Enjoy a gorgeous new tab page with customizable background images and many informational widgets to choose from, like local weather, date/time, bookmarks, and more.
“Wow. Absolutely stunning without the need for advanced user input to make it stunning.”
Featured: View Page Archive & Cache
by Armin Sebastian
Find archived and cached versions of older web pages with the help of multiple search engines, like Wayback Machine, Google Cache, Bing Cache, and others.
“Outstanding! Often have to search multiple sites for cached pages. Very useful time-saver for me. Thank you!”
Featured: Share Backported
by Daniele Mte90 Scasciafratte
Older versions of Firefox included a social media ‘share’ button in the Toolbar. This extension brings it back to its original glory.
“Beautifully implemented!”
If you’d like to nominate an extension for featuring, please send it to amo-featured [at] mozilla [dot] org for the board’s consideration. We welcome you to submit your own add-on!
The post June’s Featured Extensions appeared first on Mozilla Add-ons Blog.
https://blog.mozilla.org/addons/2018/06/01/junes-featured-extensions/
This is the SUMO weekly call
https://air.mozilla.org/sumo-firefox-60-post-mortem-and-social-support/
Now that we are back from our Chicago work week, we are heads down adding new features, making improvements and fixing bugs.
Browsers
We are focusing on making general improvements and on the Widgets API across the Android platforms:
-
Improved the widgets API to create all the windows, widgets and placements from Java:
- Create & place all widgets from Java
- Generate ids from Java in order to avoid having to wait the callback with the C++ handler
- Remove the widget creation enumerations
- Consider moving visibility to WidgetPlacement class
- Adapt all widget children to the new API
-
Resolved startup issues in GeckoView fixing, the initial home page experience
Social
This week we spent time prioritizing features and planning for the rest of the year for the Hubs by Mozilla product:
- Added documentation of Hubs A-Frame components in the code and here
- Proof of concept of scrollable list view with react-surface, which will allow full flexbox layout + react enabled UI drawn to webgl canvas in VR
- Concluded planning and requirements doc for environment building kit, editor work kicked off this week
Join our public WebVR Slack #social channel to participate in on the discussion!
Content ecosystem
We are continuing to fix bugs found on the Unity WebVR exporter tool.
Found a critical bug? File it in our public GitHub repo or let us know on the public WebVR Slack #unity channel and as always, join us in our discussion!
Stand by for new features and improvements across our three areas next week!
In our series about organisations which are ‘Open by Design,’ this time we explore how Sage Bionetworks is working to enable and speed up breakthroughs in biomedical research by redefining how complex biological data is gathered, shared and used. This means challenging the traditional relationships between academic researchers, biomedical firms and ‘subjects’ to foster an ethos of data sharing. With a business model that’s dependent on shared resources and collaborative innovation, Sage Bionetworks is fundamentally ‘Open by Design.’
Alex Klepel & Gitte Jonsdatter (CIID)
Founded as a spin-out from Merck in 2009, Sage Bionetworks is a non-profit research organization that seeks to develop predictors of disease and accelerate health research by applying a large and impactful set of open practises. These allow for a global research community to share knowledge, interpret large-scale data, crowdsource hypothesis-tests and foster innovation through community challenges.
Sage relies on cloud technology, web services and consulting services to encourage and facilitate data sharing between biotech companies, researchers and research subjects. The organisation has developed three tools to support their work: Synapse, a cloud solution for sharing research data between organisations and researchers; DREAM Challenges, a crowdsourcing platform where partners can post and answer questions in biology and medicine; and Bridge, a set of web services designed to support research studies conducted via smartphone. Bridge is the engine behind Apple’s Research Kit, which made tech headlines in 2015 with the successful initial results of Sage Bionetworks’ MPower — a project to diagnose and treat Parkinson’s disease using a rich dataset gathered from thousands of iOS users.
Biomedical research is a field with a history of high investment in data-gathering studies, and a reluctance to share. In a field where being first with analysis results means everything, access to datasets is seen as a competitive advantage: products that launch before those of competitors enjoy first-mover market advantages, and for individual researchers, having study results published first improves the chances for receiving tenure and grants. This combination of business and personal career incentives has created a guarded and apprehensive culture around data that recognises only risks tied to sharing, and not the potential rewards in innovation.
Sage Bionetworks is breaking through these systemic disincentives by identifying and communicating multi-sided opportunities, co-evolving collaboration structures that demonstrate value, and tailoring services that reward commitment to working in ways that are open.
There are several layers to this strategy:
Nudging with Tiered Pricing Models: Sage Bionetworks offers platforms to clients to conduct closed or open data projects, but data sharing has associated financial rewards. Consulting services also have varied pricing levels to encourage partners to share datasets.
Setting an Example: With the DREAM Challenges on Synapse they provide a good example and begin to shift traditional mindsets in research by gifting data to the community. The platform also provides an opportunity to reach new researchers by offering a potential reward.
Building Community in Phases: The business development team has been strategic in approaching the community in stages, starting with a few leading thinkers who share the philosophy of the value in open data. At the same time Sage is working at the structural level with the organisations that determine incentives for individual researchers.
These open networks appear to form in waves. First are the people who believe in open, then the scientists and labs that are required to participate by their funders, and then you get the most powerful incentive — fear of missing out.
John Wilbanks, Chief Commons Officer — Sage Bionetworks
A valuable lesson that Sage learned early on was that “open” is not the same as “useful”: for data to be shared, it needed to be made accessible and understandable. (Sage annotated and made available $150 million of Merck research as their first open data set. But over the course of seven years only 15–20 people asked for it.) Thus, supporting consulting services that align research needs with appropriate, discernable data has been essential in realizing the benefits of making the data
Domain Name Service (DNS) is one of the oldest parts of internet architecture, and remains one that has largely been untouched by efforts to make the web safer and more private. On the Firefox network and security teams, we’re working to change that by encrypting DNS queries and by testing a service that keeps DNS providers from collecting and sharing your browsing history.
For more than 30 years, DNS has served as a key mechanism for accessing sites and services on the web. Browsers (including Firefox) use DNS to access a distributed database that turns URLs into TCP/IP addressing information. Firefox cannot do much without the service. DNS hails from the days of a kinder, more gentle Internet where it was normal to make this kind of query using unencrypted protocols and send them to any nearby server who claimed to be able to answer it.
This approach is no longer a fit for the modern Internet. Because there is no encryption, other devices along the way might collect (or even block or change) this data too. DNS lookups are sent to servers that can spy on your website browsing history without either informing you or publishing a policy about what they do with that information.
While sophisticated users can turn to cloud-based “open resolvers” that offer better privacy controls than what is available by default from most internet service providers (ISPs), these resolvers rely on the same old unencrypted protocols so ISPs can often intercept data anyway.
Our first effort to upgrade the privacy of DNS is to implement the DNS over HTTPS (DoH) protocol, which encrypts DNS requests and responses. See Lin Clark’s terrific explainer about how DNS over HTTPS can really improve the state of the art.
DoH support has been added to Firefox 62 to improve the way Firefox interacts with DNS. DoH uses encrypted networking to obtain DNS information from a server that is configured within Firefox. This means that DNS requests sent to the DoH cloud server are encrypted while old style DNS requests are not protected. DoH standardization is currently a work in progress and we hope that soon many DNS servers will secure their communications with it.
Firefox does not yet use DoH by default. See the end of this post for instructions on how you can configure Nightly to use (or not use) any DoH server.
Our second effort focuses on building a default configuration for DoH servers that puts privacy first.
We are running a shield study where some Nightly users will participate in one or more experiments to help us build out a secure, cloud-based service that handles DoH requests. All Nightly users will receive an in-product notification about these studies.
Cloudflare is our partner for these experiments. When a shield study is active, Nightly Firefox will automatically use Cloudflare’s secure DNS over HTTPS service (though we aren’t using the famous 1.1.1.1 address). The first study will test whether DoH’s performance is up to the task.
We’ve chosen Cloudflare because they agreed to a very strong privacy agreement that protects your data. TCP/IP requires sharing the name of a website with a third party in order to connect, regardless of whether you’re using DoH or traditional DNS. We want to be confident your DNS operates with strong privacy preserving terms like those we have established with Cloudflare.
We believe that negotiating a privacy first operating agreement is something that Firefox can do for people that is just impractical to ask them to do for themselves. Imagine calling up your residential ISP and asking them to agree to an audit that demonstrates they do not log your IP address on their DNS server. And then repeating the process for your favorite coffee shop, library, friend’s house — anywhere you and your browser go to connect.
Firefox improves user privacy by default by finding good partners, establishing legal agreements that put privacy first, and eventually shipping a default configuration we believe is best.
Shield studies will come and go. If you would like to see what studies you are currently enrolled in simply load about:studies in the location bar. You can also opt out of studies on that page.
How-To Manually Configure DoH
Do you want to use (or not use) DoH all the
While at Mozilla we want to ensure consistent and high-quality translations, we also want to make sure that contributing is a rewarding and pleasant experience for everyone. Translating in a timely manner is important, however there are other essential things to take into consideration. For example, leaving non-urgent projects with missing strings so that new localizers can get involved is one of them. Reviewing pending suggestions regularly is another – and the main topic of this post.
In the last few months, the l10n-drivers Project Management group (Delphine, Peiying, Flod, Jeff, and Th'eo) has taken a good look at the state of pending suggestions across teams and projects in Pontoon, and has decided to take more direct action in order to ensure that localizers (newcomers and old timers alike) get timely and constructive reviews. In fact, a lack of timely replies – or worst, a total lack of replies – creates an unwelcoming environment and risks losing contributors.
We started reaching out to some teams individually – but given the amount of locales concerned, it seems a broader “call to action” at this moment is a better way to kick things out.
As a first step, we’d like communities that have more than 300 pending suggestions to go through these and take some time to bring that number down. In fact, our goal this year is not only to get a better picture of the health of the localization communities, but also to take action in order to ensure our localization communities are thriving and healthy. This is just one of many steps to get there.
The reality is that when a locale has hundreds or thousands of unreviewed suggestions, and that remain unreviewed for months, it creates an unwelcoming environment for newcomers who could have a high impact on the project with some mentorship. Seeing these high numbers will make new potential localizers think that no one is paying attention, that they will not be able to get involved effectively and that they won’t be able to make an impact. In addition to being unwelcoming, this slowly creates a closed localization community, as the lack of reviews and transparency restrict involvement to only a handful of localizers (or in some cases, one localizer alone).
In the case of teams that have thousands of unreviewed strings, one way that they can start thinking about this is if there are any projects that have become less important, that they are less passionate about, and that they do not want to work on anymore. In this case, they can simply reach out to the Project Manager in charge in order to discuss the situation. The Project Manager can also easily be found on the Pontoon UI under each project page, next to the “Contact Person” field. If still in doubt, simply reach out to the dev-l10n mailing list and we will gladly respond from there.
So, what are our next steps here? Starting in July, we will reach out to teams that still have more than 300 pending suggestions and ask that they bring that number down. In lack of response, or if no action on pending suggestions is taken, we will carefully evaluate which contributors to give more permissions to and assign translator rights to new particularly active localizers. We will also talk with them on how to coordinate the localization activity for the locale.
So this is a call to action for every locale that has pending suggestions: please help us ensure that we all have a great experience in localization at Mozilla, by not only welcoming and onboarding newcomers in your team – but also making sure everyone gets a timely review of their work.
Pontoon documentation explains what a healthy localization workflow can look like, and we invite you to take a look at it here.
https://blog.mozilla.org/l10n/2018/05/31/the-importance-of-reviewing-suggestions/
A few weeks ago, Shruti Singh joined the Test Pilot team for the summer as an Outreachy intern. Read on to learn more about her and what she’ll be working on.
How would you describe your role on the Test Pilot team?
I have been selected as an Outreachy intern and would be working to “Improve sharing & contribution features on Firefox Color for Test Pilot” this summer. I started on 14th May 2018 and am very excited about the project. I will be working under the guidance of my mentor — Les Orchard.
What does a typical day at Mozilla look like for you?
It’s been a few weeks since I started working with Mozilla. A typical day at Mozilla consists of a huge amount of learning and fun. Everyone around is very helpful and friendly. I spend my time learning and implementing new things. The most interesting part is vidyo conferencing and meetings where one can meet awesome people out there and can learn/discuss technologies.
Where were you before the Test Pilot team?
I am a recent graduate student. I completed my undergraduate in computer science and engineering on 4th May 2018.
What’s coming up that you’re excited about?
Apart from doing my project, I am excited for Mozilla All-hands meeting in San Francisco, USA. The All-hands meeting is a gathering, where more than 1100 Mozilla employees and contributors of the Mozilla community come to discuss where Mozilla is heading and our future product. I can’t wait to attend the All-hands next month. :-D
Any fun side projects you’re working on (outside of work)?
During college time, I along with other friends were busy helping small kids of nearby village in learning technical subjects like maths and science. I think education and knowledge is a powerful tool to change one’s life and thought process. I am looking forward to volunteering with kids education in my city (Bangalore) too.
What is something most people at Mozilla don’t know about you?
Apart from sticking all day to my laptop, I also do sketching. It gives me a sense of peace and calm. Some of my recent sketches are:
Welcome Shruti to the Test Pilot team! was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.
Mozilla Science Lab Community Call, May We are planning a community call on May 31 at 11am PST / 2pm EST / 7pm BST /...
https://air.mozilla.org/mozilla-science-lab-may-2018-bi-monthly-community-call/
I’ve surprisingly not written a lot over here about working on a distributed team in a distributed organization. Mozilla is about 60% people who work in MoLos (office workers) and 40% people who don’t (remotees). My team is 50/50: I’m remote near Toronto, one works from his home in Italy, and the other two sit in the Berlin office most days.
If I expand to encompass one extra level of organization, I work with people in Toronto, San Francisco, Poland, Iowa, Illinois, more Berlin, Nova Scotia… well, you get the idea. For the past two and a half years I’ve been working with people from all over the world and I have been learning how that’s different from the rather-more-monocultural experience I had working in offices for the previous 8-10.
So today when I shouted “Not it!” into the IRC channel in response to the dawning realization that someone would have to investigate and take ownership of some test bustage, I followed it up within the minute with a cultural note:
09:35(Actually, that's a cultural thing that may need explanation. As kids, usually at summer sleep-away camp, if there is an undesirable thing that needs to be done by one person in the cabin the last person to say "Not it" is "It" and thus, has to do the undesirable thing.)
“Not it” is cultural. I think. I’ve been able to find surprisingly little about its origins in the usual places. It seems to share some heritage with the game of Tag. It seems to be an evolution of the game “Nose Goes,” but it’s hard to tell exactly where any of it started. Wikipedia can’t find an origin earlier than the 1979 Canadian film “Meatballs” where the nose game was already assumed to be a part of camp life.
Regardless of origin, I can’t assume it’s shared amongst my team. Thus my little note. Lucky for me, they seem to enjoy learning things like this. Even luckier, they enjoy sharing back. For instance, :gfritzsche once said his thumbs were pressed that we’d get something done by week’s end… what?
There were at least two things I didn’t understand about that: the first was what he meant, the second was how one pressed one’s thumbs. I mean, do you put them in your fist and squeeze, or do you press them on the outside of your fist and pretend you’re having a Thumb War (yet another cultural artefact)?
First, it means hoping for good luck. Second, it’s with thumbs inside your fist, not outside. I’m very lucky there’s a similar behaviour and expression that I’m already familiar with (“fingers crossed”). This will not always be the case, and it won’t ever be an even exchange…
All four of my team members speak the language I spoke at home while I was growing up. A lot of my culture is exported by the US via Hollywood, embedding it into the brains of the people with whom I work. I have a huge head-start on understanding and being understood, and I need to remain mindful of it.
Hopefully I’ll be able to catch some of my more egregious references before I need to explain camp songs, cringe-worthy 90s slang, or just how many hours I spent in a minivan with my siblings looking for the letter X on a license plate.
Or, then again, maybe those explanations are just part of being a distributed team?
:chutten
https://chuttenblog.wordpress.com/2018/05/31/distributed-teams-on-the-non-universality-of-not-it/
The web should be open to everyone, a place for unbridled innovation, education, and creative expression. That’s why Firefox fights for Net Neutrality, promotes online privacy rights, and supports open-source … Read more
The post Working for Good: Accel Lifestyle appeared first on The Firefox Frontier.
https://blog.mozilla.org/firefox/working-for-good-accel-lifestyle/
Threats to users’ privacy and security are growing. At Mozilla, we closely track these threats. We believe we have a duty to do everything we can to protect Firefox users and their data.
We’re taking on the companies and organizations that want to secretly collect and sell user data. This is why we added tracking protection and created the Facebook container extension. And you’ll be seeing us do more things to protect our users over the coming months.
Two more protections we’re adding to that list are:
- DNS over HTTPS, a new IETF standards effort that we’ve championed
- Trusted Recursive Resolver, a new secure way to resolve DNS that we’ve partnered with Cloudflare to provide
With these two initiatives, we’re closing data leaks that have been part of the domain name system since it was created 35 years ago. And we’d like your help in testing them. So let’s look at how DNS over HTTPS and Trusted Recursive Resolver protect our users.
But first, let’s look at how web pages move around the Internet.
If you already know how DNS and HTTPS work, you can skip to how DNS over HTTPS helps.
A brief HTTP crash course
When people explain how a browser downloads a web page, they usually explain it this way:
- Your browser makes a GET request to a server.
- The server sends a response, which is a file containing HTML.
This system is called HTTP.
But this diagram is a little oversimplified. Your browser doesn’t talk directly to the server. That’s because they probably aren’t close to each other.
Instead, the server could be thousands of miles away. And there’s likely no direct link between your computer and the server.
So this request needs to get from the browser to that server, and it will go through multiple hands before it gets there. And the same is true for the response coming back from the server.
I think of this like kids passing notes to each other in class. On the outside, the note will say who it’s supposed to go to. The kid who wrote the note will pass it to their neighbor. Then that next kid passes it to one of their neighbors — probably not the eventual recipient, but someone who’s in that direction.
The problem with this is that anyone along the path can open up the note and read it. And there’s no way to know in advance which path the note is going to take, so there’s no telling what kind of people will have access to it.
It could end up in the hands of people who do harmful things…
Like sharing the contents of the note with everyone.
Or changing the response.
To fix these issues, a new, secure version of HTTP was created. This is called HTTPS. With HTTPS, it’s kind of like each message has a lock on it.
Both the browser and the server know the combination to that lock, but no one in between does.
With this, even if the messages go through multiple
The OED’s second definition of “vision” is “the ability to think about or plan the future with imagination or wisdom.” Thus I felt more than a little trepidation when I was tasked with creating a vision for my team. What should this look like? How do I scope it? What should it cover? The Internet was of surprisingly little help; it seems that either no one thinks about tooling and engineering processes at this level, or (perhaps more likely) they keep it a secret when they do. The best article I found was from Microsoft Research in which they studied how tools are adopted at Microsoft, and their conclusion was essentially that they had no overarching strategy.
Around six months later, I presented a Vision for Engineering Workflow at our fortnightly managers' meeting. But first, some context: a bit about Mozilla’s Engineering Workflow team, and about the challenges we face.
Engineering Workflow
The Engineering Workflow team was created in the Great Reorg of 2017, when, amongst other large changes, its predecessor, the Automation & Tools team (aka the A-Team) was split into two, with the part focussed more on test automation joining the newly formed Product Integrity org. The other half remained in the Engineering Operations org, along with a related team, managed by coop, that worked on the build and version-control systems. In February, these two teams were consolidated into a single team, with kmoir joining the team as a new manager while coop headed off to manage the Taskcluster team.
We named this new team “Engineering Workflow” to reflect that it is focussed on the first stages of the Firefox engineering pipeline, that is, tools and processes that most developers use on a day-to-day basis. Our mission is as follows:
The engineering workflow team exists to improve the quality, clarity, and efficiency of Firefox development through the integration and development of tools and automation.
More specifically, the major pieces of the engineering pipeline that we work on are
- Tracking issues
- Reviewing code
- Landing code
- Building Firefox
Just as importantly, there are many related systems that we don’t own. These include
- Tests and test frameworks. As mentioned above, these are the responsibility of the Product Integrity org.
- Release and update infrastructure. This is the domain of release engineering and release management.
- Metrics related to product use. Although we are starting to collect our own metrics, data related to Firefox itself is collected and analyzed by the data and product teams.
- Firefox Developer Experience (aka devtools). I mention this only because they have (or at least had) a similar name. This is the team that works on the developer tools that are shipped as part of Firefox.
- Low-level tools. These tools are very product focussed, requiring intimate knowledge of the Firefox codebase and C++ development. This team is managed by Anthony Jones and is part of the Runtime Engineering group.
- Products not built from mozilla-central. To allow us to focus (I seem to really love that word), we prioritize work to help developers working within the mozilla-central codebase. Many of our tools are also used by other teams (including ourselves!) but support requests from them are considered lower priority.
Of course, we can and do work with many of these other teams on joint ventures. Over time I would like to better coordinate our respective road maps to deliver even more impact to engineering at Mozilla.
Challenges
Mozilla is a unique place. Not only are we a nonprofit that works in the open, but we develop a massive application with contributors, both paid and volunteer, located all around the world. This means we also face unique challenges when it comes to figuring out what tools and automation to integrate, build, and/or improve to maximize impact. I’ll touch on a few here.
Diverse workflows and strong preferences
Tales of “religious wars” within software develop stretch back decades, so it is no surprise that many Mozillians have strong opinions about the way they prefer to work. What is less common is that Mozilla has generally shied away from defining official (or even officially supported) tools and processes. I won’t get into the merits of this approach, but it does impact
Three years ago I talked on a changelog episode about curl just having turned 17 years old and what it has meant for me etc.
Fast forward three years, 146 changelog episodes later and now curl has turned 20 years and I was again invited and joined the lovely hosts of the changelog podcast, Adam and Jerod.
We talked curl of course but we also spent time talking about where HTTP/2 is and how QUIC is coming around and a little about why and how its UDP nature makes things a little different. If you're into either curl or web transport, I hope you'll find it interesting.
https://daniel.haxx.se/blog/2018/05/31/curl-http2-and-quic-on-the-changelog/
the following changes have been pushed to bugzilla.mozilla.org:
- [1462685] Use Phabricators Draft functionality to allow sending of initial revision email after BMO has updated the policies
- [1464226] quicksearch can’t search for “Resolution:—“
- [1464312] Write script to undo the INACTIVE changes on bugs
- [1465225] New changes for draft revisions can miss setting permissions on revisions without a bug id associated
discuss these changes on mozilla.tools.bmo.
https://dlawrence.wordpress.com/2018/05/30/happy-bmo-push-day-43/
MoFo Staff Call May 2018
If you have the task to create automated tests for websites you will most likely make use of Selenium when it comes to testing UI interactions. To execute the tests for the various browsers out there each browser vendor offers a so called driver package which has to be used by Selenium to run each of the commands. In case of Firefox this will be geckodriver.
Within the last months we got a couple of issues reported for geckodriver that Firefox sometimes crashes while the tests are running. This feedback is great, and we always appreciate because it helps us to make Firefox more stable and secure for our users. But to actually being able to fix the crash we would need some more data, which was a bit hard to retrieve in the past.
As first step I worked on the Firefox crash reporter support for geckodriver and we got it enabled in the 0.19.0 release. While this was fine and the crash reporter created minidump files for each of the crashes in the temporarily created user profile for Firefox, this data gets also removed together with the profile once the test has been finished. So copying the data out of the profile was impossible.
As of now I haven’t had the time to improve the user experience here, but I hope to be able to do it soon. The necessary work which already got started will be covered on bug 1433495. Once the patch on that bug has been landed and a new geckodriver version released, the environment variable “MINIDUMP_SAVE_PATH” can be used to specify a target location for the minidump files. Then geckodriver will automatically copy the files to this target folder before the user profile gets removed.
But until that happened a bit of manual work is necessary. Because I had to mention those steps a couple of time and I don’t want to repeat that in the near future again and again, I decided to put up a documentation in how to analyze the crash data, and how to send the data to us. The documentation can be found at:
https://firefox-source-docs.mozilla.org/testing/geckodriver/doc/geckodriver/CrashReports.html
I hope that helps!
Neutrino is my preferred tool to kickstart a React app and Netlify is my preferred SPA deployment service.
Netlify makes it very easy to deploy your static sites, however, it needs some initial configuration.
You won’t find Neutrino as one of the tools listed in their docs, thus, adding some docs in here. We’ll see if my instructions are right and maybe ask them to include them in their docs.
When you create a new site you will connect your repository and you will be asked to fill in the following:
- Branch to deploy: master // Selected by default
- Build command: yarn build
- Publish directory: build // Neutrino’s default
NOTE: I prefer yarn over npm .
In few minutes your site will be up and running. You won’t need to do anything else.
It’s looking increasingly likely that Firefox will, in the not-too-distant future, build with a single C++ compiler across the four major platforms we support. I’m uneasy with this, but I think I’ve made my peace with it, partly as a result of writing the piece below.
Firefox currently builds with three major C++ compilers across four platforms: Microsoft’s Visual C++ compiler (MSVC), GCC, and Clang. A fair amount of work has been done to deal with peculiar bugs in all three compilers: you can go search the source code and/or Bugzilla to find hacks that were needed for one reason or another. A fair amount of work has also been stalled or shelved because one or two compilers don’t quite measure up in some required area (e.g. standards support). As you might imagine, many a Firefox engineer has bemoaned the need for cross-compiler compatibility.
Cross-implementation compatibility is something that Mozilla expends a lot of effort on in a different context. We have a Tech Evangelism bugzilla component for outreach to sites who use techniques that don’t translate across browsers. When new sites appear that deliberately block Firefox (whether because the launch team took the time to test with Firefox and determine the user experience wouldn’t be acceptable, or because cross-browser compatibility was an explicit non-goal), Firefox engineers go find the performance cliffs and fix them. Mozilla has a long-history of promoting the benefits of multiple implementations of the web platform; some of the old guard might remember “Works best in all browsers” campaigns and the like. If you squint properly, you can even see this promotion in the manifesto (principles 2, 5, 6, 7, and 9, by my reckoning).
So as nice as a single implementation might be, dealing with multiple implementations was a fact of life in building an high quality open-source browser. We dealt with it, because it seemed like we would always need to support MSVC; who would invest the time to create an open source, MSVC-compatible compiler?
Well, Google, mostly, and a host of other people, because the past several releases of Clang have included an MSVC-compatible frontend, clang-cl. (Indeed, Firefox has been using clang-cl for Windows static analysis builds for some time.) And now that we have a usable non-MSVC compiler on Windows, we can contemplate using an open-source compiler to create our release Windows builds. And once we have that, we can consider using (and potentially only supporting) a single compiler (Clang) for all of the major platforms we support; Linux would be the remaining holdout. (Chrome already ships on Windows with clang and requires clang everywhere, FWIW.)
We might continue to require that things build with MSVC and GCC on relevant platforms, even if we’re not shipping these builds; even if this happened, such builds seem unlikely to last for very long, for all the reasons that we wanted them dropped in the first place. I imagine we’d probably continue to accept patches to make things build with non-Clang compilers, as long as the patches were not intrusive, just like we accept patches for non-tier 1 platforms.
Supporting a single compiler has a number of advantages:
- Cross-language LTO (i.e. inlining) between Rust and C++ (we could, of course, do this today, but we wouldn’t get the win on all platforms);
- Mozilla engineers can fix bugs in Clang/LLVM if need be;
- Fixes can be more easily backported from the Clang/LLVM development tree;
- Contributors have fewer compiler quirks to hold up their patches;
- Integrating and/or upgrading local copies of upstream projects becomes easier;
- Performance tuning becomes somewhat more straightforward when you have a single compiler to worry about.
I am probably forgetting some along the way. (I don’t think it’s true that we’ll be able to entirely eliminate hacks to pacify the compiler; you push on C++ hard enough and long enough, and you find yourself doing all manner of unusual things. We might even find ourselves doing