Mozilla Nederland LogoDe Nederlandse

Firefox Nightly: Found a regression in Firefox? Give us details with mozregression!

Mozilla planet - ti, 11/10/2016 - 16:24

One of the most useful things you can do to help improve the quality for Firefox is to warn developers about regressions and give them all the details that will turn your issue into a useful actionable bug report.

This is actually the raison d’être of Nightly builds: parallelizing the work done by our communities of testers and developpers so as to catch regressions as early as possible and provide a feedback loop to developers in the early stages of development.

Complementary to nighly builds, we also have a nifty Python command line tool called mozregression (with an experimental GUI version but that will be for another post…) that allows a tester to easily find when a regression happened and what code changes are likely to have introduced the regression. This tool is largely the result of the awesome work of Julien Pagès, William Lachance, Heather Arthur and Mike Ling!

How do I install that cool tool?

tl;dr for people that do Python:
mozregression is a python package installable via pip, preferably in a virtualenv.

The installation steps detailed for mozregression on their documentation site are a bit short on details and tell you to install the tool with admin rights on linux/mac (sudo) which is not necessarily a good idea since we don’t want to potentially create conflicts with other python tools installed on your system and that may have different dependencies.

I would instead install mozregression in a virtualenv so as to isolate it from your OS, it works the same, avoids breaking something else on your OS and AFAIK, there is no advantage to having mozregression installed as a global package except of course having it available for all accounts on your system.

The installation steps in a terminal are those:

sudo apt install python-pip virtualenvwrapper echo 'export WORKON_HOME=~/.virtualenvs' >> ~/.bashrc source ~/.bashrc mkvirtualenv mozreg pip install mozregression mozregression --write-config

Here are line by line explanations because understanding is always better than copy-pasting and you may want to adapt those steps with your own preferences:

sudo apt install python-pip virtualenvwrapper

» Install the software needed to install python packages (pip) as well as the tool to create virtual environments for Python, the packae names here are for Debian-based distros.

echo 'export WORKON_HOME=~/.virtualenvs' >> ~/.bashrc

» Add to your bash config (adapt the destination if you use another shell) an environment variable indicating where your virtualenvs are stored in your home.

source ~/.bashrc

» Reload your updated .bashrc settings

mkvirtualenv mozreg

» Create a virtualenv called mozreg in ~/.virtualenvs/mozreg/. Your terminal should get the name of this virtualenv prepended to your terminal prompt such as (mozreg) ~ $>, that means you are in this virtualenv now.

pip install mozregression

» The previous step activated the mozreg virtualenv automatically, this step installs mozregression in ~/.virtualenvs/mozreg/lib/python2.7/site-packages/mozregression

mozregression --write-config

» In this final installation step, we are creating a configuration file for mozregression, the defaults are fine and detailed here.

I am set up, how do I use the tool?

Now that mozregression is installed in a virtualenv, first you need to know how to activate/deactivate your virtualenv.

As said previously, if you are already in your virtualenv, your terminal prompt will have (mozreg) mentionned. If you want to exit your virtualenv, type:


If you are not in your virtualenv, you can enter it with this command:

workon mozreg

You can now use mozregression following the Quick Start steps in the documentation but basically it boils down to indicating a good and a bad date for Firefox and the bad date is optional, so if you found a regression in Nightly that you know didn’t exist in say Firefox 49, launching mozregression is as easy as:

mozregression --good 49

Then test the nightly builds that mozregression downloads for you and indicate in the terminal ‘good’ or ‘bad’ for every build you try until the regression is found and you will get a message such as:

INFO: Last good revision: e3cff5e3ae3cc1b20d4861e7934e54c9e407a750 INFO: First bad revision: 5194eeb6ca2d34b5fca72d2a78d6a9ec95a36763 INFO: Pushlog: INFO: Looks like the following bug has the changes which introduced the regression:

The above text is what you should paste in the bug (for the record, this specific example is copied from bug 1307060), this is the information that will make your bug report actionable by a developer.

