Mozilla Nederland LogoDe Nederlandse

Air Mozilla: Martes Mozilleros, 19 Dec 2017

Mozilla planet - di, 19/12/2017 - 15:00

Martes Mozilleros 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...

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 213

Mozilla planet - di, 19/12/2017 - 06:00

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 Crate of the Week

This week's crate is cargo-audit, a cargo subcommand to look through a crates dependencies for known insecure versions. Thanks to Danilo 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.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

82 pull requests were merged in the last week

New Contributors
  • David Teller
  • Felix Schütt
  • Nika Layzell
  • qres
  • varkor
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

No RFCs were approved this week.

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Upcoming Events

If you are running a Rust event please add it to the calendar to get it mentioned here. Email the Rust Community Team for access.

Rust Jobs

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

No quote was selected for QotW.

Submit your quotes for next week!

This Week in Rust is edited by: nasa42 and llogiq.

Categorieën: Mozilla-nl planet

Air Mozilla: WebVR Meetup

Mozilla planet - di, 19/12/2017 - 03:00

WebVR Meetup WebVR Meetup

Categorieën: Mozilla-nl planet

Air Mozilla: WebVR Meetup

Mozilla planet - di, 19/12/2017 - 03:00

WebVR Meetup WebVR Meetup

Categorieën: Mozilla-nl planet

The Firefox Frontier: Update: Looking Glass Add-on

Mozilla planet - di, 19/12/2017 - 00:11

We didn’t think hard enough about how our actions would affect the community, and we’re sorry for letting you down. How we got here Over the course of the year … Read more

The post Update: Looking Glass Add-on appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Kim Moir: Ship Happens: A better Firefox build & release pipeline

Mozilla planet - ma, 18/12/2017 - 21:02

I gave a talk last week at the Mozilla All Hands in Austin about how we recently transformed our build and release pipeline to be more resilient and self-service oriented for developers. It’s a bit Mozilla specific, but I posted the slides online for those who are interested. Big kudos to the Mozilla release engineering team for all their work to make this transformation happen. Also, thanks to them for feedback on the slides!

Ship happens: A better firefox build and release pipeline from Kim Moir

If you click on this link, and then click the “Notes” link in slideshare, you can see the associated speaker notes for the talk which makes it more useful than the slides alone.

Categorieën: Mozilla-nl planet

Andreas Tolfsen: Update from WebDriver meeting at TPAC

Mozilla planet - ma, 18/12/2017 - 15:03

The WebDriver working group meeting at TPAC this year marked the culmination of six years of hard work defining WebDriver as a standard. Up to this point, the work has largely been about specifying the behaviour of existing implementations: we have tightened up semantics where drivers have behaved differently, corrected inconsistencies inherited from the Selenium wire protocol, and written a test suite.

We are quickly reaching a point where we can deliver a consistent cross-browser mechanism for instrumenting and automating web browsers. Vendors are already reaping the benefits of this by employing WebDriver in the testing of standards, and web authors will soon see a range of new features be added.

New windows

One long-awaited feature is for WebDriver to be able to open new windows and tabs. Today people use many different techniques, such as injecting a…) script to work around this deficiency. Doing that is problematic because new windows will be children of the current window, potentially opening them up to leeching.

Some users are exploiting the fact that certain drivers let you perform key combinations that affect the OS or the browser. For example, a ^T or ⌘T combination will normally open a new tab in desktop browsers, but WebDriver is constricted to web content and is not meant to let you interact with the surrounding system.

There is currently no platform API that lets you open a new untainted top-level browsing context and it will complement the other window manipulation commands well.


In the Selenium project many drivers implemented a rudimentary logging API that made it possible get different logs such as console- and performance, the driver logs, and Selenium Grid logs. We talked about logging several years ago but decided to put it on hold in order to narrow the scope of the first draft and focus on getting the fundamentals right.

Simon came up with a new strawman proposal that lets you request log services from arbitrary remote ends between you and the final endpoint node. What sets the new API apart from the existing Selenium logging API, is that it distinguishes logs from individual classes of nodes. Your favourite WebDriver-in-the-cloud provider might provide a service for taking screenshots for every failing test, and with this new API it will be possible to request those in a uniform way.


As WebDriver is a specification text other standards now have the ability to leverage its definitions to meet their own demands. We are seeing an example of this with the Permissions API that is extending WebDriver to instrument getUserMedia(). The ability to write automated tests for permissions allows shared test suites like Web Platform Tests to promote consistency amongst browsers, but for example also means web authors will get the opportunity to test geolocation for maps and other types of media.


