If, like me, you’re debugging a frontend issue and you think “I can just create some artifact builds on this device” — you might run in to a few issues. In the main, they’re caused by various bits of the build system attempting to use 64-bit x86 binaries. arm64 can run 32-bit x86 code under emulation, but not 64-bit. Here are the issues I encountered, chronologically.

1. The latest mozilla-build doesn’t work, because it only supplies 64-bit tools. Using an older version (2.2) does work.
   1. Note: Obviously this comes with older software. You should update pip and mercurial (using pip). I’d recommend not using the old software to connect to anything you don’t trust, no warranty, etc. etc.
2. You can now hg clone mozilla-central. It’ll take a while. You can also use pip to install/run other useful things, like mozregression (which seems to work but chokes when trying to kill off and delete Firefox processes when done; unsure why).
3. Running ./mach bootstrap mostly works if you pick artifact builds, but:
   1. It tries to install 64-bit x86 rustup, which doesn’t work (this bug should be fixed soon). Commenting out this line makes things work.
   2. It installs a 64-bit version of NodeJS, which also won’t work. You’ll want to remove ~/.mozbuild/node, download the 32-bit windows .zip from the NodeJS website and extract the contents at ~/.mozbuild/node to placate it.
4. If you now try to build, configure will choke on the lack of python3. This isn’t part of the old mozillabuild package, and so you want to download the latest python3 version as an “embeddable zip file” version off the python website , and extract it to path/to/mozilla-build/python3 . Then you will also want to make a copy of python.exe in that directory available as python3.exe, because that’s the path mozilla-build expects.
5. Next, configure will choke on the 64-bit version of watchman.exe that mozilla-build has helpfully provided. Rename the watchman directory inside mozilla-build (or delete it if you’re feeling vengeful) to deal with this.

That’s it! Now artifact builds should work – or at least, they did for me. Some of the issues are caused by bootstrap, and thus fixable, but obviously we can’t retrospectively change an old copy of mozilla-build. I’ve filed a bug to provide mozilla-build for aarch64.

TL;DR: from Firefox 64 onwards, RSS/Atom feed support will be handled via add-ons, rather than in-product.

What is happening?

After considering the maintenance, performance and security costs of the feed preview and subscription features in Firefox, we’ve concluded that it is no longer sustainable to keep feed support in the core of the product. While we still believe in RSS and support the goals of open, interoperable formats on the Web, we strongly believe that the best way to meet the needs of RSS and its users is via WebExtensions.

With that in mind, we have decided to remove the built-in feed preview feature, subscription UI, and the “live bookmarks” support from the core of Firefox, now that improved replacements for those features are available via add-ons.

Why are you doing this?

By virtue of being baked into the core of Firefox, these features have long had outsized maintenance and security costs relative to their usage. Making sure these features are as well-tested, modern and secure as the rest of Firefox would take a surprising amount of engineering work, and unfortunately the usage of these features does not justify such an investment: feed previews and live bookmarks are both used in around 0.01% of sessions.

As one example of those costs, “live bookmarks” use a very old, very slow way to access the bookmarks database, and it would take a lot of time and effort to bring it up to the performance standards we expect from Quantum. Likewise, the feed viewer has its own “special” XML parser, distinct from the main Firefox one, and has not had a significant update in styling or functionality in the last seven years. The engineering work we’d need to bring these features, in their current states, up to modern standards is complicated by how few automated tests there are for anything in this corner of the codebase.

These parts of Firefox are also missing features RSS users typically want. Live bookmarks don’t work correctly with podcasts, don’t work well with sync, and don’t work at all on any of Mozilla’s mobile browsers. They don’t even understand if an article has been read or not, arguably the most basic feature a feed reader should have. In short, the in-core RSS features would need both a major technical overhaul and significant design and maintenance investments to make them useful to a meaningful portion of users.

Looking forward, Firefox offers other features to help users discover and read content, and the move to WebExtensions will make it much easier for the Mozilla community to bring their own ideas for new features to life as well.