In a nutshell

Mozregression is a tool that allows power-users with no development skills to participate actively in the development of Firefox.

Providing such information to developers saves them a lot of time and most importantly, it allows bugzilla triagers to put the right developers in copy of the bug (“Hey Anne, it seems your patch in Bug XXX caused the regression described in this bug, could you have a look please?”)

Being a developer is not the only way you can help Firefox being a better browser, any advanced user able to use a terminal on his machine can participate, so don’t hesitate, file bugs and become a regression range finder!

Categorieën: Mozilla-nl planet

Torrent Sites Shutdown Update: Google Chrome, Mozilla Firefox blocks The ... - Enstarz

Nieuws verzameld via Google - ti, 11/10/2016 - 15:13


Torrent Sites Shutdown Update: Google Chrome, Mozilla Firefox blocks The ...
According to Science Report World, there are rumors that say that Google Chrome and Mozilla Firefox are not making steps in order to block access to the torrent site The Pirate Bay. It was said that the website has been declared as a phishing website ...
The Pirate Bay To Go Down With The Help Of Google, Mozilla Firefox ...Mobile & Apps
Google Chrome & Mozilla Firefox Tags The Pirate Bay As Phishing Site; Kickass ...Gamenguide
The Pirate Bay, Extra Torrent Shutdown Latest News, Update: Google Chrome ...Science World Report
University Herald -ChristianToday -Parent Herald
alle 32 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Curriculum Workshop: Ada Lovelace Day

Mozilla planet - ti, 11/10/2016 - 15:00

 Ada Lovelace Day Join us for this special Ada Lovelace Day webcast of the Mozilla Curriculum Workshop as we recognize the challenges, work and contributions of women leaders...

Categorieën: Mozilla-nl planet

The Pirate Bay To Go Down With The Help Of Google, Mozilla Firefox ... - Mobile & Apps

Nieuws verzameld via Google - ti, 11/10/2016 - 14:07

Mobile & Apps

The Pirate Bay To Go Down With The Help Of Google, Mozilla Firefox ...
Mobile & Apps
Just recently, The Pirate Bay started getting blocked again by two popular browsers Google Chrome and Mozilla Firefox. It was tagged before by the following browsers as a type of "phishing site," making the access to the site appear to be riskier ...
Torrent Sites Shutdown Update: Google Chrome, Mozilla Firefox blocks The ...Enstarz
The Pirate Bay, Extra Torrent Shutdown Latest News, Update: Google Chrome ...Science World Report
Google Chrome & Mozilla Firefox Tags The Pirate Bay As Phishing Site; Kickass ...Gamenguide
University Herald -ChristianToday -Parent Herald
alle 34 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Daniel Stenberg: poll on mac 10.12 is broken

Mozilla planet - ti, 11/10/2016 - 13:26

When Mac OS X first launched they did so without an existing poll function. They later added poll() in Mac OS X 10.3, but we quickly discovered that it was broken (it returned a non-zero value when asked to wait for nothing) so in the curl project we added a check in configure for that and subsequently avoided using poll() in all OS X versions to and including Mac OS 10.8 (Darwin 12). The code would instead switch to the alternative solution based on select() for these platforms.

With the release of Mac OS X 10.9 “Mavericks” in October 2013, Apple had fixed their poll() implementation and we’ve built libcurl to use it since with no issues at all. The configure script picks the correct underlying function to use.

Enter macOS 10.12 (yeah, its not called OS X anymore) “Sierra”, released in September 2016. Quickly we discovered that poll() once against did not act like it should and we are back to disabling the use of it in preference to the backup solution using select().

The new error looks similar to the old problem: when there’s nothing to wait for and we ask poll() to wait N milliseconds, the 10.12 version of poll() returns immediately without waiting. Causing busy-loops. The problem has been reported to Apple and its Radar number is 28372390. (There has been no news from them on how they plan to act on this.)