Can you imagine driving a WebVR headset using WebDriver? Well, the WebVR working group can. It will be an unconventional use of WebDriver, but it turns out that WebDriver’s API lends itself well to the kind of spatial navigation that is needed to control headsets.

To go into virtual reality mode in your browser you first need permission from the user, and it’s therefore exciting to see that we are starting to build an ecosystem of tools for browser instrumentation with the addition of the Permissions API.

Categorieën: Mozilla-nl planet

Mozilla installeerde stiekem Mr. Robot-plug-in in browser Firefox - Numrush

Nieuws verzameld via Google - ma, 18/12/2017 - 10:34


Mozilla installeerde stiekem Mr. Robot-plug-in in browser Firefox
Mozilla, de ontwikkelaar van internetbrowser Firefox, heeft stiekem een plug-in geïnstalleerd ter promotie van de tv-serie Mr. Robot. Veel gebruikers voelen zich in hun vertrouwen geschaad, aangezien de plug-in zonder toestemming werd geïnstalleerd ...
Mozilla flatert met ongewenste installatie Mr. Robot Firefox-extensieTechPulse
Mozilla krijgt fikse kritiek op gedwongen installatie plug-inTechzine
Stiekem geïnstalleerde plug-in uit Firefox verwijderd na

alle 9 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Don Marti: quick question on tracking protection

Mozilla planet - ma, 18/12/2017 - 09:00

One quick question for anyone who still isn't convinced that tracking protection needs to be a high priority for web browsers in 2018. Web tracking isn't just about items from your online shopping cart following you to other sites. Users who are vulnerable to abusive practices for health or other reasons have tracking protection needs too.

Screenshot from the American Cancer Society site, showing 24 web trackers

Who has access to the data from each of the 24 third-party trackers that appear on the American Cancer Society's Find Cancer Treatment and Support page, and for what purposes can they use the data?

Categorieën: Mozilla-nl planet

This RSS feed URL is deprecated

Nieuws verzameld via Google - zo, 17/12/2017 - 10:11
This RSS feed URL is deprecated, please update. New URLs can be found in the footers at
Categorieën: Mozilla-nl planet

Mozilla faces blowback after slipping Mr Robot plugin into Firefox - The Verge

Nieuws verzameld via Google - za, 16/12/2017 - 17:47


Mozilla faces blowback after slipping Mr Robot plugin into Firefox
The Verge
Yesterday, Firefox users noticed a strange new plug-in popping up in their browsers. A new plug-in called Looking Glass found its way into each instance of the new Firefox Quantum browser. It was disabled by default, but users were still alarmed to see ...
Mozilla investigates 'Mr. Robot'-Firefox extension faux pasCNET
Mozilla says sorry for pushing out a Mr. Robot add-on to Firefox usersTechRadar India
Mozilla's Mr. Robot promo backfires after it installs a Firefox extension without ...TechCrunch
How-To Geek -Digital Trends -Mashable
alle 81 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Henrik Skupin: Element interactability checks with geckodriver and Firefox 58

Mozilla planet - vr, 15/12/2017 - 13:59

When you are using Selenium and geckodriver to automate your tests in Firefox you might see a behavior change with Firefox 58 when using the commands Element Click or Element Send Keys. For both commands we have enabled the interactability checks by default now. That means that if such an operation has to be performed for any kind of element it will be checked first, if a click on it or sending keys to it would work from a normal user perspective at all. If not a not-interactable error will be thrown.

If you are asking now why this change was necessary, the answer is that we are more WebDriver specification conformant now.

While pushing this change out by default, we are aware of corner cases where we accidentally might throw such a not-interactability error, or falsely assume the element is interactable. If you are hitting such a condition it would be fantastic to let us know about it as best by filing an geckodriver issue with all the required information so that it is reproducible for us.

In case the problem causes issues for your test suites, but you totally want to use Firefox 58, you can use the capability moz:webdriverClick and turn off those checks. Simply set it to False, and the former behavior will happen. But please note that this workaround will only work for Firefox 58, and maybe Firefox 59, because then the old and legacy behavior will be removed.

That’s why please let us know about misbehavior when using Firefox 58, so that we have enough time to get it fixed for Firefox 59, or even 58.


Categorieën: Mozilla-nl planet

