Mozilla Firefox

Topic: The tools that make a successful project manager.

TenFourFox "FPR4.1" (officially Feature Parity Release 4, Security Parity Release 1) is available for testing (downloads, hashes; release notes pending revision). This is an urgent security and bugfix update which repairs a serious information leak ... [More] in Private Browsing mode that affects all versions of Firefox (and TenFourFox) to at least version 35. I also included a bugfix for an edge case in our internal AltiVec-accelerated strchr() implementation which was discovered when I expanded its usage to other portions of the browser. Mozilla is chemspilling updated versions of Fx57 and ESR52; I plan to follow suit and the fixed version will go live this afternoon-evening Pacific time assuming no problems. There are no other changes in this release. If you are rolling your own build, pull the tree at release FPR4 and add the relevant patches from issues 440 and 451. FPR5 is coming along very well. If I could sum up the changes in two words, it would be "MOAR ALTIVEC." Two other words I'd use are "stay tuned" and "totally awesome" and "amazing programmer" and "very modest." [Less]

The Monday Project Meeting

Pick of the Month: Group Speed Dial by Juraj Organize all your favorite websites with visual bookmarks. “Fast. All other speed dials are resource hungry and slow.” Featured: Gesturefy by Robbendebiene, Itch Enjoy 40+ customizable mouse gestures. ... [More] Includes multi-language support. “Very good as an alternative to FireGesture.” Featured: Tree Style Tab by Piro Display your open tabs in a tree style. “Perfect for opening lots of tabs on a widescreen monitor. All tabs remain readable contrary to the normal tab layout.” Featured: Multi-Account Containers by Mozilla An official Mozilla extension, Multi-Account Containers lets you keep distinct parts of your online life separated into color-coded tabs. Cookies are separated by container, allowing you to use the Web with multiple identities simultaneously. “This add-on is my daily partner. Now Facebook doesn’t know what I buy ;).” Featured: User-Agent Switcher by RayLo A tool to spoof user-agent strings. “Easy to use and portable too. Thank you!!” Featured: Tab Auto Refresh by Alex Automatically refresh your tabs on custom time intervals. “This is the first auto reload/refresh Firefox extension that I’ve found that can be customized for each tab that I have! This is exactly what I wanted and it works fantastic. Highly recommended.” Featured: Google Translator by Andy Portman Access a simple way to translate single words or large, complex phrases. “Easy to use, amazing pop-up background, a powerful dictionary translator!” Nominate your favorite add-ons Featured add-ons are selected by a community board made up of add-on developers, users, and fans. Board members change every six months. Here’s further information on AMO’s featured content policies. If you’d like to nominate an add-on 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 December’s Featured Extensions appeared first on Mozilla Add-ons Blog. [Less]

