Mozilla Firefox

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 ... [More] 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: [email protected] [Less]

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 ... [More] 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!   [Less]

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 ... [More] 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 up with various fixes to reduce duplicate hashtable lookups.  He also devirtualized nsTableCellFrame::GetRowSpan/GetColSpan(). Andreas Farre exposed the idle dispatch API with timeout to chrome JS.s  This is the final remaining bit of API that brings chrome JS to parity with C++ in terms of its ability to use the new idle dispatch facilities. Cervantes Yu moved our in-process crash reporter to use off-main-thread IO for generating the crash minidump.  This means that our UI will now remain responsive if a tab crashes while we prepare the corresponding crash report. Makoto Kato made UpdateOverlayTextVisibility() not get called twice by the HTMLInputElement.value setter when the element has focus. Edgar Chen made document.hidden be set to true when the browser window is fully covered by another non-translucent application.  This has some performance benefits such as treating such pages as if they were in a background tab and throttling down timeouts/refresh driver for them. Jean-Yves Avenard added support for texture recycling to the ffmpeg media backend on Windows. Kirk Steuber made us clone attributes rather than reparse them when possible when cloning a node. Olli Pettay made nsTextEditorState::UpdateOverlayTextVisibility() avoid accessing the preferences service every time. Doug Thayer moved storage cache shrinking to happen off the main thread. Jon Coppeard changed Zone::isGCMarking() to avoid a TLS lookup. Yoshi Huang moved nsImageLoadingContent to the Necko AsyncOpen2 API which, among security benefits, also reduced the cost of loading images by removing some security checks which happen centrally at the networking layer now. Lee Salzman optimized box blur surfaces for destination draw targets.  This helps with the performance of YouTube videos with text overlays using box shadows, which is common. Dão Gottwald avoided a layout flush in order to determine whether scrollbox scroll buttons should be enabled/disabled. Ted Campbell improved JIT support for ES6 classes.   Made nice improvements to the ARES-6 benchmark! [1] (The number of bug fixes is a weird metric to use for performance improvements, since we use bugs as a unit of work, and the performance impact of each bug can be vastly different.  But I have tried to describe the details of these bugs for the most part before so the detailed information is at least available.) [Less]

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 ... [More] 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, and fixed the last blocker to starting work on removing Promise.jsm usage. More awesome work on improving Talos measurements and figuring out regressions. (Particularly some issues that have been holding up animations.) Florian posted in firefox-dev about the browser_startup.js test, and asked everybody to have a look at the generated list to identify low hanging fruit. This test helps us find code that is loading too early, and prevents things from regressing once we fix it.   Thus concludes Photon update #7. As noted above, next week is going to be a little busy, so it may be a couple of weeks until the next update. [Less]

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 ... [More] 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, and fixed the last blocker to starting work on removing Promise.jsm usage. More awesome work on improving Talos measurements and figuring out regressions. (Particularly some issues that have been holding up animations.) Florian posted in firefox-dev about the browser_startup.js test, and asked everybody to have a look at the generated list to identify low hanging fruit. This test helps us find code that is loading too early, and prevents things from regressing once we fix it.   Thus concludes Photon update #7. As noted above, next week is going to be a little busy, so it may be a couple of weeks until the next update. [Less]

.

.

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 ... [More] 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 value to create one distinct Notifier instance per run. It starts at 1. Next, the session.worker_id value gives each distinct worker a unique id. If you run molotov with 5 workers, you will get values from 0 to 4. We are making the last worker (worker id== 4) the one that will be in charge of writing in the pad. For the other workers (=readers), they just use wait_for_writer() to sit and wait for worker 4 to write the pad. worker 4 notifies them with a call to written(). The last part of the script allows Molotov to run the script several times in a row using the same workers. When the writer starts its work, if the step value is superior to one, it means that we have already run the test at least one time. The writer, in that case, gets back the Notifier from the previous run and verifies that all the readers did their job before changing the pad. All of this syncing work sound complicated, but once you understand the pattern, it let you run advanced scenario in Molotov where several concurrent "users" need to collaborate. You can find the full script at https://github.com/tarekziade/molosonic/blob/master/loadtest.py [Less]

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 ... [More] 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 they spend too much time identifying the right specs to build from, spend too much time waiting for feedback from designers, and spend too much time mapping new designs to existing UI elements. In the same survey designers reported to feel they spend too much time identifying current UI to re-use in their designs, and spend 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: design.firefox.com/photonWe 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, and more 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 challenge again, and again. was originally published in Firefox User Experience on Medium, where people are continuing the conversation by highlighting and responding to this story. [Less]

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 ... [More] 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. [Less]