What will happen to my existing live bookmarks?

When we remove live bookmarks, we will:

1. Export the details of your existing live bookmarks to an OPML file on your desktop, which other feed readers (including ones that are webextensions) support importing from.
2. Replace the live bookmarks with “normal” bookmarks pointing to the URL associated with the live bookmark.
3. Open a page on support.mozilla.org that explains what has happened and offers you options for how you could continue consuming those feeds.

This will happen as part of Firefox 64, scheduled for release in December 2018. We will not change anything on Firefox 60 ESR, but the next major ESR branch (currently expected to be Firefox 68 ESR) will include the same changes.

Firefox 44 has been released, and it has started warning users of Tab Groups about its removal in Firefox 45. There were a number of reasons that led to the removal of Tab Groups. This post will aim to talk about each in a little bit more detail.

The removal happened in the context of “Great or Dead”, where we examine parts of Firefox, look at their cost/benefit balance, and sometimes decide to put resources into improving them, and sometimes decide to recognize that they don’t warrant that and remove that part of the browser.

For Tab Groups, here are some of the things we considered:

• It had a lot of bugs. A number of serious issues relating to performance, a lot of its tests failed intermittently, group and window closing was buggy, as well as a huge pile of smaller issues: you couldn’t move tabs represented as large squares to groups represented as small squares; sometimes you could get stuck in it, or groups would randomly move ; and the list goes on – the quality simply wasn’t what it should be, considering we ship it to millions of users, which was part of the reason why it was hidden away as much as it was.
• The Firefox team does not believe that the current UI is the best way to manage large numbers of tabs. Some of the user experience and design folks on our team have ideas in this area, and we may revisit “managing large numbers of tabs” at some point in the future. We do know that we wouldn’t choose to re-implement the same UI again. It wouldn’t make sense to heavily invest in a feature that we should be replacing with something else.
• It was interfering with other important projects, like electrolysis (multi-process Firefox). When using separate processes for separate tabs, we need to make certain behaviours that used to be synchronous deal with being asynchronous. The way that Tab Groups’ UI was interwoven with the tabbed browser code, and the way the UI effectively hid all the tabs and showed thumbnails for all of them instead, made this harder for things like tab switching and tab closing.
• It had a number of serious code architecture problems. Some of the animation and library choices caused intermittent issues for users as linked to earlier. All of the groups were stored with absolute pixel positions, creating issues if you change your window size, use a different screen or resolution, etc. When we added a warning banner to the bottom of the UI telling users we were going to remove it, that interfered with displaying search results. The code is very fragile.
• It was a large feature. By removing tab groups we removed more than 24,000 lines of code from Firefox.

With all these issues in mind, we had to decide if it was better to invest in making it a great feature in Firefox, or remove the code and focus on other improvements to Firefox. When we investigated usage data, we found that only a extremely small fraction of Firefox users were making use of Tab Groups. Around 0.01%. Such low usage couldn’t justify the massive amount of work it would take to improve Tab Groups to an acceptable quality level, and so we chose to remove it.

If you use Tab Groups, don’t worry: we will preserve your data for you, and there are add-ons available that can make the transition completely painless.

I wrote a thing to check if your patch landed/stuck. It’s on github because that’s what people seem to do these days. That means you can use it here:

Did it land?

The “point” of this mini-project is to be able to easily determine whether bug X made today’s nightly, or if bug Y landed in beta 5. Sometimes non-graph changelogs, such as are most accessible on hgweb, can be misleading (ie beta 5 was tagged after you landed, but on a revision before you landed…), plus it’s boring to look up revisions manually in a bug, and then look them up on hgweb, and then try to determine if revision A is in the ancestry tree for revision B. So I automated it.

Note that the tool doesn’t:

• deal cleverly with backouts. It’ll give you revision hashes from the bug, but if it notices comments that seem to indicate something got backed out, it will be cautious about saying “yes, this landed”. If you know that you bounced once but the last revision(s) is/are definitely “enough” to have the fixes be considered “landed”, then you can just switch to looking up a revision instead of a bug, copy-paste the last hash, and try that one. With a bit of work it could probably expose the internal data about which commits landed before a nightly in the UI – the data is there!
• use hg to extract the bug metadata. It’s dumb and just asks for a bug’s comments from bugzilla. Pull requests or other help about how to do this “properly” welcome.
• deal cleverly with branching. If you select aurora/beta, it will look for commits that landed on aurora/beta, not for commits that landed on “earlier” trees and made their way down to aurora/beta with the regular train. This is not super hard to fix, I think, but I haven’t gotten around to it, and I don’t think it will be a very common case.
• have a particularly nice UI. Feel free to send me pull requests to make it look better.

Sometimes, after we close a bug because we fix it, or because it is a duplicate of another bug, or because the symptoms have gone away — invalid and wontfix bugs are a little different — people come along that have a problem that they believe is identical to the original bugreport. Quite often, they end up commenting on the “old” bugreport and say something along the lines of “hey, this is not fixed yet” or “this broke again” or “why did you close this bug, I’m still seeing this”!

In 99% of cases, I (and many other people) ask people in this situation to file a new bug.

The reasons why we do this vary a little, but on the whole they tend to be pretty similar, and so I figured it would be worth documenting them. In no particular order, we prefer new bugs over reopening closed ones because:

• More often than not, issues with similar symptoms can be caused by different factors. In Firefox’s case, these can be the version of Firefox, add-ons, different preferences/options that people have selected, third-party software, network setup, hardware and drivers, the OS people are using (Mac, Linux, Windows (what version?), …), changes in public web pages involved with the bug, … it’s a pretty long list. Different causes will require different fixes, and tracking them in the same bug will lead to confusion very quickly.
• We close bugs as fixed when we land patches. We track the uplift of the patches that landed for a bug in that bug. Reopening a bug that has already had patches landed in the tree, especially once they’ve been uplifted and released, confuses tracking the state of those patches, and any new patches that we write to fix the same issue.
• The old bug will have investigation and discussion of the problem as originally reported. If we now start investigating the new issue in the same place, with the old summary and the old comments, testcases, attachments, steps to reproduce, reporter, etc., we will eventually get confused. This relates to the first point: quite often there are subtle differences. Keeping track of those once we have two reports in a single bug, and ensuring we address the issue fully is difficult, often impossible.
• Bugzilla sends a lot of email, and is geared towards communication with flags and email. If you report an issue by commenting in another one, the “reporter” role of that bug is still the old reporter, and the CC list includes all the reporters of the duplicate bugs that were filed, the assignee will be the person who landed the last few patches (but they might not be able to fix the newly-reported thing, or might even have left Mozilla altogether), and so on and so forth. This confuses the “needinfo” flag, spams all those people about an issue they might no longer be seeing, and generally leads to still more confusion.
• People track open bugs they are assigned to, and new bugs in certain components. New comments (on closed bugs) are much, much more likely to get lost in the daily bugmail avalanche – which means your issue won’t get fixed.
• Comments are almost always low on details. Comments are often “this still doesn’t work”, with no indication of any of the environmental factors that impact where and when people see bugs (see the earlier point). When people file new bugs, we immediately get more information, normally at least the operating system and version of Firefox involved, and if people are careful about how they file the bug and describe its symptoms or steps to reproduce, we might learn about differences in the steps they’re using, compared to the old bug.
• New bugs are cheap! Bugzilla has more than 1.1 million bugreports in it. Another one won’t hurt. Worst case scenario, we can mark it as a duplicate of the old one…

It might be interesting if we had an easy way to split a comment into a new bug, though that would still defeat some of the points raised earlier. In the meantime though, think twice before commenting on older, closed bugs with a “this is still broken” comment!

How do I get attention for my newly filed bug? Email to all the people on this old bug seems much more likely to get attention!