poll() is defined by POSIX and The Single Unix Specification it specifically says:

If none of the defined events have occurred on any selected file descriptor, poll() waits at least timeout milliseconds for an event to occur on any of the selected file descriptors.

We pushed a configure check for this in curl, to be part of the upcoming 7.51.0 release. I’ll also show you a small snippet you can use stand-alone below.

Apple is hardly alone in the broken-poll department. Remember how Windows’ WSApoll is broken?

Here’s a little code snippet that can detect the 10.12 breakage:

#include <poll.h> #include <stdio.h> #include <sys/time.h> int main(void) { struct timeval before, after; int rc; size_t us; gettimeofday(&before, NULL); rc = poll(NULL, 0, 500); gettimeofday(&after, NULL); us = (after.tv_sec - before.tv_sec) * 1000000 + (after.tv_usec - before.tv_usec); if(us < 400000) { puts("poll() is broken"); return 1; } else { puts("poll() works"); } return 0; }
Categorieën: Mozilla-nl planet

Hannes Verschore: Performance improvements to tracelogger

Mozilla planet - ti, 11/10/2016 - 12:47

Tracelogger is a tool to create traces of the JS engine to investigate or visualize performance issues in SpiderMonkey. Steve Fink has recently been using it to dive into google docs performance and has been hitting some road blocks. The UI became unresponsive and crashing the browser wasn’t uncommon. This is unacceptable and it urged me to improve the performance!


I looked at the generated log files which were not unacceptable large. The log itself contained 3 million logged items, while I was able to visualize 12 million logged items. The cheer number of logged items was not the cause. I knew that creating the fancy graphs were also not the problem. They have been optimized quite heavily already. That only left the overview as a possible problem.

The overview pane gives an overview of the engines / sub parts we spend time in. Beneath it we see the same, but for the scripts. The computation of this runs in a web worker to not make the browser unresponsive. Once in a while the worker gives back the partial result which the browser renders.

The issue was in the rendering of the partial result. We update this table every time the worker has finished a chunk. Generating the table is generally fast for the workloads I was testing, since there weren’t a lot of different scripts. Though running the full browser gave a lot of different scripts. As a result updating the table became a big overhead. Also you need to know this could happen every 1ms.

The first fix was to make sure we only update this table every 100ms. This is a nice trade-off between seeing the newest information and not making the browser unresponsive. This resulted in far fewer calls to update the table. Up to 100x less.

The next thing I did was to delay the creation of the table. Instead of creating a table it now shows a textual representation of the data. Only upon when the computation is complete it will show the sortable table. This was 10x to 100x faster.

Screenshot of tracelogger

In most cases the UI is now possible to generate the temporary view in 1ms. Though I didn’t want to take any chances. As a result if generating the temporary view takes longer than 100ms it will stop live updating the temporary view and only show the result when finished.

Lastly I also fixed a memory issue. A tracelog log is a tree of where time is spend. This is parsed breadth-first. That is better since it will give a quite good representation quite quickly, even if all the small logged items are not processed yet. But this means the UI needs to keep track of which items will get processed in the next round. This list of items could get unwieldy large. This is now solved by switching to dept-first traversal when that happens. Dept-first traversal needs no additional state to traverse the tree. In my testcase it previously went to 2gb and crashed. With this change the maximum needed memory I saw was 1.2gb and no crash.

Everything has landed in the github repo. Everybody using the tracelogger is advised to pull the newest version and experience the improved performance. As always feel free to report new issues or to contribute in making tracelogger even better.


Categorieën: Mozilla-nl planet

Wil Clouser: just got a lot easier to work on

Mozilla planet - ti, 11/10/2016 - 09:00

We originally built Test Pilot on top of Django and some JS libraries to fulfill our product requirements as well as keep us flexible enough to evolve quickly since we were a brand new site.