There is a strong argument in modern software engineering that a sequence of smaller changes is preferable to a single large change. This approach facilitates development (easier to debug, quicker to land), testing (less functionality to verify at ... [More] once), reviews (less code to keep in the reviewer’s head), and archaeology (annotations are easier to follow). Recommended limits are in the realm of 300-400 changed lines of code per patch (see, for example, the great article “How to Do Code Reviews Like a Human (Part Two)”). 400 lines can still be a fairly complex change. Microcommits is the small-patch approach taken to its logical conclusion. The idea is to make changes as small as possible but no smaller, resulting in a series of atomic commits that incrementally implement a fix or new feature. It’s not uncommon for such a series to contain ten or more commits, many changing only 20 or 30 lines. It requires some discipline to keep commits small and cohesive, but it is a skill that improves over time and, in fact, changes how you think about building software. Former Mozillian Lucas Rocha has a great summary of some of the benefits. Various other Mozillians have espoused their personal beliefs that Firefox engineering would do well to more widely adopt the microcommits approach. I don’t recall ever seeing an organized push towards this philosophy, however; indeed, for better or for worse Mozilla tends to shy away from this type of pronouncement. This left me with a question: have many individual engineers started working with microcommits? If we do not have a de juror decision to work this way, do have a de facto decision? We designed MozReview to be repository-based to encourage the microcommit philosophy. Pushing up a series of commits automatically creates one review request per commit, and they are all tied together (albeit through the “parent review request” hack which has understandably caused some amount of confusion). Updating a series, including adding and removing commits, just works. Although we never got around to implementing support for confidential patches (a difficult problem given that VCSs aren’t designed to have a mix of permissions in the same repo), we were pretty proud of the fact that MozReview was unique in its first-class support for publishing and reviewing microcommit series. While MozReview was never designated the Firefox review tool, through organic growth it is now used to review (and generally land) around 63% of total commits to mozilla-central, looking at stats for bugs in the Core, Firefox, and Toolkit products: To be honest, I was a little surprised at the numbers. Not only had MozReview grown in popularity over the last year, but much of its growth occurred right around the time its pending retirement was announced. In fact, it continued to grow slightly over the rest of the year. However, we figured that, owing to MozReview’s support for microcommits, this wasn’t quite a fair comparison. Bugzilla’s attachment system discourages multiple patches per bug, even with command-line tools like bzexport. So we figured that, generally, a fix submitted to MozReview would have more parts than a corresponding fix submitted as a traditional BMO patch. Thus the bug-to-MozReview-request ratio would be lower than the bug-to-patch ratio. We ran a query on the number of MozReview requests per bug in about the last seven months. These results yielded further surprises: About 75% of MozReview commit “series” contain only a single commit. 12% contain only two commits, 5% contain three, and 2.7% contain four. Series with five or more commits make up only 5.3%. Still, it seems MozReview has perhaps encouraged the splitting up of work per bug to some degree, given that 25% of series had more than one commit. We decided to compare this to traditional patches attached to bugs, which are both more annoying to create and to apply: Well then. Over approximately the same time period, of bugs with old-style attachments, 76% had a single patch. For bugs with two, three, and four patches, the proportions were 13%, 7%, and 1.5%, respectively. This is extremely close to the MozReview case. The mean is almost equal in both cases, in fact, slightly higher in the old-style-attachment case: 1.65 versus 1.61. The median in both cases is 1. Okay, maybe the growing popularity of MozReview in 2017 influenced the way people now use BMO. Perhaps a good number of authors use both systems, or the reviewers preferring MozReview are being vocal about wanting at least two or three patches over a single one when reviewing in BMO. So we looked back to the situation with BMO patches in early 2016: Huh. One-, two-, three-, and four-patch bugs accounted for 74%, 14%, 5%, and 2.6%, respectively. For one more piece of evidence, this scatter plot shows that, on average, we’ve been using both BMO and MozReview in about the same way, in terms of discrete code changes per bug, over the last two years: There are a few other angles we could conceivably consider, but the evidence strongly suggests that developers are (1) creating, in most cases, “series” of only one or two commits in MozReview and (2) working in approximately the same way in both BMO and MozReview, in terms of splitting up work. I strongly believe we would benefit a great deal from making more of engineering’s assumptions and expectations clearer; this is a foundation of driving effective decisions. We don’t have to be right all the time, but we do have to be conscious, and we have to own up to mistakes. The above data leads me to conclude that the microcommit philosophy has not been widely adopted at Mozilla. We don’t, as a whole, care about using series of carefully structured and small commits to solve a problem. This is not an opinion on how we should work, but a conclusion on how we do work, informed by data. This is, in effect, a decision that has already been made, whether or not we realized it. Although I am interested in this kind of thing from an academic perspective, it also has a serious impact to my direct responsibilities as an engineering manager. Recognizing such decisions will allow us to better prioritize our improvements to tooling and automation at Mozilla, even if it has to first precipitate a serious discussion and perhaps a difficult, conscious decision. I will have more thoughts on why we have neither organically nor structurally adopted the microcommits approach in my next blog post. Spoiler: it may have to do with prevailing trends in open-source development, likely influenced by GitHub. [Less]