First off, this strategy can be detrimental in many cases (see e.g. this or this – or just consider how much “email to all the people…to get attention” sounds like “spam”).

Second, we get a lot of bugreports. We’re working on ensuring they get triaged effectively. This should already be a lot better than it was a few months ago (see this post by Benjamin Smedberg), and will continue to improve.

Finally… if you file a bug that is extremely similar to an old bug, it seems fair to me to leave a comment in the old bug, mark the new bug as blocking the old bug, and/or set the needinfo flag for the assignee (if available) of the fixed bug, to draw their attention to this new bug.

Working on Firefox front-end code, I am often reminded of Nicholas’ excellent post on people’s experiences and how those experiences shape their opinions.

The most recent example concerns the beforeunload event and the resulting dialog.

On the one hand there are people who see it as the bane of a usable web. They mostly encounter it when it is abused by malicious websites to trap users on a page they don’t want them to leave, and so they view it as a misfeature that should have been removed from the relevant specs 10 years ago. Websites shouldn’t be able to keep a tab open at all! They honestly and sincerely see no reason why on earth Firefox (and most other desktop browsers) still support it.

On the other there are people who see it as critical web infrastructure to ensure users can’t accidentally close a tab/window while in the middle of a task, causing data loss, and for that reason they honestly and sincerely see no reason why we’re even talking about getting rid of it. “Even” Facebook and Google Apps, who otherwise have decent facilities for saving drafts etc., will use it in some cases.

Even when this discrepancy in experience and their resulting opinions is pointed out, people who hold opinions on the extreme end of this spectrum seem reluctant to accept that really, there might be both pros and cons involved here, and a solution is not so straightforward as either believed.

If/when they do, the solution offered is usually “make it a preference”, with resulting debate about what the default should be (NB: in this case, such a (hidden) preference was already added). However, this is not what we prefer doing when working on Firefox, we historically haven’t, and still don’t.

I’d be interested if people have suggestions on how we could concretely address both usecases in the example I used, in a way that makes life better for both groups of users. For the latter, note that the event causes other technical difficulties even when not used for ‘trapping’ users, and that mobile browsers have already started disregarding it in some cases.

At this point, the best plan I know of is not showing a dialog when closing a single tab, perhaps while keeping the dialog for application/window closes and navigation. (For concrete followups regarding this particular issue, please consider writing to firefox-dev instead of commenting here.)

However, finding a solution for “beforeunload” and its dialog doesn’t solve the more general problem: how do you bridge the gap in the general case and explain why we are not “just” doing what seems “obvious”? How do you turn the fierce disagreement into a constructive solution-oriented discussion?

I’ve had problems before where it would have been useful to easily run mochitests against other versions of the browser than those in my $OBJDIR. I’m pleased to say I just landed a small patch for the mochitests runner’s mach commands that lets you do:

./mach mochitest-browser --app-override /usr/bin/firefox path/to/test

and also has a special shortcut for the application as built for distribution (using omni.jar rather than a flat directory structure):

./mach mochitest-browser --app-override dist path/to/test

Happy testing!

We’re getting closer and closer to releasing Australis with Firefox 29, and that gives me more time to write something that’s been on my mind the last couple of weeks/months. Extra impetus was provided by sentiment along the lines of “how did you possibly miss this / think fix X was a good idea?” from some people outside the core development team, responding to some of our changes.

In this post, I’d like to give you an idea of the number of combinations of options, configurations, themes, add-ons, fonts and styles. It is enormous. Firefox generally tries to fit in with your operating system as best it can, and that means we have to pay attention to lots of things. And yes, that means sometimes we miss things. Here’s a breakdown of some of the things I’ve seen fly by as we made Australis, all linked to bugs specific to particular scenarios (there are 54 individual bugs linked, the majority of which were fixed for 29).

Firefox is available on three main (tier-1) platforms: Windows, Linux, and OS X.

All three platforms support lightweight themes, of which we support light and dark text variants. On light text lightweight themes, we invert the text and icons to be bright (which usually means the theme itself has a dark background). Interactions between these themes and the OS are not always the same everywhere, which leads to bugs.

