Subscribe: Planet Mozilla
Added By: Feedage Forager Feedage Grade B rated
Language: English
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Planet Mozilla

Planet Mozilla

Planet Mozilla -


Gervase Markham: Root Store Policy 2.5 Published

Fri, 23 Jun 2017 16:00:57 +0000

Version 2.5 of Mozilla’s Root Store Policy has now been published. This document incorporates by reference the Common CCADB Policy 1.0.1.

With this update, we have mostly worked through the backlog of modernization proposals, and I’d call this a policy fit for a transparent, openly-run root program in 2017. That doesn’t mean that there’s not more that could be done, but we’ve come a long way from policy 2.2, which we were using until six months ago, and which hadn’t been substantively updated since 2012.

We also hope that, very soon, more root store operators will join the CCADB, which will reduce everyone’s costs and administrative burdens on all sides, and hopefully allow root programs to be more responsive to changing circumstances and requests for inclusion or change.


Alessio Placitelli: Getting Firefox data faster: the shutdown pingsender

Fri, 23 Jun 2017 15:54:07 +0000

The data our Firefox users share with us is the key to identify and fix performance issues that lead to a poor browsing experience. Collecting it is not enough if we don’t manage to receive the data in an acceptable time-frame. My esteemed colleague Chris already wrote about this a couple of times: data latency … 

Hacks.Mozilla.Org: An inside look at Quantum DOM Scheduling

Fri, 23 Jun 2017 14:56:16 +0000

Use of multi-tab browsing is becoming heavier than ever as people spend more time on services like Facebook, Twitter, YouTube, Netflix, and Google Docs, making them a part of their daily life and work on the Internet. Quantum DOM: Scheduling is a significant piece of Project Quantum, which focuses on making Firefox more responsive, especially when lots of tabs are open. In this article, we’ll describe problems we identified in multi-tab browsing, the solutions we figured out, the current status of Quantum DOM, and opportunities for contribution to the project. Problem 1: Task prioritization in different categories Since multiprocess Firefox (e10s) was first enabled in Firefox 48, web content tabs now run in separate content processes in order to reduce overcrowding of OS resources in a given process. However, after further research, we found that the task queue of the main thread in the content process was still crowded with tasks in multiple categories. The tasks in the content process can come from a number of possible sources: through IPC (interprocess communication) from the main process (e.g. for input events, network data, and vsync), directly from web pages (e.g. from setTimeout, requestIdleCallback, or postMessage), or internally in the content process (e.g. for garbage collection or telemetry tasks). For better responsiveness, we’ve learned to prioritize tasks for user inputs and vsync above tasks for requestIdleCallback and garbage collection. Problem 2: Lack of task prioritization between tabs Inside Firefox, tasks running in foreground and background tabs are executed in First-Come-First-Served order, in a single task queue. It is quite reasonable to prioritize the foreground tasks over than the background ones, in order to increase the responsiveness of the user experience for Firefox users. Goals & solutions Let’s take a look at how we approached these two scheduling challenges, breaking them into a series of actions leading to achievable goals: Classify and prioritize tasks on the main thread of the content processes in 2 dimensions (categories & tab groups), to provide better responsiveness. Preempt tasks that are running the background tabs if this preempting is not noticeable to the user. Provide an alternative to multiple content processes (e10s multi) when fewer content processes are available due to limited resources. Task categorization To resolve our first problem, we divide the task queue of the main thread in the content processes into 3 prioritized queues: High (User Input and Refresh Driver), Normal (DOM Event, Networking, TimerCallback, WorkerMessage), and Low (Garbage Collection, IdleCallback). Note: The order of tasks of the same priority is kept unchanged. Task grouping Before describing the solution to our second problem, let’s define a TabGroup as a set of open tabs that are associated via window.opener and window.parent. In the HTML standard, this is called a unit of related browsing contexts. Tasks are isolated and cannot affect each other if they belong to different TabGroups. Task grouping ensures that tasks from the same TabGroup are run in order while allowing us to interrupt tasks from background TabGroups in order to run tasks from a foreground TabGroup. In Firefox internals, each window/document contains a reference to the TabGroup object it belongs to, which provides a set of useful dispatch APIs. These APIs make it easier for Firefox developers to associate a task with a particular TabGroup. How tasks are grouped inside Firefox Here are several examples to show how we group tasks in various categories inside Firefox: Inside the implementation of window.postMessage(), an asynchronous task called PostMessageEvent will be dispatched to the task queue of the main thread: void nsGlobalWindow::PostMessageMozOuter(...) {   ...  RefPtr event = new PostMessageEvent(...);   NS_DispatchToCurrentThread(event); } With the new association of DOM windows to their TabGroups and the new dispat[...]

Carsten Book: Sheriff Survey Results

Fri, 23 Jun 2017 12:39:21 +0000