As the site has grown, we've dropped a few requirements, and realized that we were using APIs from our engagement team to collect newsletter sign ups, APIs from our measurement team for our metrics, and everything else on the site was essentially HTML and JS. We used the Django scaffolding for updating the experiments, but there was no reason we needed to.

I'm happy to highlight that as of today is served 100% statically. Moving to flat files means:

  • Easier to deploy. All we do is copy files to an S3 bucket. No more SQL migrations or strange half-pushed states.

  • More secure. With just flat files we have way less surface area to attack.

  • Easier to participate in. You'll no longer need to set up Docker or a database. Just check out the files, run npm install and you're done. (disclaimer: we just pushed this today, so we actually still need to update the documentation)

  • Excellent change control. Instead of using an admin panel on the site, we now use GitHub to manage our static content. This means all changes are tracked for free, we already have a process in place for reviewing pull requests, and it's easy to roll back or manipulate the data because it's all in the repository already.

If you want to get involved with Test Pilot, come join us in #testpilot (or webchat)!

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 151

Mozilla planet - ti, 11/10/2016 - 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 Blog Posts News & Project Updates Other Weeklies from Rust Community New Crates
  • SvgBobRus. Convert your ASCII diagram scribbles into happy little SVG.
  • Curryrs. A library for providing easy to use bindings between Rust and Haskell code.
  • NetBricks. A new network function framework based on Rust.
  • F3. A crate to play with STM32F3DISCOVERY development board with a Cortex-M4 microcontroller.
  • derivative: A set of attribute-enhanced #[derive] for built-in traits using Macro 1.1.
Crate of the Week

No crate was selected for CotW.

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

135 pull requests were merged in the last week.

New Contributors
  • Anthony Ramine
  • Christopher
  • Eric Roshan-Eisner
  • Florian Diebold
  • KillTheMule
  • Mathieu Borderé
  • Nick Stevens
  • p512
  • Razican
  • Stephen M. Coakley
  • 石博文
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 Style RFCs

Style RFCs are part of the process for deciding on style guidelines for the Rust community and defaults for Rustfmt. The process is similar to the RFC process, but we try to reach rough consensus on issues (including a final comment period) before progressing to PRs. Just like the RFC process, all users are welcome to comment and submit RFCs. If you want to help decide what Rust code should look like, come get involved!

FCP issues:

Other issues getting a lot of discussion:

No PRs this week.

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.

fn work(on: RustProject) -> Money

No jobs listed for this week.

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

Friends of the Forest

Our community likes to recognize people who have made outstanding contributions to the Rust Project, its ecosystem, and its community. These people are 'friends of the forest'.

This week's friends of the forest are:

dtolnay for outstanding work on Serde, taking it from a great library into an outstanding library, improving documentation significantly, being on top of the macros 1.1 transition, and even developing a new high level library for making custom derive under macros 1.1 easier to work with.

sgrif for outstanding work on Diesel, an ORM that will change the game for ORMs, and for being incredibly helpful and friendly with early adopters.

njn (on IRC) or nnethercote1 on GitHub for outstanding work on compiler perf. They've removed an allocation during HashSet creation, made TypedArena lazily allocate the first chunk, and more. They also have helped with adding a benchmarking script to compare two different compiler versions against the benchmarks in, which helps future work in this area.

I nominate TimNN for Friend of the Forest for his repeated and invaluable work minimizing and bisecting (example). Keep up the good work!

I'd like to nominate BurntSushi for Friend of the Forest. I think the multiples crates he contributed are both important and high quality. In addition to his code contributions to the ecosystem, he also did some good and informative write up about some of them.

I'd like to nominate GuillaumeGomez for the "Rust documentation superhero" title as well.

Submit your Friends-of-the-Forest nominations for next week!

Quote of the Week

< Celti> I just had a recruiter contact me for a Rust job requiring 3+ years of professional experience with it.

— From #rust.

Thanks to bluss for the suggestion.

Submit your quotes for next week!

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

Categorieën: Mozilla-nl planet