Different toolbars like the menubar and the bookmarks toolbar can be toggled on and off (which sometimes makes certain ideas more difficult), and the menubar has an autohide state, which is new on Linux and caused specific bugs there.

And although we normally always show the tabbar and the navbar, there are popup windows where we don’t (toolbar=no), which, you guessed it, causes bugs.

Then we have per-window private browsing, which has an indicator which makes things ‘fun’ (and soon private browsing will look even more different from normal browsing).

Of course, while we stick to English layout direction is more or less fixed, but we ship both LTR and RTL locales on all platforms, which changes the order of things, which frequently leads to bugs.

Then there’s the padding that we added for “customize mode”, which affects layout of the toolbars and the (‘fake’) titlebar, which had its own problems.

Some issues are specific to pinned or overflowing tabs (sometimes even particular tabs), as well as panorama/tab groups.

Beyond that, styling is somewhat platform-specific, each with their own quirks:

OS X

OS X is, in a certain sense, “easiest” because the OS doesn’t have a lot of options that mess with things (font size, for example, isn’t easily configurable). But there’s still some variation:

• Lion vs. pre-lion: 10.6, which we still support, has no fullscreen button in the titlebar (unlike 10.7-10.9) and has no concept of “Lion fullscreen”.
• Spaces: causes odd bugs with panels.
• HiDPI (“retina”): this causes bugs / missed cases. Add external displays which might not be hidpi, and you get even odder bugs (this one’s 10.9-only, too, it seems!).
• RTL. Coupled with retina –> more bugs.
• 10.9 broke more stuff.
• Titlebar can be turned on/off now: cue more bugs.

Linux

Linux really means “Unix that has GTK”, as far as theming is concerned. Unfortunately that ends up being a wide spectrum of cases:

• Configurable font-sizes. And unsurprisingly, even when we use font-size based sizing to avoid issues, that still causes bugs (because CSS rounds things. ouch.)
• Different GTK themes cause lots of bugs.
• The same GTK theme being different in different distros or shells (Gnome 3 vs. Unity) makes bugs difficult to reproduce/track down.
• Different versions of GTK and/or GTK with/without compositor cause issues.

Windows

Windows really means “Windows XP, Windows Vista, Windows 7, Windows 8(.1) and all the corresponding Windows Server versions”. Which then means:

• A large number of OS themes to worry about:
  • Windows classic (on XP, Vista and 7)
  • Windows XP “modern” (Luna Blue, Olive and Silver)
  • Vista/7 “Basic” a.k.a. Aero-lite
  • Vista/7 Aero
  • Pre-Windows-8 high contrast themes
  • Windows 8 default theme (with arbitrary colors)
  • Windows 8 high contrast themes
• Configurable colors, fonts and font-sizes for Windows classic themes (and I think pre-Windows-8 high contrast themes, too?)
• Different fonts ship as default in different Windows locales (!), and the default fonts change between Windows versions. The font is user-configurable under some themes and versions of Windows, but not others (e.g. Windows 8).
• Titlebar toggling and some Windows themes (but not others, and also, multiple windows and a non-default session restore pref, in the case of this bug)
• Toggling some about:config preferences has surprising results.
• HiDPI is increasingly common, and more complicated than on OS X because of the variety of scaling factors available. We improved the tabs, but there is plenty left to do.
• Custom Windows XP themes! (which don’t always seem to expose the right colors, making it practically impossible to work well)
• Significant differences between maximized and restored mode.

This list doesn’t include bugs caused or revealed by add-ons, but of course those also add interesting behaviour to the mix.

All in all, it’s been an interesting first year as an employee at Mozilla (I started April 1st, 2013), and I can’t wait to see all our changes ship: Firefox 29 is scheduled for release on April 29th.

About a month ago I posted about debugging chrome JS and mochitests. Since then, we’ve done a fair bit to improve the situation, and so I figured an update was in order (I’ve posted some of this to fx-dev and m.d.platform already, so apologies if you’re reading this twice). In particular:

• After updating your chrome/remote debugging settings, no restart or new window is required anymore to start debugging, and the notes that say so are gone, too. So all you  need to do is toggle the required settings, and open the debugger from the menu.
• As of today’s nightly (still building) you’ll be able to use the --jsdebugger flag to start the browser debugger on browser startup. (with many thanks due to Panos for fixing an issue that stopped this, as well as –jsconsole, from working on Nightly builds, but not self-compiled builds)
• As of just now, mach on mozilla-central supports using the aforementioned flag with mochitests as well, and you can debug your mochitests in one easy command:

  ./mach mochitest-browser --jsdebugger <my-test(s)>

  The test framework takes care of setting the required prefs in the freshly created profile, – you won’t even be prompted to allow the connection – and will wait with running the tests so you have time to set breakpoints etc.

Happy debugging!

Somewhat surprisingly given that I’ve been “around” for “a while”, this year’s was the first summit I went to. I’d been to several FOSDEMs, a EuroOSCON/EuroFoo, and several other conferences as a Mozillian, but somehow the invitations for Summits/MozCamps/Add-on events had always come at a time when I had already planned other international travel for whenever they were happening (once more my apologies to Will, who I think has never had any other response to invites than apologetic “erm, I’d love to, but I can’t make it — maybe next time?” emails).

Anyhow, this was the first time announcements came so early (and my traveling had somewhat quietened down) that I was still free. And what an event it was! I met a whole bunch of folks that I’d never seen before, despite interacting with them online for years now (I would add a list but I’d be sure to forget someone…). It’s great to have faces (and some stories) to the names. Then there were some of my Firefox MoCo teammates that I met for the first time. I also had a chance to hang out with a wide range of people, volunteer and employee alike, active in totally (or only slightly) different areas of the project than me (MoCo “people team” folks, documentation writers, reps, devtools team members, add-ons developers, Paris office workplace resource people, and the list goes on…) both during sessions as well as in bars, when walking through random bits of Brussels, or in the hotel lobby / breakfast room.

Session-wise, I first went to the excellent session about Privacy, Security and Data. Thanks Garrett, Stacy, Curtis, Crystal, etc. for a fascinating session about what we can do and how our biases about privacy as technically adept folks are different from most other people, who worry about completely different things.

The next day I spent a bunch of my energy showing off Australis and answering questions about it at the Innovation Fair together with Jared, Matt, and many of the UX team people (who had a bunch of other stuff to show off, not just Australis). At the Brussels booth, we had a good selection of questions and worries from people about add-on compatibility, Linux (sadly, our booth table was big enough for two laptops, on which we showed OS X and Windows builds, which probably prompted many of the questions), customizability, and how to test the builds. Hopefully we did a good job answering those questions, and we’re getting ever closer to shipping Australis on Nightly!

We then had a hurried lunch and I went to the “Developing empathy for your users” session. I met some more amazing people there, and we had an interesting time thinking through the motivations and interests of the people that our UX team met doing field research, and trying to see how and why they made decisions the way they did. Thank you Larissa and Maureen for an excellent session!

Afterwards I had a quick conversation with Blake about an idea that I’d been mulling over for a while now, and spent the rest of the afternoon hacking. Not that idea, but related, is now slowly progressing on bugzilla: create source maps for preprocessed chrome files. Otherwise, if I find some extra hours in my week (unlikely) I may try and produce something else to ease hacking on the front-end of Mozilla products. 🙂

Finally, on Sunday, there was a bunch more hacking, and I went to the excellent session on DRM, where we had a somewhat depressing discussion about what we as Mozilla can do about the EME proposal in the W3C HTML spec.

On Monday, we all went home again! I think what I took away from the summit most of all was an increased awareness of the size and diversity of our community and its goals, as well as how the mission unites us. Kudos to the organizers for coordinating a complex and large event as well as they did! 🙂