first a super big thanks for taking part in this years Sheriff Survey – this helps us a lot !
Here are the results.
1. Overall “satisfaction” – we have asked how People rate their interaction with us (from 1 (bad) to 10 (best)
So far from all results:
3,1 % = 5
3,1 % = 7
12,5 % = 8
43,8 % = 9
37,5 % = 10
2. What can we do better  as Sheriffs?
We got a lot of Feedback thats its not easy to find out who is on “sheriffduty”. We will take steps (like adding |sheriffduty tag to irc names etc) also we have with the target to have that name on treeherder.
Also we try to make sure to Set Needinfo requests on Backouts.
In any case, backouts are never meant to be personal and it’s part of our job to try our best to keep our trees open for developers. We also try to provide as much information as possible in the bug for why we
backed out a change.
3. Things we can improve in general (not just sheriffs) ?
A interesting Idea in the Feedback we got was about Automation. We will follow up from the Feedback and i already filed for the Idea of having a “Backout Button” in Treeherder in case no Sheriff is around etc – more bugs from ideas to improve general stuff and workflows will follow.
Again thanks for taking part in the Survey and if you have questions/feedback/concerns/ideas you can of course contact me / the team at anytime !
– Tomcat

Doug Belshaw: "And she turned round to me and said..."

Fri, 23 Jun 2017 10:54:54 +0000

I’d always assumed that my grandmother’s use of the sentence starter in this post’s title came from her time working in factories. I imagined it being reference to someone turning around on the production line to say something bitchy or snarky. It turns out, however, that the phrase actually relates to performing a volte face. In other words it’s a criticism of someone changing their opinion in a way that others find hypocritical. This kind of social judgement plays an important normative role in our society. It’s a delicate balance: too much of it and we feel restricted by cultural norms; not enough, and we have no common touchstones, experiences, and expectations. I raise this as I feel we’re knee-deep in developments happening around the area that can broadly considered ‘notification literacy’. There’s an element of technical understanding involved here, but on a social level it could be construed as walking the line between hypocrisy and protecting one’s own interests. Let’s take the example of Facebook Messenger: The Sending… / Sent / Delivered / Read icons serve as ambient indicators that can add value to the interaction. However, that value is only added, I’d suggest, if the people involved in the conversation know how the indicators work, and are happy to ‘play by the rules of the game’. In other words, they’re in an active, consensual conversation without an unbalanced power dynamic or strained relationship. I choose not to use Facebook products so can’t check directly, but I wouldn’t be surprised if there’s no option to turn off this double-tick feature. As a result, users are left in a quandry: do they open a message to see a message in full (and therefore show that they’ve seen it), or do they just ignore it (and hope that the person goes away)? I’ve certainly overheard several conversations about how much of a difficult position this can be for users. Technology solves as well as causes social problems. A more nuanced approach is demonstrated by Twitter’s introduction of the double-tick feature to their direct messaging (DM). In this case, users have the option to turn off these ‘read receipts’. As I have this option unchecked, people who DM me on Twitter can’t see whether or not I’ve read their message. This is important, as I have ‘opened up’ my DMs, meaning anyone on Twitter can message me. Sometimes, I legitimately ignore people’s messages after reading them in full. And because I have read receipts (‘double ticks’) turned off, they’re none the wiser. Interestingly, some platforms have gone even further than this. Path Messenger, for example, has experimented with allowing users to share more ambient statuses: This additional ambient information can be shared at the discretion of the user. It can be very useful in situations where you know the person you’re interacting with well. In fact, as Path is designed to be used with your closest contacts, this is entirely appropriate. I think we’re still in a transition period with social networks and norms around them. These, as with all digital literacies, are context-dependent, so what’s acceptable in one community may be very different to what’s acceptable in another. It’s going to be interesting to see how these design patterns evolve over time, and how people develop social norms to deal with them. Comments? Questions? Write your own blog post referencing this one, or email me: [...]

Mozilla Reps Community: New Council Members – Spring 2017

Fri, 23 Jun 2017 09:39:39 +0000

We are very happy to announce that our new council members are already onboarded and working on their focus areas.

We are also extremely happy with the participation we had for these elections as for the first time we had the record number of 12 nominees and 215 (75% of the body)  have voted.



Welcome Ankit, Daniele, Elio, Faye, and Flore, we are very excited to have you onboard.

Here are the areas that each of the new council members will work on:

  • Flore – Resources
  • Faye – Coaching
  • Ankit  -Activate
  • Elio – Communications
  • Daniele – onboarding

Of course they will also all co-work with the old council members on the program’s strategy and implementation bringing the Reps Program forward.

Also I would like to thank and send #mozlove to Adriano, Ioana, Rara and Faisal for all their hard work during their term as Reps Councils Members. Your work has been impactful and appreciated and we can’t thank you enough.

The Mozilla Reps Council is the governing body of the Mozilla Reps Program. It provides the general vision of the program and oversees day-to-day operations globally. Currently, 7 volunteers and 2 paid staff sit on the council. Find out more on the Reps wiki.

Don’t forget to congratulate the new Council members on the Discourse topic!


Ehsan Akhgari: Quantum Flow Engineering Newsletter #14

Fri, 23 Jun 2017 07:13:10 +0000

We have about 13 more weeks before the train of Firefox 57 leaves the station.  Next week many of you will be at the upcoming work week, so I thought it may be a good time to have some retrospection over our progress so far, just so that you can get a good sense of how to extrapolate when you are planning things next week. One difficulty with the Quantum Flow project is that since it touches many different areas of the browser, it doesn’t lend itself very easily to drawing nice charts for it.    It is hard to find one metric that all of this work fits inside, and that’s OK.  My goal this week is to highlight what we can achieve with focus in a limited amount of time, so I’ll bring a couple of examples. This is a snapshot of our burndown chart1.  We currently have 182 closed bugs and 136 open bugs.  That’s great progress, and I’d like to thank everyone who helped with all aspects of this! But to speak of a more direct measurement of performance, let’s look at our progress on Speedometer V2.  Today, I measured our progress so far on this benchmark by comparing Firefox 53, 54, 55.0b3 (latest beta as of this writing) and the latest Nightly, all x64 builds, on the reference hardware.  This is the result (numbers are the reported benchmark score, higher is better): There are also many other top level performance related projects that are ongoing and approaching final stages.  I’m really excited to see what the next few months are going to uncover for Firefox performance. One bit of administrative note, as next week most people are able to get updates from each other face to face, I won’t send out the newsletter.  Now let’s finish with this week’s list of acknowledgements to those who helped make Firefox faster during the past week, hopefully I’m not forgetting any names! Jan de Mooij optimized object property enumeration with great results.  He finished his ongoing optimization effort on adding/defining properties.  He also reordered the checks in ValueToId() and ValueToIdPure() to cover the more common cases first.  He then moved the object/string pre-barrier null check to JIT code.  This speeds up initializing unboxed objects. Makoto Kato improved the performance of HTMLInputElement.value setters by avoiding doing some unnecessary work. Alessio Placitelli deferred querying whether we’re the default browser to until after session restore completes in order to avoid potential startup slowdown issues. Markus Stange made arrow panel animations much more efficient on macOS! Doug Thayer made it so that we shrink the Places SQLite database off of the main thread, avoiding some jank when hitting memory pressure. Jonathan Kew switched to using a faster API for retrieving font glyph advances instead of all glyph metrics on DirectWrite. Mark Banner converted the bookmarks backup code to use the new asynchronous bookmarks API. Matthew Noorenberghe made the context menu code lazily import LoginManagerContextMenu.jsm and InlineSpellChecker.jsm at startup. Florian Quèze avoided attaching an XBL binding to hidden elements to improve startup performance. Boris Zbarsky avoided querying the preferences service to determine whether interface enablement conditions are met. Jonathan Watt optimized calls to nsUXThemeData::InitTitlebarInfo(), improving the performance of opening a window on Windows. Nicholas B. Pierron enabled backtracking to a normal call when inlining fails in IonMonkey. Mats Palmgren continued his battle on unnecessary hashtable lookups.  He added a couple of new APIs for adding and removing entries on nsTHashtable which return values indicating whether they changed the hashtable, which allow rewriting patterns where code currently does two hashtable lookups, first to check whether an entry exists in the hashtable and then to add/remove it (which incurs a second lookup on the same entry).  He then followed [...]

Justin Dolske: Photon Engineering Newsletter #7

Fri, 23 Jun 2017 05:34:46 +0000

Lucky you, here’s Photon update #7! Let’s start off with a fresh new video that gives an overview of what we’re doing with the Quantum and Photon projects. If you’re not already running Nightly, but are willing to live on the cutting-edge, this would be a great time to give it a spin! Get involved to help us test out everything that’s new, and experience some of these great improvements first-hand!   Mozilla All-Hands Next week, everyone at Mozilla will be gathering in San Francisco for our biannual All-Hands meeting. The Photon team will be using it as a repeat of our Toronto Work Week (as covered in Photon Update #2). So we’re going to be super-busy hacking on Photon. We’ve got even more great stuff coming up, and I can’t wait to talk about it in Photon Update #8. But… The intense focus means that I might not get that update out until the following week. I think the wait will be worth it.   Recent Changes Menus/structure: As mentioned in the last update, the Photon menus/structure pref has been enabled by default on Nightly. We’ve had a number of issues filed by Nightly users (thanks for the bug reports!), and fortunately the were no huge surprises. As a bonus, Talos reported performance wins from the new menus. The library panel now has a “View Pocket List” item and looks more polished. The synced tabs view also got a small update. Subviews in menu panels now scroll correctly when necessary. (You can see this, for example, in the History view when you have lots of history entries.) Coming soon: more updates to the library panel, page action panel, and moving the bookmarks star (back) to the URL bar.   Animation: Updated arrow-panel animations are going through review this week. Users on macOS will notice that panel open/close animations are much smoother, as a result of a platform fix. (You’ll see more improvements soon, from the item above, as well as another platform fix to add a beautiful background blur to the panel). Work continues on animations for the downloads toolbar button, stop/reload button, and page loading indicator.   Preferences: The revised reorganization is actively being worked on, and is undergoing review this week. Search in preferences was enabled by default in Nightly. Searching now highlights matching menuitems with an arrow, and works inside subdialogs.   Visual redesign: Another community contribution: Oriol removed an small, unexpected line that was appearing at the top of some windows. Thanks for the patch! Firefox will now automatically enable its touch mode (which increases the size of various UI to make it more touch-friendly) when used in Windows 10 Tablet mode. The dark toolbar that previously landed for Windows 10 is now coming to macOS. (This just landed, and if it sticks will be in Friday’s Nightly build.)   Onboarding: The onboarding tour content has landed and been polished to match the UI spec. You can click the Fox icon in about:home to give it a try! Currently it has 5 tours for existing (non-Photon) features — Private Browsing, Add-ons, Customization, Searching, and setting your Default Browser. These are planned to ship in Firefox 56 (for users installing Firefox for the first time). Additional tours will next be implemented for Firefox 57, to introduce new Photon features to existing Firefox users. The onboarding tour now has UI to allow hiding it (so users who don’t want to go through each tour step can just make it go away). The Mozilla logo and onboarding icon are now shown on the correct sides for RTL languages. A Sync tour and tour notifications will be landing soon.   Performance: Places (our bookmarks and history storage system) is now initialized after first paint on startup. This helps make Firefox feel faster to launch, because the window will be shown sooner. More giant patches up for review for removal of Task.jsm calls, [...]

Tarek Ziadé: Advanced Molotov example

Thu, 22 Jun 2017 22:00:00 +0000

Last week, I blogged about how to drive Firefox from a Molotov script using Arsenic. It is pretty straightforward if you are doing some isolated interactions with Firefox and if each worker in Molotov lives its own life. However, if you need to have several "users" (==workers in Molotov) running in a coordinated way on the same web page, it gets a little bit tricky. Each worker is its coroutine and triggers the execution of one scenario by calling the coroutine that was decorated with @scenario. Let's consider this simple use case: we want to run five workers in parallel that all visit the same etherpad lite page with their own Firefox instance through Arsenic. One of them is adding some content in the pad and all the others are waiting on the page to check that it is updated with that content. So we want four workers to wait on a condition (=pad written) before they make sure and check that they can see it. Moreover, since Molotov can call a scenario many times in a row, we need to make sure that everything was done in the previous round before changing the pad content again. That is, four workers did check the content of the pad. To do all that synchronization, Python's asyncio offers primitives that are similar to the one you would use with threads. asyncio.Event can be used for instance to have readers waiting for the writer and vice-versa. In the example below, a class wraps two Events and exposes simple methods to do the syncing by making sure readers and writer are waiting for each other: class Notifier(object): def __init__(self, readers=5): self._current = 1 self._until = readers self._readers = asyncio.Event() self._writer = asyncio.Event() def _is_set(self): return self._current == self._until async def wait_for_writer(self): await self._writer.wait() async def one_read(self): if self._is_set(): return self._current += 1 if self._current == self._until: self._readers.set() def written(self): self._writer.set() async def wait_for_readers(self): await self._readers.wait() Using this class, the writer can call written() once it has filled the pad and the readers can wait for that event by calling wait_for_writer() which blocks until the write event is set. one_read() is then called for each read. This second event is used by the next writer to make sure it can change the pad content after every reader did read it. So how do we use this class in a Molotov test? There are several options and the simplest one is to create one Notifier instance per run and set it in a variable: @molotov.scenario(1) async def example(session): get_var = molotov.get_var notifier = get_var('notifier' + str(session.step), factory=Notifier) wid = session.worker_id if wid != 4: # I am NOT worker 4! I read the pad # wait for worker #4 to edit the pad await notifier.wait_for_writer() # <.. pad reading here...> # notify that we've read it await notifier.one_read() else: # I am worker 4! I write in the pad if session.step > 1: # waiting for the previous readers to have finished # before we start a new round previous_notifier = get_var('notifier' + str(session.step)) await previous_notifier.wait_for_readers() # <... writes in the pad...> # informs that the write task was done notifier.written() A lot is going on in this scenario. Let's look at each part in detail. First of all, the notifier is created as a var via set_var(). Its name contains the session step. The step value is incremented by Molotov every time a worker is running a scenario, and we can use that valu[...]

Firefox UX: Let‘s tackle the same challenge again, and again.

Thu, 22 Jun 2017 19:12:07 +0000

Actually, let’s not!The products we build get more design attention as our Firefox UX team has grown from about 15 to 45 people. Designers can now continue to focus on their product after the initial design is finished, instead of having to move to the next project. This is great as it helps us improve our products step by step. But this also leads to increasing efforts to keep this growing team in sync and able to timely answer all questions posed to us.Scaling communication from small to big teams leads to massive effort for a few.Especially for engineers and new designers it is often difficult to get timely answers to simple questions. Those answers are often in the original spec, which too often is hard to locate. Or worse, it may be in the mind of the designer, who may have left, or receives too many questions to respond timely.In a survey we ran in early 2017, developers reported to feel theyspend too much time identifying the right specs to build from,spend too much time waiting for feedback from designers, andspend too much time mapping new designs to existing UI elements.In the same survey designers reported to feel theyspend too much time identifying current UI to re-use in their designs, andspend too much time re-building current UI to use in their designs.All those repetitive tasks people feel they spend too much time on ultimately keep us from tackling newer and bigger challenges. ‒ So, actually, let‘s not spend our time on those.Let’s help people spend time on what they love to do.Shifting some communication to a central tool can reduce load on people and lower the barrier for entry.Let’s build tools that help developers know what a given UI should look like, without them needing to wait for feedback from designers. And let’s use that system for designers to identify UI we already built, and to learn how they can re-use it.We call this the Photon Design System, and its first beta version is ready to be used: are happy to receive feedback and contributions on the current content of the system, as well as on what content to add next.Photon Design SystemBased on what we learned from people, we are building our design system to help people:find what they are looking for easily,understand the context of that quickly, andmore deeply understand Firefox Design.Currently the Photon Design System covers fundamental design elements like icons, colors, typography and copy-writing as well as our design principles and guidelines on how to design for scale. Defining those already helped designers better align across products and features, and developers have a definitive source to fall back to when a design does not specify a color, icon or other.GrowthWith all the design fundamentals in place we are starting to combine them into defined components that can easily be reused to create consistent Firefox UI across all platforms, from mobile to desktop, and from web-based to native. This will add value for people working on Firefox products, as well as help people working on extensions for Firefox.If you are working on Firefox UIWe would love to learn from you what principles, patterns & components your team’s work touches, and what you feel is worth documenting for others to learn from, and use in their UI.Share your principle/pattern/component with us!And if you haven’t yet, ask yourself where you could use what’s already documented in the Photon Design System and help us find more and more synergies across our products to utilize.If you are working on a Firefox extensionWe would love to learn about where you would have wanted design support when building your extension, and when you had to spend more time on design then you intended to.Share with us!Let‘s tackle the same chal[...]

Mozilla Open Design Blog: MDN’s new design is in Beta

Thu, 22 Jun 2017 17:46:43 +0000

Change is coming to MDN. In a recent post, we talked about updates to the MDN brand, and this time we want to focus on the upcoming design changes for MDN. MDN started as a repository for all Mozilla documentation, but today MDN’s mission is to provide developers with the information they need to build things on the open Web. We want to more clearly represent that mission in the naming and branding of MDN.


MDN’s switch to new branding reflects an update of Mozilla’s overall brand identity, and we are taking this opportunity to update MDN’s visual design to match Mozilla’s design language and clean new look. For MDN that means bold typography that highlights the structure of the page, more contrast, and a reduction to the essentials. Color in particular is more sparingly used, so that the code highlighting stands out.

Here’s what you can expect from the first phase:


New MDN design

The core idea behind MDN’s brand identity change is that MDN is a resources for web developers. We realize that MDN is a critical resource for many web developers and we want to make sure that this update is an upgrade for all users. Instead of one big update, we will make incremental changes to the design in several phases. For the initial launch, we will focus on applying the design language to the header, footer and typography. The second phase will see changes to landing pages such as the web platform, learning area, and MDN start page. The last part of the redesign will cover the article pages themselves, and prepare us for any functional changes we’ve got coming in the future.

Today, we are launching the first phase of the redesign to our beta users. Over the next few weeks we’ll collect feedback, and fix potential issues before releasing it to all MDN users in July. Become a beta tester on MDN and be among the first to see these updates, track the progress, and provide us with feedback to make the whole thing even better for the official launch.

The post MDN’s new design is in Beta appeared first on Mozilla Open Design.

Air Mozilla: Mozilla Gigabit Eugene Open House

Thu, 22 Jun 2017 16:00:00 +0000

(image) Hello Eugene, Oregon! Come meet with local innovators, educators, entrepreneurs, students, and community advocates and learn about what it means to be a “Mozilla Gigabit...

Air Mozilla: Gigabit Community Fund June 2017 RFP Webinar

Thu, 22 Jun 2017 15:13:28 +0000

(image) This summer, we're launching a new round of the Mozilla Gigabit Community Fund. We're funding projects that explore how high-speed networks can be leveraged for...

Hacks.Mozilla.Org: Powerful New Additions to the CSS Grid Inspector in Firefox Nightly

Thu, 22 Jun 2017 15:00:44 +0000

CSS Grid is revolutionizing web design. It’s a flexible, simple design standard that can be used across all browsers and devices. Designers and developers are rapidly falling in love with it and so are we. That’s why we’ve been working hard on the Firefox Developer Tools Layout panel, adding powerful upgrades to the CSS Grid Inspector and Box Model. The latest improvements are now available in Firefox Nightly. Layout Panel Improvements The new Layout Panel lists all the available CSS Grid containers on the page and includes an overlay to help you visualize the grid itself. Now you can customize the information displayed on the overlay, including grid line numbers and dimensions. This is especially useful if you’re still getting to know CSS Grid and how it all works. There’s also a new interactive grid outline in the sidebar. Mouse over the outline to highlight parts of the grid on the pages and display size, area, and position information. The new “Display grid areas” setting shows the bounding areas and the associated area name in every cell. This feature was inspired by CSS Grid Template Builder, which was created by Anthony Dugois. Finally, the Grid Inspector is capable of visualizing transformations applied to the grid container. This lets developers accurately see where their grid lines are on the page for any grids that are translated, skewed, rotated or scaled. Improved Box Model Panel We also added a Box Model Properties component that lists properties that affect the position, size and geometry of the selected element. In addition, you’ll be able to see and edit the top/left/bottom/right position and height/width properties—making live layout tweaks quick and easy. Finally, you’ll also be able to see the offset parent for any positioned element, which is useful for quickly finding nested elements. As always, we want to hear what you like or don’t like and how we can improve Firefox Dev Tools. Find us on Discourse or @firefoxdevtools on twitter. Thanks to the Community Many people were influential in shipping the CSS Layout panel in Nightly, especially the Firefox Developer Tools and Developer Relations teams. We thank them for all their contributions to making Firefox awesome. We also got a ton of help from the amazing people in the community, and participants in programs like Undergraduate Capstone Open Source Projects (UCOSP) and Google Summer of Code (GSoC). Many thanks to all the contributors who helped land features in this release including: Micah Tigley – Computer science student at the University of Lethbridge, Winter 2017 UCOSP student, Summer 2017 GSoC student. Micah implemented the interactive grid outline and grid area display. Alex Lockhart – Dalhousie University student, Winter 2017 UCOSP student. Alex contributed to the Box Model panel with the box model properties and position information. Sheldon Roddick –  Student at Thompson Rivers University, Winter 2017 UCOSP student. Sheldon did a quick contribution to add the ability to edit the width and height in the box model. If you’d like to become a contributor to Firefox Dev Tools hit us up on GitHub or Slack or #devtools on Here you will find all the resources you need to get started.[...]

Air Mozilla: Reps Weekly Meeting Jun. 22, 2017

Thu, 22 Jun 2017 14:00:00 +0000

(image) This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Dustin J. Mitchell: Taskcluster Manual Revamp

Thu, 22 Jun 2017 11:22:00 +0000

As the Great Taskcluster Migration draws near the finish line, we are seeing people new to Taskcluster and keen to take advantage of its new features every day. It’s exciting to build something with such expressive power: easy-to-use loaners, automatic toolchain builds, and a simple process for adding new tests, to name just a few.

We have long had a thorough reference section, with technical details of the various microservices and workers that comprise Taskcluster, but that information is a bit too deep for a newcomer. A few years ago, we introduced a tutorial to guide the beginning user to the knowledge they need for their use-case, but the tutorial only goes so far.

Daniele Procida gave a great talk at PyCon 2017 about structuring documentation, which came down to this diagram:

 Tutorials   | How-To Guides 
 Discussions | Reference     

This shows four types of documentation. The top is practical, while the bottom is more theoretical. The left side is useful for learning, while the right side is useful when trying to solve a problem. So the missing components are “discussion” and “how-to guides”. Daniele’s “discussions” means prose-style expositions of a system, organized to increase the reader’s understanding of the system as a whole.

Taskcluster has had a manual for quite a while, but it did not really live up to this promise. Instead, it was a collection of documents that didn’t fit anywhere else.

Over the last few months, we have refashioned the manual to fit this form. It now starts out with a gentle but thorough description of tasks (the core concept of Taskcluster), then explains how tasks are executed before delving into the design of the system. At the end, it includes a bunch of use-cases with advice on how to solve them, filling the “how-to guides” requirement.

If you’ve been looking to learn more about Taskcluster, check it out!

Mozilla Reps Community: RepsNext – Status Update June 2017

Thu, 22 Jun 2017 10:19:11 +0000

In the past few months we have kept working on the implementation of our RepsNext initiative. The RepsNext initiative has started more than a year ago with the goal to bring the Mozilla Reps program to the next level. Back in January we wrote a status update. Almost half a year later, we want to provide a further update. We have also published our OKRs for the current quarter with goals to further the implementation of RepsNext. Resources The Resources training is finalized. It’s still a little bit text-heavy, but we want to move forward with the training and iterate based on feedback. For this, we have reached out to a few selected Reps based on the past 6 months to ask them to test the training and give initial feedback about the process and content. Once we have this feedback, we will adjust the training if needed and then open up the Resources track for applications. Applications will most probably be done in a Google Form and will include general info about the Rep as well as a free-text input field where the Rep can explain why they are fitted for the track as well as provide some links to previous, good budget requests they filed. You can learn more about the Resources Track on the Resources Wiki page. Onboarding Process We have simplified and streamlined the on-boarding process for new Reps. Until April we had a lot of applications that were open for more than 6 months. We are happy to report that we have started to on-board 20 new Reps between April and now. Further 10 Reps are in the administrative process of signing the agreement and creating profiles on the Portal. All of this is thanks to a new Webinar. The Webinar allows us to give Reps the very needed first information about Reps and what to expect being a Rep. Participation Alignment The Council is working with the Participation team in order to co-create the quarterly and yearly goals and OKRs for 2017. This happened twice already this year and we will continue to give our valuable input and feedback for the quarters to come. The program’s goals are also being created based the team’s goals and priorities. We are also attending the monthly Open Innovation Team calls. Of course this is an ongoing work that will continue. The Reps Council is also involved in strategic and operational discussions as representatives for the broader community, giving feedback on the currently ongoing strategic projects. All of this work will continue at the All Hands in San Francisco later this month. Leadership At the beginning of our work on RepsNext, we wanted to do a specific Leadership Track Reps can apply for as a specialization. Throughout the past months it became clear that we want all Reps to improve their leadership skills to help out other Reps as well as their communities. Therefore we created an initial list of good leadership resources for everyone to access and learn. At first this is a basic list of resources which will be improved on in the future. We want all Reps to be able to improve their leadership skills as soon as possible and later build on top of this knowledge with further resources. Please provide your feedback in the Discourse topic! Coaching Previously known as Regional Coaches, Community Coaches will continue to support local communities. Additionally to that we are currently creating a Coaches Training to train new Reps on coaching skills as well as existing mentors to improve their skills. These coaches will be able to coach Reps in regards to personal development. The idea is to have the Coaches Training on a self-serve basis, so everyone can take the training and complete a nar[...]

Alex Vincent: Validating directory inputs?

Thu, 22 Jun 2017 07:38:11 +0000

A quick thought here.  I spent several hours today trying to figure out why a simple Firefox toolkit application wouldn’t work.  (I don’t know what to call “-app application.ini” applications anymore, as “XULRunner” has definitely fallen from favor…)  It took me far too long to realize that the “default” subdirectory should’ve been named “defaults” – something that I already know about these apps, but I only build them from scratch every two years or so…

Catching this sort of rookie mistake is, fundamentally, an argument validation exercise:  the main difference is instead of the argument being an object of some kind, it’s a directory on the filesystem.  If Mozilla has a module or component for validating a directory’s structure in general, I haven’t heard of it…

Which is the point of my post here.  I’m wondering what general-purpose libraries exist for validating a directory tree’s structure and contents at a basic level.  Somebody out there must have run into this problem before and created libraries for this.  I’d love to see libraries written in C++, D, Python, NodeJS and/or privileged JavaScript.  Please reply to my post if you can point me to them.  (For once, a quick search on the world’s most popular search engine fails me…)  Bonus points for libraries that allow passing in callbacks for file-specific validation. (“Is there a syntactically correct .ini file at (root)/application.ini?”)

Air Mozilla: Community Participation Guidelines Revision Brownbag (APAC)

Wed, 21 Jun 2017 20:00:00 +0000

(image) A revised version of Mozilla's Community Participation Guidelines was released in May 2017. Please join Larissa Shapiro (Head of D&I) and Lizz Noonan (D&I Coordinator)...

Air Mozilla: The Joy of Coding - Episode 103

Wed, 21 Jun 2017 17:00:00 +0000

(image) mconley livehacks on real Firefox bugs while thinking aloud.

Mozilla Addons Blog: Upcoming changes for add-on usage statistics

Wed, 21 Jun 2017 15:44:40 +0000

We’re changing the way we calculate add-on usage statistics on AMO so they better reflect their real-world usage. This change will go live on the site later this week.

The user count is a very important part of AMO. We show it prominently on listing and search pages. It’s a key factor of determining add-on popularity and search ranking.


However, there are a couple of problems with it:

  • We count both enabled and disabled installs. This means some add-ons with high disable rates have a higher ranking than they should.
  • It’s an average over a period of several weeks. Add-ons that are rapidly growing in users have user numbers that are lagging behind.

We’ll be calculating the new average based on enabled installs for the past two weeks of activity. We believe this will reflect add-on usage more accurately.

What it means for add-on developers

We expect most add-ons to experience a small drop in their user numbers, due to the removal of disabled installs. Most add-on rankings on AMO won’t change significantly. This change also doesn’t affect the detailed statistics dashboard developers have access to. Only the number displayed on user-facing sections of the site will change.

If you notice any problems with the statistics or anything else on AMO, please let us know by creating an issue.

The post Upcoming changes for add-on usage statistics appeared first on Mozilla Add-ons Blog.

Hacks.Mozilla.Org: Designing for performance: A data-informed approach for Quantum development

Wed, 21 Jun 2017 14:56:07 +0000

When we announced Project Quantum last October, we talked about how users would benefit from our focus on “performance gains…that will be so noticeable that your entire web experience will feel different.” We shipped the first significant part of this in Firefox 53, and continue to work on the engineering side. Now let’s dive into the performance side and the work we’re doing to ensure that our users will enjoy a faster Web experience. What makes work on performance so challenging and why is it so important to include the user from the very beginning? Performance — a contested subject, to say the least! Awareness of performance as a UX issue often begins with a negative experience – when things get slow or don’t work as expected. In fact, good performance is already a table stake, something that everyone expects from an online product or service. Outstanding performance will very soon become the new baseline point of reference. The other issue is that there are different perspectives on performance. For users, performance is about their experience and is very often unspecific. For them, perception of good performance can range from “this is amazingly fast” to “SLOW!”, from “WOW!” to “NO!”. For engineers, performance is about numbers and processes. The probes that collect data in the code often measure one specific task in the pipeline. Measuring and tracking capabilities like Garbage Collection (GC) enables engineers to react to regressions in the data quickly, and work on fixing the root causes. This is why there can be a disconnect between user experience and engineering efforts at mitigation. We measure garbage collection, but it’s often measured without context, such as whether it runs during page load, while the user interacts with a website, or during event queue idle time. Often, GC is within budget, which means that users will hardly perceive it. More generally, specific aspects of what we measure with our probes can be hard to map to the unspecific experience of performance that users have. Defining technical and perceived performance To describe an approach for optimizing performance for users, let us start by defining what performance means. For us, there are two sides to performance: technical performance and perceived performance. Under technical performance, we include the things that we can measure in the browser: how long page elements take to render, how fast we can parse JavaScript or — and that is often more important to understand — how slow certain things are. Technical performance can be measured and the resulting data can be used to investigate performance issues. Technical performance represents the engineer’s viewpoint. On the other hand, there is the topic of how users experience performance. When users talk about their browser’s performance, they talk about perceived performance or “Quality of Experience” (QoE). Users express QoE in terms of any perceivable, recognized, and nameable characteristic of the product. In the QoE theory, these are called QoE features. We may assume that these characteristics are related to factors in the product that impact technical performance, the QoE factors, but this is not necessarily given. A promising approach to user-perceived optimization of performance is to identify those factors that have the biggest impact on QoE features and focus on optimizing their technical performance. Understanding perception The first step towa[...]

Air Mozilla: Community Participation Guidelines Revision Brownbag (EMEA)

Wed, 21 Jun 2017 14:00:00 +0000

(image) A revised version of Mozilla's Community Participation Guidelines was released in May 2017. Please join Larissa Shapiro (Head of D&I) and Lizz Noonan (D&I Coordinator)...

The Mozilla Blog: A $2 Million Prize to Decentralize the Web. Apply Today

Wed, 21 Jun 2017 11:30:48 +0000

We’re fueling a healthy Internet by supporting big ideas that keep the web accessible, decentralized and resilient. What will you build?   Mozilla and the National Science Foundation are offering a $2 million prize for big ideas that decentralize the web. And we’re accepting applications starting today. Mozilla believes the Internet is a global public resource that must be open and accessible to all.  In the 21st century, a lack of Internet access is far more than an inconvenience — it’s a staggering disadvantage. Without access, individuals miss out on substantial economic and educational opportunities, government services and the ability to communicate with friends, family and peers. Currently, 34 million people in the U.S. — 10% of the country’s population — lack access to high-quality Internet connectivity. This number jumps to 39% in rural communities and 41% on Tribal lands. And when disasters strike, millions more can lose vital connectivity right when it’s needed most. To connect the unconnected and disconnected across the U.S., Mozilla today is accepting applications for the Wireless Innovation for a Networked Society (WINS) challenges. Sponsored by NSF, a total of $2 million in prize money is available for wireless solutions that get people online after disasters, or that connect communities lacking reliable Internet access. The details: Off-the-Grid Internet Challenge When disasters like earthquakes and hurricanes strike, communications networks are among the first pieces of critical infrastructure to overload or fail. How can we leverage both the Internet’s decentralized design and current wireless technology to keep people connected to each other — and vital messaging and mapping services — in the aftermath of a disaster? Challenge applicants will be expected to design both the means to access the wireless network (i.e. hardware) and the applications provided on top of that network (i.e. software). Projects should be portable, easy to power and simple to access. Here’s an example: A backpack containing a hard drive computer, battery and Wi-Fi router. The router provides access, via a Wi-Fi network, to resources on the hard drive like maps and messaging applications. Smart Community Networks Challenge Many communities across the U.S. lack reliable Internet access. Sometimes commercial providers don’t supply affordable access; sometimes a particular community is too isolated; sometimes the speed and quality of access is too slow. How can we leverage existing infrastructure — physical or network — to provide high-quality wireless connectivity to communities in need? Challenge applicants should plan for a high density of users, far-reaching range and robust bandwidth. Projects should also aim to make a minimal physical footprint and uphold users’ privacy and security. Here’s an example: A neighborhood wireless network where the nodes are housed in, and draw power from, disused phone booths or similarly underutilized infrastructure. These challenges are open to individuals and teams, nonprofits and for-profits. Applicants could be academics, technology activists, entrepreneurs or makers. We’re welcoming anyone with big ideas and passion for a healthy Internet to apply. Prizes will be available for both early-stage design concepts and fully-working prototypes. To learn more and apply, visit This[...]

Firefox Nightly: These Weeks in Firefox: Issue 19

Wed, 21 Jun 2017 09:56:19 +0000

Highlights The Photon structure pref has been flipped on Nightly. Photon menus / customization etc. are now the default configuration on Nightly. See dolske’s blog post. The new hamburger menu We populated the onboarding overlay on about:newtab according to the UI spec. There are 5 tours with call-to-action buttons & you can hide the tour with a checkbox. The new onboarding panel The stub installer is shipping in Firefox 55, and defaults to 64-bit for 64-bit OSes as of 55, provided it has sufficient memory. (Updating to 64-bit from 32-bit is aiming to follow suit in 56.) The reorganized preferences page is shipping in Firefox 56! Also, the search input in preferences has been enabled by default! Recent perf work in the Location Bar code is showing interesting gains in the time to return the first result (source) Mean! Firefox Focus is now available for Android! We’re officially shipping e10s-multi to eligible users in Firefox 54! We’ll soon be expanding it to users with WebExtensions installed via a system add-on update as well. Friends of the Firefox team johannh wants to introduce Prathiksha [:prathiksha], our new Outreachy intern who is working on permission management in about:preferences and other permission-related bugs. mikedeboer wants to introduce Bao Quan [:beekill], the sessionstore GSoC intern this year! Resolved bugs (excluding employees): More than one bug fixed: Iaroslav Sheptykin Jeongkyu Kim Santiago Paez [:tiago] Tomislav Jovanovic :zombie UK92 New contributors ( = First Patch!) Perry Jiang [:perry] fixed the broken Preferences button for Flash when it’s set to Never Activate! And with an automated test, too! And it got uplifted to beta! meet1995 implemented History.hasVisits, also with an automated test! Project Updates Add-ons chrome_settings_overrides now allows an extension to add a search engine to Firefox (but not change the default search engine). now requires user interaction. privacy.websites.referrersEnabled landed, allowing an extension to enable or disable referrers. Methods for getting information about installed extensions (management.get() and management.getAll()) as well as events for onEnabled, onDisabled, onInstalled and onUninstalled were all enabled for regular extensions in addition to themes. Updated WebExtensions code to put things in the permanent area in the overflow panel instead of the hamburger menu. A browser.menus namespace was added which becomes an alias for the browser.contextMenus namespace. This was added because we are in the process of adding APIs to add items to the main menu in addition to context menus. Support for ws and wss protocols were added to the webRequest API. WebExtension experiments are now allowed on release, however they need to be signed by AMO. This will be used by TestPilot to migrate away from the add-on SDK and replace unimplemented APIs with experiments. 57 release is 7 weeks away, at which point we will be disabling all add-ons except WebExtensions on Nightly. This doesn’t include internally signed legacy add-ons. Activity Stream June 15th Newsletter Highlights: Graduation Team has landed the about:newtab Preferences Pane, put in place a bunch of performance telemetry, and made some amazing progress on making sure all existing Firefox about:newtab tests pass. The MVP Team has built out controls f[...]

Chris McDonald: Message Broker: Into String

Tue, 20 Jun 2017 21:18:19 +0000

Strings in most native or performance focused languages tend to present a fair amount of complexity and Rust is no exception to this. There are cases where you have a struct that needs to have a name, such as: struct ServiceHandle { name: String, } The first ServiceHandle::new() function I would typically write when first learning Rust would look like this: fn new(name: String) -> ServiceHandle { // other init stuff ServiceHandle { name: name } } In the real world I generally have a String to pass to ServiceHandle::new(String) so this API works well. But when I’m writing tests for my code, I want to pass hard coded values with type &'static str. In order to do that, I have to call one of the conversion functions. ServiceHandle::new("listener".into()); ServiceHandle::new("listener".to_owned()); ServiceHandle::new(String::from("listener")); If I change the signature to something like: fn new(name: &str) -> ServiceHandle { // other init stuff ServiceHandle { name: name.to_owned() } } Then I have to remember to prefix String with & when passing to the function. Another possibility is to from_string and from_str which is what I started to rely on next. Then I don’t have to remember as much, just use the right one for the right type. fn from_str(name: &str) -> ServiceHandle { // skip init stuff, let from_string do it ServiceHandle::from_string(name.to_owned()) } fn from_string(name: String) -> ServiceHandle { // other init stuff ServiceHandle { name: name } } This gets me into a better state where it is easy to remember what string type it takes, but it feels clumsy. Rust provides the From and Into traits that types can implement to enable more generic coding. They are as their name implies a way to automatically change types. They are “reflexive” which means that if one of them is implemented the other can use it. For example, impl From for B would allow you to write a function like fn thing>(arg: T) which could be called like thing(A {}). So the next iteration of my ServiceHandle::new() went generic: fn new>(name: S) -> ServiceHandle { ServiceHandle { name: name.into() } } This allows calling with String, &str or several other types that can automatically be converted into a String. Making writing testing code with &'static str simple, while dynamically generated String objects still a first class citizen. [...]

Jean-Marc Valin: Opus 1.2 is out!

Tue, 20 Jun 2017 19:16:16 +0000

(image) Opus gets another major upgrade with the release of version 1.2. This release brings quality improvements to both speech and music, while remaining fully compatible with RFC 6716. There are also optimizations, new options, as well as many bug fixes. This Opus 1.2 demo describes a few of the upgrades that users and implementers will care about the most. You can download the code from the Opus website.

Air Mozilla: Rain of Rust -3rd online meeting

Tue, 20 Jun 2017 17:00:00 +0000

(image) This event belongs to a series of online Rust events that we run in the month of June, 2017

David Bryant: I think I know what you mean, Kev, and I understand, but if you ask me it is your day too.

Tue, 20 Jun 2017 15:04:20 +0000

I think I know what you mean, Kev, and I understand, but if you ask me it is your day too. Happy Father’s Day, from one father to another.


Air Mozilla: Martes Mozilleros, 20 Jun 2017

Tue, 20 Jun 2017 15:00:00 +0000

(image) Reunión bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos. Bi-weekly meeting to talk (in Spanish) about Mozilla status, community and...

The Mozilla Blog: Firefox Focus New to Android, blocks annoying ads and protects your privacy

Tue, 20 Jun 2017 13:06:55 +0000

Last year, we introduced Firefox Focus, a new browser for the iPhone and iPad, designed to be fast, simple and always private. A lot has happened since November; and more than ever before, we’re seeing consumers play an active role in trying to protect their personal data and save valuable megabytes on their data plans. While we knew that Focus provided a useful service for those times when you want to keep your web browsing to yourself, we were floored by your response  – it’s the highest rated browser from a trusted brand for the iPhone and iPad, earning a 4.6 average rating on the App Store. Today, I’m thrilled to announce that we’re launching our Firefox Focus mobile app for Android. Like the iPhone and iPad version, the Android app is free of tabs and other visual clutter, and erasing your sessions is as easy as a simple tap.  Firefox Focus allows you to browse the web without being followed by tracking ads which are notoriously known for slowing down your mobile experience.  Why do we block these ad trackers? Because they not only track your behavior without your knowledge, they also slow down the web on your mobile device. Check out this video to learn more:   New Features for Android For the Android release of Firefox Focus, we added the following features: Ad tracker counter – For the curious, there’s a counter to list the number of ads that are blocked per site while using the app. Disable tracker blocker – For sites that are not loading correctly, you can disable the tracker blocker to quickly take care of it and get back to where you’ve left off. Notification reminder – When Focus is running in the background, we’ll remind you through a notification and you can easily tap to erase your browsing history. For Android users we also made Focus a great default browser experience. Since we support both custom tabs and the ability to disable the ad blocking as needed, it works great with apps like Facebook when you just want to read an article without being tracked. We built Focus to empower you on the mobile web, and we will continue to introduce new features that make our products even better. Thanks for using Firefox Focus for a faster and more private mobile browsing experience.   Firefox Focus Settings View You can download Firefox Focus on Google Play and in the App Store. The post Firefox Focus New to Android, blocks annoying ads and protects your privacy appeared first on The Mozilla Blog.[...]

QMO: Firefox 55 Beta 4 Testday, June 23rd

Tue, 20 Jun 2017 12:58:41 +0000

Hello Mozillians,

We are happy to let you know that Friday, June 23rd, we are organizing Firefox 55 Beta 4 Testday. We’ll be focusing our testing on the following new features: Screenshots and Simplify Page.

Check out the detailed instructions via 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!

Firefox Nightly: Resolved: Fixed – A short story about a community-reported bug

Tue, 20 Jun 2017 09:14:55 +0000

Firefox Nightly users, thanks to the telemetry and crash reports they send to Mozilla, are an amazing help to Firefox developers. The aggregated data sent by our community is extremely useful and allows spotting performance or stability regressions at the earliest stages of development. It probably can’t be emphasized enough how just using Nightly is a great way to get involved in Mozilla. That said, we have in our Nightly community people that also actively hunt and report bugs and regressions and provide us detailed feedback, usually via the opening of a bug report in Bugzilla. These people are our core community, our first line of defense against regressions, they allow us to ship faster and better software and many of them have been involved in Mozilla and Firefox for a long time. “Have you filed a bug?” is something you often hear open source developers say to people that report them some anomaly or regression, and for the majority of our users, this sounds like a complicated process. Just explaining the bug they experience in terms that make the bug report actionable by the developer that will fix it is a skill in itself. And this is where our core community of power-users on Nightly shines, they have this skill. But what if the reporter has these skills but is not comfortable communicating in English because it is not her native language? Yes, language can also be a barrier to giving feedback… A few days ago, a mozillian from our Spanish community (web developer in an IT company in Spain), sent me an email about a regression he was experiencing at work with nightly in the last days. This is the story I want to tell because it illustrates how powerful community work in open source can be and how lucky Mozilla is to have a dedicated global community. Fernando, or StripTM as we know him in the Mozilla Hispano community, sent me an email about a major performance regression with forms on a page they have on their intranet, clicking in a form field would freeze the browser for seconds, and he wanted to know if I had heard about it. I didn’t so I asked him if there was a way I could see this page. Intranets are tricky, the content there is by definition not public. But StripTM being a Web developer, he emailed me a reduced anonymized version of the page so as that I could test locally if I could see the bug and yes, I was experiencing it as well. Since StripTM is not always comfortable writing bug reports in English, I did it for him and filed bug 1372843 a week ago and attached his test case. I fired up mozregression and found out that the bug was caused by the recent activation of Form Autofill in Nightly (see our article Preview Form Autofill in Firefox Nightly). In a nutshell, the performance problem was caused by the fact that this intranet page had 170(!) forms and our heuristics were cycling through all of the input fields in the page instead of only  the ones for the form we had clicked in. All in all, it took a total of 3 days to discover the performance problem, file a bug and get a patch for it in mozilla-central. This is what happens when you can put passionate and skilled volunteers in contact with our equally [...]

Daniel Stenberg: c-ares 1.13.0

Tue, 20 Jun 2017 06:15:52 +0000

(image) The c-ares project may not be very fancy or make a lot of noise, but it steadily moves forward and boasts an amazing 95% code coverage in the automated tests.

Today we release c-ares 1.13.0.

This time there’s basically three notable things to take home from this, apart from the 20-something bug-fixes.


Due to an oversight there was an API function that we didn’t fuzz and yes, it was found out to have a security flaw. If you ask a server for a NAPTR DNS field and that response comes back crafted carefully, it could cause c-ares to access memory out of bounds.

All details for CVE-2017-1000381 on the c-ares site.

(Side-note: this is the first CVE I’ve received with a 7(!)-digit number to the right of the year.)


Now c-ares can optionally be built using cmake, in addition to the existing autotools setup.

Virtual socket IO

If you have a special setup or custom needs, c-ares now allows you to fully replace all the socket IO functions with your own custom set with ares_set_socket_functions.

This Week In Rust: This Week in Rust 187

Tue, 20 Jun 2017 04:00:00 +0000

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR. Updates from Rust Community News & Blog Posts RustConf 2017 tickets are now available. encoding_rs, a new character encoding conversion library written in Rust, has landed in nightly Firefox. Bugs you'll probably only have in Rust. Why not to use Rust. Algorithms cookbook in Rust. Implementing cooperative multitasking in Rust. Switching from C++ to Rust. Graphics by squares: a gfx-rs tutorial. Rustfmt releases. There are some significant changes happening to Rustfmt. Here is what you need to know. System programming in Rust: beyond safety. Writing a LALR(1) parser generator in Rust. hyper v0.11 is released. This week in Redox 22. This week in Servo 104. Crate of the Week This week's crate is include_dir, a crate that lets you include entire directory contents in your binary – like include_str!, but on steroids. Thanks to Michael Bryan for the suggestion! Submit your suggestions and votes for next week! Call for Participation Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. [easy] rust: Guard types should implement more traits. walkdir: Add Error docs to methods that return Result. walkdir: Default to generating constified enums, rather than generating Rust enums. walkdir: Change OsString args in sort_by to OsStr. walkdir: Remove re-export of is_same_file. walkdir: Document why unwraps won't fail. walkdir: Make skip_current_dir and filter_entry inherent methods. walkdir: Link references to std in docs. walkdir: Add build badges to Cargo.toml. walkdir: Implement Debug for WalkDir, Iter and IterFilterEntry. walkdir: Correct errors in WalkDir type docs. walkdir: Document that Iter and IterFilterEntry are the result of trait methods. walkdir: Add links to other walkdir items in WalkDirIterator docs. walkdir: Add links to other walkdir items in Iter and IterFilterEntry docs. walkdir: Add links to other walkdir items in DirEntry docs. walkdir: Add example for content_first. rust-cookbook: Use filter_entry in walkdir examples. [easy] rust-bindgen: Default to generating constified enums, rather than generating Rust enums. [less-easy] rust-bindgen: Rewrite is_unsized as either a graph traversal or fix-point analysis. [less-easy] rust-bindgen: Rewrite can_derive_debug as either a graph traversal or fix-point analysis. [less-easy] rust-bindgen: Rewrite can_derive_copy[_in_array] as either a graph traversal or fix-point analysis. [less-easy] rust-bindgen: Rewrite has_vtable checks as either graph traversal or fix-point analysis. If you are a [...]

Mozilla Marketing Engineering & Ops Blog: MozMEAO SRE Status Report - June 20, 2017

Tue, 20 Jun 2017 00:00:00 +0000

Here’s what happened on the MozMEAO SRE team from June 13th - June 20th.

Current work

Static site hosting

  • The irlpodcast site now has a staging environment also hosted in S3 with CloudFront. Additionally, Jenkins has been updated to deploy to staging and production via git push.

  • We’re going to move from Kubernetes to S3 and CloudFront hosting. Production and staging environments have been provisioned, but we’ll need to update Jenkins to push changes to these new environments.

Basket move to Kubernetes

Kubernetes (general)

Our DataDog, New Relic and MIG DaemonSets have been configured to use Kubernetes tolerations to schedule pods on master nodes. This allows us to capture metrics from K8s master nodes in additional to worker nodes.

Frankfurt Kubernetes cluster provisioning

Work continues to enable our apps in the new Frankfurt Kubernetes cluster. In addition, we’re working on automating our app installs as must as possible.


  • ElasticSearch will be upgraded to 2.4 in SCL3 production, June 21 11 AM PST

  • We may reconsider self-hosting ElasticSearch.


Daniel Stenberg: “OPTIONS *” with curl

Mon, 19 Jun 2017 21:30:04 +0000

(Note: this blog post as been updated as the command line option changed after first publication, based on comments to this very post!)

curl is arguably a “Swiss army knife” of HTTP fiddling. It is one of the available tools in the toolbox with a large set of available switches and options to allow us to tweak and modify our HTTP requests to really test, debug and torture our HTTP servers and services.

That’s the way we like it.


In curl 7.55.0 it will take yet another step into this territory when we finally introduce a way for users to send “OPTION *” and similar requests to servers. It has been requested occasionally by users over the years but now the waiting is over. (brought by this commit)

“OPTIONS *” is special and peculiar just because it is one of the few specified requests you can do to a HTTP server where the path part doesn’t start with a slash. Thus you cannot really end up with this based on a URL and as you know curl is pretty much all about URLs.

The OPTIONS method was introduced in HTTP 1.1 already back in RFC 2068, published in January 1997 (even before curl was born) and with curl you’ve always been able to send an OPTIONS request with the -X option, you just were never able to send that single asterisk instead of a path.

In curl 7.55.0 and later versions, you can remove the initial slash from the path part that ends up in the request by using –request-target. So to send an OPTION * to for http and https URLs, you could do it like:

$ curl --request-target "*" -X OPTIONS
$ curl --request-target "*" -X OPTIONS

In classical curl-style this also opens up the opportunity for you to issue completely illegal or otherwise nonsensical paths to your server to see what it does on them, to send totally weird options to OPTIONS and similar games:

$ curl --request-target "*never*" -X OPTIONS

$ curl --request-target "allpasswords"


Chris McDonald: Message Broker: Goals and (De)Motivations

Mon, 19 Jun 2017 20:57:28 +0000

Recently, I read a twitter rant that described message brokers as poor combination load balancer, database, and service discovery tools. It hit me hard since I’d just spent a week diving into writing my own message broker. While I had my dislikes of brokers, I think they are handy tools. The tweeter stated that many of these things should be built into the services. The goal of which to keep the heavy work out of the center of the system. Message brokers doing the opposite when used as a central bus. Having this description of the problem space is turning out to be nice. It gives me some different framing for the various parts of the message broker I’ll be building and the underlying needs. It also pointed out a heavy flaw that message brokers as a central bus can cause trouble in some systems. While that twitter rant dismayed me at first, I now feel even more energized in building this tool. This framing of load balancer, database, and service discovery reminds me to go read up on that tech as well. Sourcing papers for those problems while looking into queuing related things. I can acknowledge and make sure these subproblems get solved well enough for my intended scale. That will be a key part of my design going forward, keeping my decisions favoring small to medium scale. I’ve seen message brokers work well in those scenarios and want to make an even better one of those. This doesn’t mean one couldn’t use the broker in a larger scale operation. But, I’m architecting it to encourage deliberate clustering beyond medium scale. Clustering acknowledges the fact that there are usually groups of services that are able to meet a work request without speaking outside of their group except for one or two edges. What I hope to discover as part of the development process is how to encourage this. Whether documenting and creating examples will be enough, or if I’ll need more core features. I think keeping the message broker light weight will be instrumental in encouraging clustering. If the message broker is heavy, folks wouldn’t want to run too many instances. If it requires a lot of tuning to be useful, folks will want to only tune it once as a central bus. Side note: as I typed this I realized this is why Redis is so good. Among the lofty design and architecture goals I want to mention my motivations and put the goals in perspective. This project’s main goal is to be a learning project. I want to better understand the internals of message buses. Most green field backend projects will be utilizing a message bus and smaller services. Understanding the internals of the message bus and keeping them in mind will let me design better services. I also want to build a complex, performance focused, realistic piece of software in Rust. I find the language fun to work with and writing my own thread orchestration that is safe is delightful. As I build up the basics in the broker and client, I’m learning a lot of practical Rust skills. Like many others writing and coding in Rust in their free time, I’m[...]

Air Mozilla: Community Participation Guidelines Revision Brownbag (NALA)

Mon, 19 Jun 2017 20:00:00 +0000

(image) A revised version of Mozilla's Community Participation Guidelines was released in May 2017. Please join Larissa Shapiro (Head of D&I) and Lizz Noonan (D&I Coordinator)...

Air Mozilla: Mozilla Weekly Project Meeting, 19 Jun 2017

Mon, 19 Jun 2017 18:00:00 +0000

(image) The Monday Project Meeting

Air Mozilla: Rep. Eshoo Net Neutrality Roundtable

Mon, 19 Jun 2017 16:30:00 +0000

(image) Congresswoman Anna Eshoo (D-CA) will convene a roundtable to discuss the impacts of net neutrality and the consequence of eviscerating the policy. Eshoo will hear...

Carsten Book: Reminder :) Please take part in the Sheriff Survey!

Mon, 19 Jun 2017 14:45:41 +0000

just a reminder that we have our Sheriff Survey Running and please take part in it, it helps us a lot to improve our work!





Cameron Kaiser: TenFourFox FPR1 available

Mon, 19 Jun 2017 05:26:00 +0000

TenFourFox Feature Parity Release 1 is available for testing (downloads, hashes, release notes). There are no major changes from the beta except for a couple minor efficiency updates and a font blacklist update, and all remaining applicable security issues have been backported as well.

Chris T reported that old issue 72 (a/k/a bug 641597) has resurfaced in FPR1. Most likely this bug was never actually fixed, just wallpapered over by something or other, and the efficiency improvements in FPR1 have made it easier to trigger again. That said, it has only ever manifested on certain 10.5 systems; it has never been reproduced on 10.4 by anyone, and I can't reproduce it myself on my own 10.5 DLSD PowerBook G4. For that reason I'm proceeding with the release as intended but if your system is affected, please post your steps to replicate and we'll compare them with Chris' (especially if you have a 10.4 system, since that will be much easier for me to personally debug). Please also note any haxies or system extensions as the issue can be replicated on a clean profile, meaning addons or weird settings don't appear to be a factor. If we find a fix and enough people are bitten, it should be possible to spin a point release.

The plan is for a Tuesday/Wednesday release ahead of schedule, so advise if there are any new showstoppers.

Emma Irwin: Escaping the economy of souls — starting with Facebook (in 4 steps)

Sun, 18 Jun 2017 16:02:18 +0000

“I think it’s time for a reclamation movement.” – Tim Wu author of The Attention Merchant in a talk at @ Mozilla Toronto last week A little over two months ago, I removed the web-warping, soul exploiting, goggles of a ‘free’ Facebook account — free as in guinea pig. I lost my best friend and partner to cancer around this time, and Facebook knew that. I found myself staring at content curated just for me — a Ted Talk about end of life care, cancer foundations, hospital foundations, an ‘inspiring’ story of a boy who survived cancer, and a review of ‘Option B’, Sheryl Sandburg’s book on grief… I had joined her Facebook group, but they knew that too: And there I was, as if waking in a horror movie finding vile tentacles of a venomous creature wrapped around me, I saw; I witnessed and felt the cost of free. The cost of my well being, of dignity and for all those around me — the cost of my attention, focus and awareness of the world around me. Was my feed part of an experiment or just really shitty and cruel algorithms? Facebook doesn’t hide the fact it’s learning from people like me during personal crises. Rather, it publishes reports on the findings:   And probably what upset me the most was that Sheryl Sandburg of Facebook, whose book I liked and shared, who should be protective of people in grief was bringing large numbers of people to her Facebook group —so much heartbreak, so much trauma data. And Sheryl is aware… “ However, the company was widely criticised for manipulating material from people’s personal lives in order to play with user emotions or make them sad. In response on Thursday, Facebook said that it was introducing new rules for conducting research on users with clearer guidelines, better training for researchers and a stricter review process. But, it did not state whether or not it would notify users — or seek their consent — before starting a study.” — BBC News “Facebook admits failings over emotion manipulation study” The reason I write this is to wake you up as well, although you are likely partially there — you need to get all the way there. Please stumble with me to some type of reclamation movement, it’s important for humanity (no exaggeration). Facebook, and others in the economy of souls design addictive technology to keep us there. I’ve used the same excuses you are. The spine of Facebook’s business model is your contact list — and this should be the center of reclaim.             Dumping Facebook means threatening the ambient contact I have with my 81 year old Aunt whom I love and adore. And that is the problem. — Clint Lalonde (@clintlalonde) May 28, 2017   Below are the steps I’ve taken to wean myself off Facebook and my contact list off Facebook for good. I want an empowered online life, and I want that for [...]

Daniel Stenberg: curl doesn’t spew binary anymore

Fri, 16 Jun 2017 22:00:22 +0000

One of the least favorite habits of curl during all these years, I’ve been told, is when users forget to instruct the command line tool where to store the downloaded file and as a direct consequence, curl instead sends a lot of binary “gunk” to the terminal. The end result of that is at best just a busload of weird-looking characters on the screen, but with just a little bit of bad luck it can also lock up the terminal completely or change it in other ways.


Starting in curl 7.55.0 (from this commit), curl will inspect the beginning of each download that has been told to get sent to the terminal (tty!) and attempt to detect and prevent raw binary output to get sent there. The code is only simply looking for a binary zero in the data.

$ curl
Warning: Binary output can mess up your terminal. Use "--output -" to tell curl to output it to your terminal anyway, or consider "--output " to save to a file.

As the warning message says, there’s an option to use to switch off this emergency check for when you truly know what you’re doing and you don’t need curl to prevent you from doing this. Then you just tell curl explicitly that you want the output to stdout, with “–output -” (or “-o -” for a shorter version):

$ curl -o -

We’re eager to get your input and feedback on how this works. We are aware of the risk of false positives for UTF-16 and UTF-32 outputs, but we think they are rare enough to not make this a huge problem.

This feature should be able to drastically reduce the risk for this:



(Update, added after the initial posting.)

So many have remarked or otherwise asked how this affects when stdout is piped into something else. It doesn’t affect that! The whole point of this check is to only show the warning message if the binary output is sent to the terminal. If you instead pipe the output to another program or if you redirect the output with >, that will not trigger this warning but will instead continue just like before. Just like you’d expect it to.

Air Mozilla: Webdev Beer and Tell: June 2017

Fri, 16 Jun 2017 18:00:00 +0000

(image) Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...

Will Kahn-Greene: The Soloists

Fri, 16 Jun 2017 16:00:00 +0000

Building Firefox is a big endeavor. There are many teams and projects covering initiatives, maintenance, bug fixing, triage, localization, support, understanding feedback, marketing, communication, releasing, supporting infrastructure, crash analysis, and a bazillion other activities all to build a family of browsers and applications. Teams and projects aren't static. People move around as priorities change and the landscape shifts and projects complete or are scuttled. Sometimes projects get started up with a single person. Sometimes all the people except one move off a project. Sometimes we find ourselves working alone, in a basement office, with only a stapler equivalent to keep us company. We are the soloists. You wouldn't believe the list of things we work on. Alone. Where to find soloists: IRC, Slack There's an IRC channel #soloists on There's also a Slack channel #soloists on the Mozilla Slack [1]. These two places (and whatever other places soloists want to hang out at) are places where we can: find some solace from the weary drudgery of being alone on their projects for days on end ask for help bounce ideas off each other vent frustrations in a friendly forgiving place get advice on dealing with things like code reviews and how to go on vacation get recognition for a job well done and a variety of other things that alleviate many of the problems we have as soloists. [1]I just created it, so it's kind of empty. I'm feeling alone in the #soloists Slack channel. So alone. Stickers at the All Hands! Over the last month or so, we spent some time figuring out #soloists stickers because we like stickers and you like stickers and everyone likes stickers. They look like this: Soloist 2017 sticker. They're 2" by 2" and round. They're warm to the touch. They make you want to climb things. By yourself. Alone. With appropriate safety gear. [2] If you're a soloist, come find one of us and get a sticker. Also, consider joining soloist channels. If you support soloists, come find one of us and get a sticker. Ask us about the things we're working on. We may be solo, but we're working on real projects that almost certainly affect you. As a group, we did great things in the last 6 months. Alone. So alone. [2]That's how they make me feel, anyhow. [...]

Daniel Stenberg: curl: read headers from file

Fri, 16 Jun 2017 07:20:52 +0000

(image) Starting in curl 7.55.0 (since this commit), you can tell curl to read custom headers from a file. A feature that has been asked for numerous times in the past, and the answer has always been to write a shell script to do it. Like this:

while read line; do
  args="$args -H '$line'";
curl $args $URL

That’s now a response of the past (or for users stuck on old curl versions). We can now instead tell curl to read headers itself from a file using the curl standard @filename way:

$ curl -H @headers

… and this also works if you want to just send custom headers to the proxy you do CONNECT to:

$ curl --proxy-headers @headers --proxy proxy:8080

(this is a pure curl tool change that doesn’t affect libcurl, the library)

Ehsan Akhgari: Quantum Flow Engineering Newsletter #13

Fri, 16 Jun 2017 05:11:37 +0000

I’m back with some more updates on another week worth of work on improving various performance aspects of Firefox. Similar to the past weeks, Speedometer remains a big focus area for performance work.  In addition to the many already identified bugs to work on, we are also still measuring the benchmark quite actively looking for more optimization opportunities. Another item worthy of an update is Background Hang Reports.  Michael Layzell earlier today enabled collection of native stack traces on Win64 (and Mac) using the Gecko Profiler stack walking backend (Linux support soon to follow).  Because we are now using the Gecko Profiler backend for BHR, we can soon get interleaved native and pseudo-stacks from BHR similar to the ones that we have come to know and love in Gecko Profiler for a long time now!  Also, Doug Thayer has made a lot of progress on hangs.html, his front-end for exploring the native stack traces uploaded from BHR.  This is a nice and super fast tool to explore the hangs that our users are experiencing on the Nightly channel and it shows you the corresponding pseudo-stacks that are extremely helpful if for example the hang is coming from chrome-privileged JS (where we get full call stack information through telemetry).  Please have a look, and send him feedback. This edition is exceptionally short, but the most interesting part of these is probably the last part anyway, the credits section, where I acknowledge the hard work of the people who worked on improving the performance of Firefox in the past week.  So let’s get to that, and I do hope I’m not dropping any names: Dão Gottwald made it so that XUL scrollboxes don’t always cause a style flush when checking if it can scroll to an element. Junior Hsu got rid of some main thread IO that we do when closing the DB connection to the cookies database.  This helps with startup performance. Florian Quèze deferred the construction and initialization of some search components, UnifiedComplete (for the AwesomeBar), and the sidebar browser until after first paint, which should all help to improve start-up speed.  Similarly he deferred the initialization of Places to after first paint.  Additionally he sped up the appearance of the about:home search bar placeholder text which is the last part of painting the initial UI in a new browser profile.  He also made GetShellFolderPath() call the correct Windows API and making startup quite a bit faster as a result. David Baron made it so that we cache font lookups on Windows! Among other things, this should help speed up rendering long