QMO: Firefox DeveloperEdition 58 Beta 12 Testday, December 22nd

Mozilla planet - vr, 15/12/2017 - 10:42

Hello Mozillians,

We are happy to announce that Friday, December 22nd, we are organizing Firefox 58 Beta 12 Testday. We will be focusing our testing on Graphics and Web Compatibility. 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.

Please note that the contribution deadline for this Testday is 27th of December!

Join us and help us make Firefox better!

See you on Friday!

Categorieën: Mozilla-nl planet

The Mozilla Blog: Today’s net neutrality vote – an unsurprising, unfortunate disappointment

Mozilla planet - do, 14/12/2017 - 19:14

We are incredibly disappointed that the FCC voted this morning – along partisan lines – to remove protections for the open internet. This is the result of broken processes, broken politics, and broken policies. As we have said over and over, we’ll keep fighting for the open internet, and hope that politicians decide to protect their constituents rather than increase the power of ISPs.

This fight isn’t over. With our allies and our users, we will turn to Congress and the courts to fix the broken policies.

The partisan divide only exists in Washington.  The internet is a global, public resource and if closed off — with only some content and services available unless you pay more to your ISP — the value of that resource declines. According to polls from earlier this year, American internet users agree. Three-quarters of the public support net neutrality. This isn’t a partisan issue.

We’ll keep fighting. We’re encouraged by net neutrality victories in India and elsewhere.  Americans deserve and need better than this.

The post Today’s net neutrality vote – an unsurprising, unfortunate disappointment appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

The Firefox Frontier: A new Firefox and a new Firefox icon

Mozilla planet - do, 14/12/2017 - 17:21

Firefox Quantum is all about being fast, responsive and modern. All the work we did in making this browser fast under the hood, we also put into making it look … Read more

The post A new Firefox and a new Firefox icon appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

The Firefox Frontier: 5 Things That Make Firefox Focus Great at Saving Mobile Data

Mozilla planet - do, 14/12/2017 - 06:12

Here’s a new view on 2018: start the year with more Focus—focus in your online life, on what you’re doing, and away from the distractions. At least that’s going to … Read more

The post 5 Things That Make Firefox Focus Great at Saving Mobile Data appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Firefox Focus Adds Quick Access Without Sacrificing Users’ Privacy

Mozilla planet - do, 14/12/2017 - 06:00

It’s been a little over a year since we launched Firefox Focus. We’ve had tremendous success since then, we launched in 27+ languages, launched on Android, and hit over 1 million downloads on Android within the first month of launch.

Today, we’re introducing a new feature: quicker access to your most visited sites, as well as the ability to add any search engine to your Focus app. They were the most requested items from our users and are aligned with our goals on what makes Focus so great.

We know our users want choice and miss the convenience of having their favorite websites and search engines at their fingertips, but they don’t want to sacrifice their privacy. Since the moment we’ve built Focus, our goal has been to get our users quickly to the information and sites all while keeping their data safe from unwanted targeting.

We all have our popular go-to sites that we visit regularly — whether it’s checking the latest news on your favorite news site or checking the scores of your beloved sports team. Now, you can add the sites you visit frequently to your personal autocomplete list within the app. This means that only you can see the sites’ URL in this list. So, when you’re ready to check your favorite sports team’s scores, you simply type in a couple letters and autocomplete will finish the job.

Autocomplete on Android (Left) and iOS (Right)


Check it out here:

There’s also something new for users where they can add search engines from any site that has a search field. If you want to search from somewhere outside our list of suggested search engines, go ahead and add it! For example, if you want to see a movie this weekend but don’t want to waste hours on a bad movie, you can check We know that choice is important to our power users so this new function allows them to set up their preferred way for searching the web.

One of the reasons users love Focus is because of the faster load times due to our auto-blocking of ads and trackers. It quickly gets you to the places where you want to go and sets us apart from other browsers. We built Focus as the quickest and easiest privacy browser built with you in mind.

The latest version of Firefox Focus can be downloaded on Google Play and in the App Store.

The post Firefox Focus Adds Quick Access Without Sacrificing Users’ Privacy appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mozilla Reps Community: New Council Members – Autumn 2017

Mozilla planet - wo, 13/12/2017 - 23:34

We are very happy to announce our 2 new council members Prathamesh Chavan and Mayur Patil are fully onboarded and already working moving the Mozilla Reps program forward.