From powerful extensions like Stratiform or FT Deep Dark to simple lightweight themes, theming has been quite popular within Firefox. Now that Firefox Quantum (57) has launched with many performance improvements and a sparkling new interface, we want ... [More] to bridge the gap with a new theming API that allows you to go beyond basic lightweight themes. Demo by John Gruen What can you theme? Before the launch of Quantum, lightweight themes had a limited set of properties that could be themed: you could only add a header image and set the frame text color and background color. The new theming API introduces some new properties. The full list can be found on MDN. A basic Theme object looks like this: { "colors": { "accentcolor": "tomato", "textcolor": "white", "toolbar": "#444", "toolbar_text": "lightgray", "toolbar_field": "black", "toolbar_field_text": "white" }, "images": { "headerURL": "" } } Here’s how the above theme is displayed: Notice how the images.headerURL property is set to an empty string. This is because it is one of three mandatory properties: images.headerURL, colors.accentcolor and colors.textcolor. Finally, another improvement to lightweight themes is support for multiple header images, using the images.additional_backgrounds field which takes an array of image paths. The alignments and tilings of these images is achieved using properties.additional_backgrounds_alignment and properties.additional_backgrounds_tiling, which take in an array of background-position and background-repeat values respectively. You can check out the MDN page for an example. You can use multiple backgrounds in order to display curtains on both sides of the browser UI, or as a way to add several thematic indicators (sports/weather/private browsing) in the UI. Dynamic themes Let’s say you would like to introduce a night mode to your theme. Dynamic themes allow you to do this. They have the full power of a normal browser extension. To use dynamic theming, you need to add the theme permission to your manifest. The browser.theme.update() method is at the core of this type of theming. It takes in a Theme object as parameter. The method can be called anywhere in your background scripts. For this example, let’s create an extension that switches the theme depending on whether it’s night or day. The first step is to create a function in your background script that switches your theme to the day theme or the night theme: var currentTheme = ''; const themes = { 'day': { images: { headerURL: 'sun.jpg', }, colors: { accentcolor: '#CF723F', textcolor: '#111', } }, 'night': { images: { headerURL: 'moon.jpg', }, colors: { accentcolor: '#000', textcolor: '#fff', } } }; function setTheme(theme) { if (currentTheme === theme) { // No point in changing the theme if it has already been set. return; } currentTheme = theme; browser.theme.update(themes[theme]); } The above code defines two themes: the day theme and the night theme, the setTheme function then uses browser.theme.update() to set the theme. The next step is now to use this setTheme function and periodically check whether the extension should switch themes. You can do this using the alarms API. The code below checks periodically and sets the theme accordingly: function checkTime() { let date = new Date(); let hours = date.getHours(); // Will set the sun theme between 8am and 8pm. if (hours > 8 && hours < 20) { setTheme('day'); } else { setTheme('night'); } } // On start up, check the time to see what theme to show. checkTime(); // Set up an alarm to check this regularly. browser.alarms.onAlarm.addListener(checkTime); browser.alarms.create('checkTime', {periodInMinutes: 5}); That’s it for this example! The full example is available on the webextension-examples github repository. Another method that’s not covered by the example is browser.theme.reset(). This method simply resets the theme to the default browser theme. Per-window themes The dynamic theming API is pretty powerful, but what if you need to apply a different theme for private windows or inactive windows? From Firefox 57 onwards, it is possible to specify a windowId parameter to both browser.theme.update() and browser.theme.reset(). The windowId is the same ID returned by the windows API. Let’s make a simple example that adds a dark theme to private windows and keeps other windows set to the default theme: We start by defining the themeWindow function: function themeWindow(window) { // Check if the window is in private browsing if (window.incognito) { browser.theme.update(window.id, { images: { headerURL: "", }, colors: { accentcolor: "black", textcolor: "white", toolbar: "#333", toolbar_text: "white" } }); } // Reset to the default theme otherwise else { browser.theme.reset(window.id); } } Once that’s done, we can wire this up with the windows API: browser.windows.onCreated.addListener(themeWindow); // Theme all currently open windows browser.windows.getAll().then(wins => wins.forEach(themeWindow)); Pretty straightforward right? The full example can be found here. Here is how the example looks: Another add-on that makes use of these capabilities is the Containers theme by Jonathan Kingston, which sets the theme of each window to the container of its selected tab. The source code for this add-on can be found here. The VivaldiFox add-on also makes use of this capability to display different website themes across different windows: Obtaining information about the current theme From Firefox 58 onward, you can now obtain information about the current theme and watch for theme updates. Here’s why this matters: This allows add-ons to integrate their user interface seamlessly with the user’s currently installed theme. An example of this would be matching your sidebar tabs colors with the colors from your current theme. To do so, Firefox 58 provides two new APIs: browser.theme.getCurrent() and browser.theme.onUpdated. Here is a simple example that applies some of the current theme properties to the style of a sidebar_action: function setSidebarStyle(theme) { const myElement = document.getElementById("myElement"); // colors.frame and colors.accentcolor are aliases if (theme.colors && (theme.colors.accentcolor || theme.colors.frame)) { document.body.style.backgroundColor = theme.colors.accentcolor || theme.colors.frame; } else { document.body.style.backgroundColor = "white"; } if (theme.colors && theme.colors.toolbar) { myElement.style.backgroundColor = theme.colors.toolbar; } else { myElement.style.backgroundColor = "#ebebeb"; } if (theme.colors && theme.colors.toolbar_text) { myElement.style.color = theme.colors.toolbar_text; } else { myElement.style.color = "black"; } } // Set the element style when the extension page loads browser.theme.getCurrent().then(setSidebarStyle); // Watch for theme updates browser.theme.onUpdated.addListener(async ({ theme, windowId }) => { const sidebarWindow = await browser.windows.getCurrent(); /* Only update theme if it applies to the window the sidebar is in. If a windowId is passed during an update, it means that the theme is applied to that specific window. Otherwise, the theme is applied globally to all windows. */ if (!windowId || windowId == sidebarWindow.id) { setSidebarStyle(theme); } }); The full example can be found on Github. As you can see in the screenshot below, the sidebar uses colors from the currently applied browser theme: Another example is the Tree Style Tab add-on which makes use of these APIs to integrate its interface with the currently used theme. Here is a screencast of the add-on working together with VivaldiFox: What’s next? There is more coming to this API! We plan to expand the set of supported properties and polish some rough edges around the way themes are applied. The tracking bug for the API can be found on Bugzilla. In the meanwhile, we can’t wait to see what you will be able to do with the new theming API. Please let us know what improvements you would like to see. [Less]

Greetings Mozillians! We are happy to let you know that Friday, December 8th, we are organizing Firefox 58 Beta 10 Testday. We’ll be focusing our testing on Media Recorder Refactor and Tabbed Browser. Check out the detailed instructions via ... [More] this etherpad. No previous testing experience is required, so feel free to join us on #qa IRC channel where our moderators will offer you guidance and answer your questions. Join us and help us make Firefox better! See you on Friday! [Less]

My comments on Bug 1422892 started to get long, so I started untangling my thoughts here. From the bug: We experimented with using activity_date instead of submission_date when developing the clients_daily etl job. We should summarize our findings and decide on which of these measures we'd like to standardize against …

Someone seems to be still convinced that changing our beloved NoScript UI has been a whimsical (and suicidal) decision of mine, entirely avoidable. The ones who know better about recent history of Firefox and of its add-ons ecosystem are aware ... [More] , though, that the UI couldn't stay the same simply because the technical foundation (XUL/XPCOM) for the "old" one is not there anymore, and NoScript has been forced into being completely rewritten as a WebExtension (and therefore its UI as pure HTML) or just die. Since it was anyway impossible to replicate exactly the well known NoScript 5.x user experience, I've tried to find a silver lining in the forced rewrite, taking it as a chance to incorporate user feedback collected over more than 12 years, especially about making the permissions system more customizable. And indeed, the old concepts are all still there, but the way they are implemented is more flexible and amenable to customization, albeit admittedly less discoverable and, for long time users, surely confusing at least initially. Bugs aside, I think the biggest problem with the transition, which I'm truly sorry for, is me not having found the time yet to write any proper user-oriented documentation for NoScript 10; but maybe we can start here by providing a minimalistic overview, mapping the new "Quantum" UI onto the "Legacy" (I actually prefer to call it "Classic") one: In the NoScript 10 we've got 3 presets (DEFAULT, UNTRUSTED and TRUSTED): you can assign one of them to any site, and the sites with the same preset share the same set of (configurable) permissions For sites that don't fit in any of the 3 aforementioned presets, you can choose to use CUSTOM permissions: CUSTOM is not a preset, but a way to give very specific permissions to a site, applying to that site only Back to presets, DEFAULT is the set of permissions that any unknown site has. So if you don't touch NoScript, beside a handful of websites (the "old" default whitelist) pre-assigned with the TRUSTED preset, all the sites on the Web have the permissions of the DEFAULT preset (i.e. almost none). "Temporary allow xyz.com" maps to clicking the TRUSTED preset on the xyz.com row. "Allow xyz.com" (permanently) maps to clicking the clock-shaped icon onto the TRUSTED preset (which means "Temporary"), to disable it (and make the preset assignment "Permanent") "Forbid xyz.com" maps to clicking the DEFAULT preset, which actually means deleting the site from the internal "whitelist". In facts, if you do it in the general Options panel, next time you open the panel (or refresh it) the site is not even listed there anymore. It doesn't disappear right away for convenience, to give you the chance to change your mind or correct mistakes. "Mark xyz.com as untrusted" maps to clicking the UNTRUSTED preset, which contains no permission at all and is meant to collect and remember the "known bad sites" in a permanent blacklist. And then CUSTOM, which is new to NoScript 10 and lets you fine tune just a certain website with its own specific permissions, either more restrictive than DEFAULT or more permissive than TRUSTED ; this tuning is either permanent (by default, the clock shaped icon in this case comes disabled) or temporary, by additionally clicking the clock-shaped icon. Each and all the presets can be freely customized to your own needs, with the convenience constraint that you cannot remove the "script" permission from TRUSTED, and you cannot add it to UNTRUSTED. However, the factory presets are very similar to the "old" NoScript experience. A lot more needs to be written yet, but these are the bare bones. If you find bugs or need support, rather than using in the blog comments or, even worse, the AMO review system as a way to communicate with developers, please submit to the support forum here. And if you want to help me with development, please install latest development build, which is released even more often than the stable and ships earlier both bug fixes and new features. And please keep providing feedback, as especially the UI is still a work in progress and I'm eager to make it better than before, by merging as much as possible of your valuable contributions. Thank you all! [Less]

Someone seems to be still convinced that changing our beloved NoScript UI has been a whimsical (and suicidal) decision of mine, entirely avoidable. The ones who know better about recent history of Firefox and of its add-ons ecosystem are aware ... [More] , though, that the UI couldn't stay the same simply because the technical foundation (XUL/XPCOM) for the "old" one is not there anymore, and NoScript has been forced into being completely rewritten as a WebExtension (and therefore its UI as pure HTML) or just die. Since it was anyway impossible to replicate exactly the well known user experience provided by NoScript 5.x (which, BTW, is still actively maintained and available here), I've tried to find a silver lining in the forced rewrite, taking it as a chance to incorporate user feedback collected over more than 12 years, especially about making the permissions system more customizable. And indeed, the old concepts are all still there, but the way they are implemented is more flexible and amenable to customization, albeit admittedly less discoverable and, for long time users, surely confusing at least initially. Bugs aside, I think the biggest problem with the transition, which I'm truly sorry for, is me not having found the time yet to write any proper user-oriented documentation for NoScript 10; but maybe we can start here by providing a minimalistic overview, mapping the new "Quantum" UI onto the "Legacy" (I actually prefer to call it "Classic") one: In the NoScript 10 we've got 3 presets (DEFAULT, UNTRUSTED and TRUSTED): you can assign one of them to any site, and the sites with the same preset share the same set of (configurable) permissions For sites that don't fit in any of the 3 aforementioned presets, you can choose to use CUSTOM permissions: CUSTOM is not a preset, but a way to give very specific permissions to a site, applying to that site only Back to presets, DEFAULT is the set of permissions that any unknown site has. So if you don't touch NoScript, beside a handful of websites (the "old" default whitelist) pre-assigned with the TRUSTED preset, all the sites on the Web have the permissions of the DEFAULT preset (i.e. almost none). "Temporary allow xyz.com" maps to clicking the TRUSTED preset on the xyz.com row. "Allow xyz.com" (permanently) maps to clicking the clock-shaped icon onto the TRUSTED preset (which means "Temporary"), to disable it (and make the preset assignment "Permanent") "Forbid xyz.com" maps to clicking the DEFAULT preset, which actually means deleting the site from the internal "whitelist". In facts, if you do it in the general Options panel, next time you open the panel (or refresh it) the site is not even listed there anymore. It doesn't disappear right away for convenience, to give you the chance to change your mind or correct mistakes. "Mark xyz.com as untrusted" maps to clicking the UNTRUSTED preset, which contains no permission at all and is meant to collect and remember the "known bad sites" in a permanent blacklist. And then CUSTOM, which is new to NoScript 10 and lets you fine tune just a certain website with its own specific permissions, either more restrictive than DEFAULT or more permissive than TRUSTED ; this tuning is either permanent (by default, the clock shaped icon in this case comes disabled) or temporary, by additionally clicking the clock-shaped icon. Each and all the presets can be freely customized to your own needs, with the convenience constraint that you cannot remove the "script" permission from TRUSTED, and you cannot add it to UNTRUSTED. However, the factory presets are very similar to the "old" NoScript experience. What about the "Match HTTPS only" green/red lock toggle? If green (locked), the toggle makes base domain entries (e.g. "..google.com") match themselves and all their subdomains, but only if their protocol is HTTPS (and therefore the traffic encrypted and not easily tampered with). Otherwise, if red and unlocked, both HTTP and HTTPS match: this has bad security implications especially on "hostile" networks where injecting malicious scripts directly in the unencrypted traffic is relatively easy, but is unfortunately needed for some sites to work. NoScript tries to gives you the "smartest" default for each site, i.e. green if the page is already served on HTTPS, red otherwise. A lot more needs to be written yet, but these are the bare bones. If you find bugs or need support, rather than using in the blog comments or, even worse, the AMO review system as a way to communicate with developers, please submit to the support forum here. And if you want to help me with development, please install latest development build, which is released even more often than the stable and ships earlier both bug fixes and new features. And please keep providing feedback, as especially the UI is still a work in progress and I'm eager to make it better than before, by merging as much as possible of your valuable contributions. Thank you all! [Less]