Of course we would like to thank a lot the 2 outcoming members: Michael Kohler and Alex Lakatos.

Michael and Alex: you have worked extremely hard to move the program forward and your input and strategic thinking have inspired the rest of the Reps.

Prathamesh and Mayur: a warm welcome. We we are very excited to have you and can’t wait to build the program together.

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!


Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Actual Input Latency: cross-browser measurement and the Hasal testing framework

Mozilla planet - wo, 13/12/2017 - 16:07

Editor’s Note: This post is also featured on the 2017 Performance Calendar.

This is a story about an engineering team at Mozilla, based in Taipei, that was tasked with measuring performance and solving some specific performance bottlenecks in Firefox. It is also a story about user-reported performance issues that were turned into actionable insights. It is the story of how we developed Hasal, a framework for testing web performance between different browsers. Hasal takes a new approach to testing that considers user perception in the process.

Back in 2016, Firefox performance was problematic. We had many issues to address. One of the critical issues had to do with user reports about performance problems of Firefox on office web applications — regarding slow page-loads as well as sluggish response times.

Taking these seriously, but also experiencing many of these issues during our daily work, identifying the root cause for these performance issues was a top priority for us. Unfortunately, user sentiments is very often unspecific which makes identifying specific problems and evaluating their impact hard. So, we decided to take a new approach.

We were trying to implement a framework without using WebDriver, which relies on specialized browser APIs and JavaScript injection to manipulate the browser. Instead we used Sikuli, which submits native-like I/O signals to the computer to simulate user action. We built a framework that lets you define precise user interactions on a web application and measure input latency time using image recognition and real-time measurement instead of DOM events.

After working hard for about a year, we successfully implemented Hasal to compare the Actual Input Latency between different browsers on various web applications.

What is Actual Input Latency?

Based on Google’s “Measurement Performance with the RAIL Mode”, actual input latency is one of the key metrics that extends measurements of web performance beyond page load and focuses on responsiveness and in-app navigation.

In typical web applications, browsers spend most of their time on waiting for network resources to be downloaded and running JavaScript. The goal of the Hasal implementation was to focus on the latter, meaning that we measure the time elapsed between an I/O event and the web application’s first response as perceived by a user. Therefore, we measure only the time from user input to the screen’s initial change. We define this measure of time as the actual input latency.


Implementation Concepts Basic concept

Our goal was to implement a tool built from the perspective of user perception. We designed our workflow so that each and every simulated user step would be based on image recognition, and every numeric measurement would be based on visual analysis.

Basic flow


Our framework is based on the PyUnit framework in combination with Sikuli. You can see our workflow in the figure above. First, we have some prerequisite tasks in the setup() function. Next, it executes the simulated user steps in the run() function of a designated test. Last, we get the final output from teardown() function.

Each simulated user interaction is screen-captured for analysis. Hasal relies on video recording and image extraction to get the desired results. The details of how we do this will be explained in the next few paragraphs.

Run details

When entering the run() function, we send a simulated I/O event to specific icons, images, or areas of the screen through the JVM (Java Virtual Machine). This way, we simulate how people interact with the web application. Also, we send the event log to the terminal at the same time via JVM. This is considered a marker to identify when the I/O event triggered.

Video analysis

In the teardown() function, Hasal finishes desktop video recording and starts to analyze the video. The basic idea of getting the measured time is to calculate the actual frames played during two key frames. The first key frame is marked when the indication shows up in terminal, and we assume that there is a very little time delay between indication shown in terminal and submission of I/O event. The second key frame is the first screen change in a certain area of the browser. In other words, the second key frame is the indicator of web application’s response in the first place.

By calculating the actual frame number between the first key frame and second key frame, we can get the real response time of web application’s response to user action. For example, if we were recording in 90fps (frames per second), and we have 10 frames between 2 key frames as shown above, we will get an Actual Input Latency of 111.11 ms.

An Example of Actual Input Latency

To better illustrate the idea of how to get from a defined user interaction on a web application to Actual Input Latency measurements with Hasal, here is a small example from one of our test cases from our “social” category (as described in a previous post about performance testing).

In one testing scenario that looks at latency for opening an online chat, we measure the Actual Input Latency from the initial click to when the chat screen shows up. Here are the testing steps. These steps are the ones that are translated into the linked script:

The user wants to open a chat window on Facebook. Therefore, they select a friend from their list and click on the respective friend to launch the window and wait for it to load.

  • Open the browser and enter the URL in URL bar
  • Login to Facebook and wait for the page to be fully loaded
  • Make sure the friend list is not hidden
  • Move mouse cursor to one of the avatars in the friend list
  • Take snapshot (Snapshot 1)
  • Send the MouseDown Event
  • Send the MouseUp Event and simultaneously send the Message to the Terminal Console and take snapshot (Snapshot 2)
  • Wait for the chat window to be launched
  • Close the chat screen
  • Close the browser

The result of input latency will based on the Snapshot 1, 2 and the frames converted from video to come out the actual frames played.

More details on how each web application was tested can be found in the repository.

Current Results -Performance improvements in Firefox Quantum

This framework was initially targeted to find the performance differences between Firefox and other browsers in specific web applications. After we finished examining targeted applications, we started to help finding performance gaps in other major web applications.

Comparing response times for targeted web apps in Firefox<figcaption>The test result is based on the snapshot of web app.</figcaption>

We have dedicated the Hasal framework to measure and improve Firefox Quantum performance. Over time, we have seen great improvements on Actual Input Latency for different web applications. In the above figures, we can see that Firefox Quantum’s response time has improved by up to 6x. Based on Hasal results, we have filed more than 200 bugs of which more than 80% were fixed for our Firefox Quantum release.

Other findings

From time to time, we’ve seen some performance regressions in our tests without any real changes to our browser. After confirming with the respective third-party web service providers, we found out that we have been able to detect performance regressions on their side through our testing.

Limitations of the Hasal framework

The work on Hasal has been a constant iterative approach of implementation and testing. During the whole time of its development, we worked closely with other engineering teams at Mozilla to make Hasal as useful as possible. However, some limitations still exist which are important to keep in mind:

Measured time is limited by FPS

Since our measurement is based on captured frames, any action within one frame can’t be measured by this framework. In our laboratory environment where we record with 90fps, this threshold is at 11.11ms and any response faster than 11.11ms cannot be detected.

Overhead can vary in different browsers

Since the framework heavily relies on capturing desktop video, there is potential overhead introduced. We have tried to choose a recorder with little overhead that records from hardware directly. However, this approach could introduce different overhead in the different browsers due to different implementations for leveraging graphics card computation power.

JVM versioning can also affect the measured time

As the Hasal approach also relies heavily on the assumption that sending an indicator to the terminal should only have a very short delay compared to sending I/O events to the browser, we have done a lot of profiling to ensure that this assumption is correct. According to our profiling results, we are almost certain. However, we still found that different JVM version could break our assumption in certain environments. Sometimes, a newer JVM version can increase the time delay between sending the indicator to the terminal and sending the I/O events. We actually found that upgrading Java introduced a delay of 20ms.


While the current Hasal implementation has proven useful to guide engineering work on fixing critical performance issues, there are some open issues that we will need to target next to make Hasal useful as a general framework for testing performance.


This framework is a combination of many tools. So, it requires a time-consuming installation script to deploy the framework. That also raises the barrier to use, due to the difficulty of installing and reproducing our test results in other environments. Therefore, trying to make it simple and easier to install in others’ environment will be our next step in the future.


The overall concept of our framework should apply in mobile devices as well. However, we might need to change few things before we can proceed. First of all, the video recorder might need to be replaced by snapshot or screen capture software to minimize the CPU power consumption and improve the efficiency. Also, the host connected to the mobile device should be responsible for calculating the results.

Reducing overhead

We already talked about the issue of potentially introducing non-negligibleoverhead in some scenarios by relying on a software desktop video recorder. So, we’ve also considered having an alternative solution to record the whole desktop screen. For example, an external HDMI recorder or external high-speed camera would be a potential choice for us to further investigate.


When you find a scenario with a significant performance issue, typically you file a bug for it. However, a bug does not provide the detailed information during testing such as detailed profiler data needed to take the next action. That’s missing in our current framework. It’s not easy to figure out a way to combine the actual visual representation with the code stack. But we are trying to integrate them via indicators and markers in profiles. This could help us understand two different things in the same timeline and let engineers understand more about the situation.

Let us know what you think. Thanks!

Bobby Chien, Fu-Hung Yen, Mike Lien, Shako Ho, and Walter Chen of the Hasal team<figcaption>Bobby Chien, Fu-Hung Yen, Mike Lien, Shako Ho, and Walter Chen of the Hasal team .</figcaption>
Categorieën: Mozilla-nl planet