Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 2 weken 2 dagen geleden

Andy McKay: The Mozilla Bug Firehose - Design Decisions

do, 21/12/2017 - 09:00

There could be many blog posts about the Mozilla bug firehose. This is just about dealing with one particular aspect.

When a bug comes into Mozilla it needs to get triaged - someone needs to figure out what to do with it. Triaging is an effort to try and get bugs appropriately classified to see how critical the bug is. Part of shipping a product every 6 weeks is that we have to try and fix crucial bugs in each release. To do that you have to read the bugs reports and try to understand what's happening.

We set aside a certain amount of time for triage meetings every week to triage those bugs. With product, engineering management, QA management and a bunch of engineers, those meetings are expensive to the whole organisation. So we started getting pretty ruthless on those triage meetings to keep them as short as possible .

One category of bugs that we got a lot of (an awful lot of) in WebExtension is a "feature request". This is where someone is asking for feature that we currently don't provide in the WebExtensions API. This one bug could slow down a whole triage as all the people look at a bug and think about it and try to decide if its a good idea or not. That's a terribly expensive and inefficient way to spend the triage meeting.

Instead we decided that we can do a few things:

  • We can usually determine quickly if a bug is within the bounds of WebExtensions or not. If not, it gets closed quickly.
  • We can usually determine quickly if a bug is reasonable or not. If it is, it goes into the backlog.
  • The rest go into a seperate bucket called design-decision-needed.

Then we have a seperate design-decision-needed meeting. For that meeting we do a few things:

  • Pick a few bugs from the bucket. For arbitrary reasons we pick the 3 oldest and 3 newest.
  • Try to involve the community, so we let the community know about the meeting and bugs before hand. All our meetings are public, but we specifically feel community should be involved in this one.
  • Ping the reporter before the meeting asking if they want to come to the meeting or enter more details in the bug.
  • Try to spend 5 minutes on each bug.
  • Try to find someone to argue for the bug, especially when everyone thinks it shouldn't happen.

There are currently 107 bugs needing a decision, 57 have been denied, 133 have been approved and 2 deferred. The deferred bugs are ones where we still have no real idea what to do with.

We are hoping this process means that:

  • Contributors can feel comfortable that before they start working on a bug, they know the patch will be accepted.
  • Everyone's time is respected, from developers to the reporters.
  • The process constrains internal developers time to prevent them from being overwhelmed by external requests.

The single best part of this process, was that we got our awesome Community Manager - Caitlin to run these triages. She does a much better job of working with the contributors and making them welcome than I can do.

So far we feel this process has been pretty good. One thing we need to improve is following up with comments on the bug quickly after the meeting. Some have fallen through the cracks and we struggle to remember later on what we discussed. Ideally, we do need more contributors to work on the bugs that have been marked as design-decision-approved. They are all there for the taking!

Categorieën: Mozilla-nl planet

Mozilla B-Team: happy shiney bmo push day

do, 21/12/2017 - 05:41

release tag

the following changes have been pushed to

  • [1423391] Add additional phabricator settings to for running bmo-extensions demo
  • [1424787] Due Date on bug modal is 1 day ahead
  • [1424155] Write scripts to import/export attachments to disk
  • [1376826] New HTML Header for BMO
  • [1425119] Allow the new-bug interface to be used
  • [1424940] Support HTML5 datepicker
  • [1403777] Migrate urlbase from params to localconfig
  • [1409957] Create polling daemon to query Phabricator for recent transcations and update bug data according to revision changes
  • [1422329] The phabricator conduit API method feed.query_id return data format has changed so the daemon needs to be updated
  • [1420771] Remove global footer
  • [1426424] feed daemon complains when trying to set an inactive review flag
  • [1361890] Remove asset concatenation
  • [1426117] Failure when opening a bug: Invalid parameter passed to Bugzilla::Bug::new_from_list: It must be numeric.
  • [905763] Fix named anchors in various pages so that the Sandstone theme header can be set to a fixed position
  • [1424408] “Sign in with GitHub” button triggers a bugzilla security error, if I’m viewing a page with e.g. “t=”

discuss these changes on

Categorieën: Mozilla-nl planet

The Rust Programming Language Blog: Rust in 2017: what we achieved

do, 21/12/2017 - 01:00

Rust’s development in 2017 fit into a single overarching theme: increasing productivity, especially for newcomers to Rust. From tooling to libraries to documentation to the core language, we wanted to make it easier to get things done with Rust. That desire led to a roadmap for the year, setting out 8 high-level objectives that would guide the work of the team.

How’d we do? Really, really well.

There’s not room in a single post to cover everything that happened, but we’ll cover some of the highlights below.

The goals for 2017 Rust should have a lower learning curve Rust should have a pleasant edit-compile-debug cycle
  • The cargo check workflow
    • Cargo now offers a check subcommand which can be used to speed up the edit-compile cycle when you’re working on getting your code to pass the compiler’s checks. This mode, in particular, skips producing executable artifacts for crates in the dependency tree, instead doing just enough work to be able to type check the current crate.
  • Incremental recompilation
    • The cornerstone of our approach to improving compilation times is incremental recompilation, allowing rebuilds to reuse significant pieces of work from prior compilations. Over the course of the year we have put a lot of work into making this happen and now we are happy to announce that incremental compilation will start riding the trains with the next beta version of the compiler in January and become available on the stable channel with Rust 1.24 in February!
    • You can see how incremental recompilation performs in practice on some of our key benchmarks below. Note that -opt refers to optimized builds, “best case” refers to a recompilation with no changes, and println refers to a recompilation with a small change, like adding a println call to a function body. We expect the 50+% speedups we’re seeing now to continue to grow next year as we push incremental recompilation more deeply through the compiler.
    • Together with the changes in the compiler we will also update Cargo to use incremental recompilation by default for select use cases, so you can take advantage of improved compile times without the need for additional configuration. Of course you will also be able to opt into and out of the feature on a case by case basis as you see fit.

Incremental recompilation benchmarks

Rust should provide a solid, but basic IDE experience
  • Rust now has solid IDE support in IntelliJ and via the Rust Language Server (RLS). Whether you prefer a fully-featured IDE or a more lightweight editor with IDE features, you can boost your productivity by taking advantage of great Rust integration.
  • IntelliJ. Rust has official support in JetBrains’ IDEs (IntelliJ IDEA, CLion, WebStorm, etc.), which includes:
    • Finding types, functions and traits across the whole project, its dependencies and the standard library.
    • Hierarchical overview of the symbols defined in the current file.
    • Search for all implementations of a given trait.
    • Go to definition of symbol at cursor.
    • Navigation to the parent module.
    • Refactoring and code generation
  • RLS. The RLS is an editor-independent source of intelligence about Rust programs. It is used to power Rust support in many editors including Visual Studio Code, Visual Studio, and Atom, with more in the pipeline. It is on schedule for a 1.0 release in early 2018, but is currently available in preview form for all channels (nightly, beta, and stable). It supports:
    • Code completion (using Racer)
    • Go to definition (and peek definition if the editor supports it)
    • Find all references
    • Find impls for a type or trait
    • Symbol search (current file and project)
    • Reformatting using rustfmt, renaming
    • Apply error suggestions (e.g., to add missing imports)
    • Docs and types on hover
    • Code generation using snippets
    • Cargo tasks
    • Installation and update of the RLS (via rustup)
Rust should integrate easily into large build systems
  • Alternative registries. Cargo now has unstable support for installing crates from registries other than This will enable companies to manage and use internal crates as easily as open source crates. Work is underway developing crate servers that are more tailored for private use than the server is.
  • Cargo as a component. A lot of work this year went into gathering constraints from stakeholders who want to integrate Rust crates into a large existing build system (like Bazel). The Cargo team has formulated a vision of Cargo as a suite of components that can be customized or swapped out, making it easy for an external build system to manage the work it is built to do, while still integrating with and with Cargo workflows. While we did not get as far as we hoped in terms of implementing this vision, there is ongoing work spiking out “build plan generation” to a sufficient degree that it can support the Firefox build system and Tup. This initial spike should provide a good strawman for further iteration in early 2018.
Rust should provide easy access to high quality crates Rust should be well-equipped for writing robust servers
  • Futures and Tokio
    • Much of the story for Rust on the server has revolved around its async I/O story. The futures crate was introduced in late 2016, and the Tokio project (which provides a networking-focused event loop for use with futures) published its 0.1 early in 2017. Since then, there’s been significant work building out the “Tokio ecosystem”, and a lot of feedback about the core primitives. Late in the year, the Tokio team proposed a significant API revamp to streamline and clarify the crate’s API, and work is underway on a book dedicated to asynchronous programming in Rust. This latest round of work is expected to land very early in 2018.
  • Async ecosystem
  • Generators
    • Thanks to a heroic community effort, Rust also saw experimental generator support land in 2017! That support provides the ingredients necessary for async/await notation, which is usable today on nightly. Further work in this area is expected to be a high priority in early 2018.
  • Web frameworks
    • Finally, sophisticated web frameworks like Rocket (sync) and Gotham (async) have continued to evolve this year, and take advantage of Rust’s expressivity to provide a robust but productive style of programming.
Rust should have 1.0-level crates for essential tasks
  • Libz Blitz. The library team launched the Libz Blitz this year, a major effort to vet and improve a large number of foundational crates and push them toward 1.0 releases. It was a massive community effort: we performed a crowd-sourced “crate evaluation” every two weeks, fully vetting a crate against a clear set of guidelines, assessing the issue tracker, and sussing out any remaining design questions. While not all of the assessed crates have published a 1.0 yet, they are all very close to doing so. The full list includes: log, env_logger, rayon, mio, url, num_cpus, semver, mime, reqwest, tempdir, threadpool, byteorder, bitflags, cc-rs, walkdir, same-file, memmap, lazy_static, flate2.
  • API Guidelines. A great by-product of the Libz Blitz is the API Guidelines book, which consolidates the official library team API guidance as informed by the standard library and the Libz Blitz process.
Rust’s community should provide mentoring at all levels
  • We ran 5 RustBridge Workshops in 2017, in Kyiv, Ukraine; Mexico City, Mexico; Portland, OR, USA; Zurich, Switzerland; and Columbus, OH, USA! RustBridge workshops aim to get underrepresented folks started in Rust. Attendees get an introduction to syntax and concepts, work on some exercism exercises, and build a web application that delivers emergency compliments and crab pictures. We hope to scale this program and help more folks run more workshops in 2018!
  • The Increasing Rust’s Reach program brought people with skills from other areas (such as teaching) and with different experiences into Rust so that we can improve in areas where the community is missing these skills and experiences. The participants have helped immensely, and many are planning to continue helping in the Rust community going forward. We’re glad they’re here! Here are some blog posts about the experience:
  • Last but not least, we also launched the first Rust impl Period. This was an ambitious effort to simultaneously help get a lot of new people contributing to the Rust ecosystem while also getting a lot of things done. To that end, we created 40+ working groups, each with their own focus area, leaders, and chat channel. These groups identified good “entry points” for people who wanted to contribute, and helped mentor them through the changes needed. This event was a wild success and resulted in changes and contributions to all areas of Rust, ranging from the compiler internals to documentation to the ecosystem at large. To those of you who participated, a great big thank you — and please keep contributing! To those of you who didn’t get a chance, don’t worry: we hope to make this a regular tradition.

We’ll be spinning up the 2018 roadmap process in the very near future; watch this space!

Thank you!

We got a staggering amount of work done this year — and the “we” here includes an equally staggering number of people. Because the work has been spread out over so many facets of the project, it’s hard to provide a single list of people who contributed. For the impl period specifically, you can see detailed contribution lists in the newsletters:

but of course, there have been contributions of all kinds during the year.

In this post, I’d like to specifically call out the leaders and mentors who have helped orchestrate our 2017 work. Leadership of this kind — where you are working to enable others — is hard work and not recognized enough. So let’s hand it to these folks!

  • Cargo
    • carols10cents, for sustained leadership and mentoring work throughout the year on
  • Community
  • Compiler
    • nikomatsakis, for an incredible amount of leadership, organization, and mentoring work, and for a lot of high-value hacking on NLL in particular.
    • arielb1, likewise for mentoring and hacking work, spanning both NLL and the rest of the compiler.
    • michaelwoerister, for pushing continuously on delivering incremental recompilation, and creating opportunities for others to join in throughout the year.
    • eddyb, for continuing to act as a general compiler guru, and for tackling some truly heavy lifts around const generics this year.
  • Dev tools
    • nrc, for overseeing the dev tools group as a whole, and for steady work toward shipping the RLS and rustfmt, despite many thorny infrastructure problems to get there.
    • matklad, for the incredible work on IntelliJ Rust.
    • xanewok, for enormous efforts making the RLS a reality.
    • fitzgen, for happily corralling a huge contributor base around bindgen.
  • Docs
    • steveklabnik, for launching and overseeing a hugely exciting revamp of rustdoc.
    • quietmisdreavus, for overseeing tons of activity in the docs world, but most especially for helping the community significantly improve rustdoc this year.
  • Infrastructure
    • mark-simulacrum, for getting the perf website to a highly useful state, and for overhauling rustbuild to better support contribution.
    • aidanhs, for coordinating maintenance of crater.
  • Language
    • withoutboats, for keeping us focused on the programmer experience and for helping the community navigate discussion around very thorny language design issues.
    • cramertj, for keeping us focused on shipping, and in particular building consensus around some of the topics where that’s been hardest to find: impl Trait, and module system changes.
    • nikomatsakis, for making the NLL RFC so accessible, and pioneering the idea of using a separate repo for it to allow for greater participation.
  • Libraries
    • brson, for envisioning and largely overseeing the Libz Blitz initiative.
    • kodraus, for gracefully taking over the Libz Blitz and seeing it to a successful conclusion.
    • dtolnay, for taking on the API guidelines work and getting it to a coherent and polished state.
    • budziq, for a ton of work coordinating and editing contributions to the cookbook.
    • dhardy, for leading a heroic effort to revamp the rand crate.

Technical leaders are an essential ingredient for our success, and I hope in 2018 we can continue to grow our leadership pool, and get even more done — together.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Plugging in on Policy

wo, 20/12/2017 - 23:00
Mozilla Tech Policy Fellows continue to lead policy conversations around the world.


When Mozilla rolled out a new fellowship focused on tech policy this past June, the goal was to gather some of the world’s top policymakers in tech to continue advancing the important initiatives they were working on in government as fellows with Mozilla.

We rounded up 10 fellows from the U.S., Brazil, India, and Kenya as part of the initial cohort. Fellows are spending the year keeping the Internet open and free both by furthering the crucial work they had already been leading, and by finding new ways to add to forward-thinking policy efforts.

Fellows are urging policymakers to keep net neutrality in the United States and to adopt it in India, they’re promoting data privacy and security in East Africa and Brazil, and they’re encouraging increased access to high-quality broadband in vulnerable communities in rural, urban, and tribal areas everywhere. The fellows have all described their work in depth on Mozilla’s network blog:

Alan Davidson is advancing policies and practices to support building the field of public interest technologists — the next generation of leaders with expertise in technology and public policy who we need to guide our society through coming challenges such as encryption, autonomous vehicles, blockchain, cybersecurity, and more.

Amina Fazlullah is exploring policies that will help lower the cost of broadband access, support broad adoption, ensure that applications are developed with the most vulnerable users in mind, promoting a fair and open Internet, and identifying and highlighting the good work of digital inclusion organizations around the world.

Camille Fischer worked on policies that support legal protections for privacy rights in the U.S. Camille completed her fellowship and recently joined the Electronic Frontier Foundation as a fellow working on free speech and government transparency.

Caroline Holland is working to promote competition for a healthy Internet to make sure consumers have access to affordable and competitive high speed broadband and equal access to the lawful content they desire.

Amba Kak is moving policies forward on net neutrality, zero rating and the open Internet in India, including supporting the country’s recent commitment to comprehensive net-neutrality protection.

— In East Africa, Linet Kwamboka is working to promote policies that support data protection and privacy as well as data literacy for the public.

Terah Lyons explored the global role of stakeholders from public, private, civil society, and academic stakeholder communities on AI policy to address issues related to ethics, accountability, the future of work, and safety and control. Terah recently completed her fellowship and joined the Partnership on AI as its first Executive Director.

–From Brazil, Marília Monteiro is working to analyze tech policy issues from a consumer protection perspective to ensure that policy makers are balancing consumer interests with technology and innovation advances.

Jason Schultz is exploring AI’s impact on open technologies including the need for new methods both to measure the negative impacts of AI closure and to adapt alternatives in meaningful technological, economic, and social ways.

Gigi Sohn is continuing her nearly 30-year fight for fast, fair, and open networks, including working to keep net neutrality in the U.S.

The Tech Policy Fellows gathered at MozFest, Mozilla’s annual festival for the open Internet movement, in October. They led workshops, roundtables, and panels, and — of course — met Foxy.

Mozilla Tech Policy Fellow Amina Fazlullah meets Foxy at MozFest.

Fellows are also contributing to the upcoming 2018 version of the Internet Health Report (you can get involved with that project, too!) and they are working closely with a dedicated Advisory Board, made up of seven top experts and supporters of a free and open Internet located in six different countries.

Mozilla will begin recruiting for a new cohort of fellows in 2018 — keep an eye out for our announcement and help us bring together even more amazing tech policy leaders to advance this crucial work.

The post Plugging in on Policy appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Chris H-C: Another Stay of Execution for Firefox Users on Windows XP

wo, 20/12/2017 - 21:44


Firefox users who are on Windows XP now have until August 28, 2018 to upgrade their machines. In the grand Internet tradition I will explore this by pretending someone is asking me questions.


The last Firefox release supporting Windows XP is Firefox ESR 52. Previously Firefox ESR 52 was set to end-of-life on or around May of 2018 after the next ESR, Firefox ESR 59, had been released and stabilized. Now, with an email to the Enterprise, Dev Platform, Firefox Dev, and Mobile Firefox Dev mailing lists, :Sylvestre has announced that the next ESR will be Firefox ESR 60, which extends the Firefox ESR 52 end-of-life to August 28, 2018.

No, not “Why did it change,” Why should anyone still care about Windows XP? Hasn’t it been out-of-service for a decade or something?

Not quite a decade, but the last release of Windows XP was over nine years ago, and even Microsoft’s extended support tapped out nearly four years ago.

But as to why we should care… well, Windows XP is still a large-ish portion of the Firefox user base. I don’t have public numbers in front of me, but you can see the effect the Windows XP Firefox population numbers had on the Firefox Hardware Report when we diverted them to ESR this past March. At that time they were nearly 8.5% of all Firefox users. That was more than all versions of Mac Firefox users.

Also, it’s possible that these users may be some of the most vulnerable of the Internet’s users. They deserve our thought.

Oh, okay, fine. If they matter so much, why aren’t we supporting them forever?

As you can see from the same Firefox Hardware Report, the number of Windows XP Firefox users was in steady decline. At some point our desire and capability to support this population of users can no longer match up with our desire to ship the best experience to the most users.

Given the slope of the decline in the weeks leading up to when we migrated Windows XP Firefox users to Firefox ESR, we ought to be getting pretty close to zero. We hate to remove support from any users, but there was a real cost to supporting Windows XP.

For instance, the time between the ESR branch being cut and the first Windows XP-breaking change was a mere six days. And it wasn’t on purpose, we were just fixing something somewhere in Gecko in a way that Windows XP didn’t like.

So who are we going to drop support for next?

I don’t know of any plans to drop support for any Operating Systems in the near future. I expect we’ll drop support for older compilers in our usual manner, but not OSs.

That pretty much sums it up.

If you have any questions about Firefox ESR 60, please check out the Firefox ESR FAQ.


Categorieën: Mozilla-nl planet

Firefox Test Pilot: Students Pitch New Accessibility Features for Firefox

wo, 20/12/2017 - 20:56

In early October, the Test Pilot team helped kick off an undergraduate product design course at design and media school Ravensbourne in London. The partnership with Ravensbourne was spearheaded by Mozilla’s Open Innovation team with the goal of generating ideas for Mozilla’s innovation pipeline. With Test Pilot as the “client” for the course, students working in seven small teams have been iterating on design concepts to advance accessibility in Firefox. Test Pilot team members John Gruen and I were back in London last month to evaluate the student’s final product pitches. We ultimately chose two winning teams.

First Place: Team Spectrum

The winning team set out to improve the browser experience for individuals with phonological dyslexia. After conducting both secondary and primary research, the team identified an opportunity to help alleviate the tired eyes and general cognitive overhead that individuals with dyslexia experience when reading text on the web. Team Spectrum’s solution is an add-on that allows people to enlarge and embolden text and apply color filters to increase contrast — all from the browser toolbar.

<figcaption>Screenshot from Team Spectrum’s prototype showing a large cursor intended to make it easier to enlarge and embolden text for more comfortable reading</figcaption>

The team conducted some initial usability testing and found that their solution increased reported ease of reading and reading speed.

Honorable Mention: Team Elderline

The second place team was interested in helping older adults use the browser more easily by creating an add-on to surface customization options. Through their research, Team Elderline determined that among the biggest opportunities were to support adults over 75-years-old in: reading online more comfortably, reducing confusing ads on webpages, and understanding icons representing valuable browser controls. The team’s solution is a control panel that lets people easily manipulate the current webpage to make content more accessible and manageable.

<figcaption>Screenshot from Team Elderline’s prototype showing control panel options tailored to the current webpage</figcaption>

Based on what they learned from initial usability testing of their concept, Team Elderline’s final concept emphasized plain language and clearer selection indicators.

In addition to the pitches by Teams Spectrum and Elderline, the other student teams presented a range of intriguing concepts to support challenges encountered by older adults, students with dyslexia, and individuals with Attention Deficit Hyperactivity Disorder (ADHD) in the browser.

Next Steps

We will be sharing the winning concepts with the broader Test Pilot team and investigating the feasibility of turning the concepts into future experiments. Thanks to all of the Ravensbourne students for your fresh thinking on improving Firefox through accessibility! Read more about our collaboration with Ravensbourne on their blog.

Students Pitch New Accessibility Features for Firefox was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

The Firefox Frontier: Private shopping is smart holiday shopping

wo, 20/12/2017 - 20:47

Maybe Santa’s running a little late this year. There are gifts left to buy. You’re shopping online. You’re hoping you make it under the wire for shipping. Basically, you’re trying … Read more

The post Private shopping is smart holiday shopping appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Air Mozilla: Sheriffing episode 1 - failure starring and beta uplifts

wo, 20/12/2017 - 19:35

Sheriffing episode 1 - failure starring and beta uplifts 00:00 identifying failure in second line of log summary 01:19 failure not in log summary 02:14 test name of failing test not in log summary...

Categorieën: Mozilla-nl planet

Air Mozilla: Sheriffing episode 1 - failure starring and beta uplifts

wo, 20/12/2017 - 19:35

Sheriffing episode 1 - failure starring and beta uplifts 00:00 identifying failure in second line of log summary 01:19 failure not in log summary 02:14 test name of failing test not in log summary...

Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding - Episode 124

wo, 20/12/2017 - 19:00

The Joy of Coding - Episode 124 mconley livehacks on real Firefox bugs while thinking aloud.

Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding - Episode 124

wo, 20/12/2017 - 19:00

The Joy of Coding - Episode 124 mconley livehacks on real Firefox bugs while thinking aloud.

Categorieën: Mozilla-nl planet

Air Mozilla: Weekly SUMO Community Meeting December 20, 2017

wo, 20/12/2017 - 18:00

Weekly SUMO Community Meeting December 20, 2017 This is the SUMO weekly call

Categorieën: Mozilla-nl planet

Air Mozilla: Weekly SUMO Community Meeting December 20, 2017

wo, 20/12/2017 - 18:00

Weekly SUMO Community Meeting December 20, 2017 This is the SUMO weekly call

Categorieën: Mozilla-nl planet

The Mozilla Blog: Firefox is Now on Amazon Fire TV – Happy Holiday Watching

wo, 20/12/2017 - 17:50
Fast for good, just right for watching video at home

As many of us prepare to be with families and close friends for the holidays, I’m excited to announce that Mozilla is bringing the speed of Firefox and the power of the web onto the TV with an established family of streaming media devices, just in time for the holidays.

As of this morning we have shipped Firefox for Fire TV, a browser for discovering and watching web video on the big screen TV for users to install on their Amazon Fire TV and Fire TV stick. The app is now available on 2nd generation or newer devices in the Amazon Appstore for free, aimed at U.S. customers, but available for anyone else that wants to try.

It’s a sign of the strength of Firefox Quantum that Amazon came to us looking for a partner who could bring more of the full web to its customers. The team came together to port, design and release a best-in-class application designed for the 10-foot, leanback experience and that makes watching videos as easy as clicking, searching or entering a URL. With this in-product application, we will be able to continue to drive our mission and reach existing and new users no matter what device they’re using.

“Our goal is to make it easy for customers to access the broadest range of content in the world,” said Marc Whitten, vice president, Amazon Fire TV and Appstore. “We’re excited to bring web browsing to customers on every Fire TV device in every country where we’re sold.”

Especially on this wave of a successful release of Firefox Quantum, extending our top-notch browser experience into so many livingrooms was an opportunity too large to pass. It also gave us new avenues to deepen our relationships with consumers and extend our mission to an even wider audience.

We believe passionately that you should have the ability to get to watch what you want or view the web how you want to. So, if you already have a Fire TV, consider using Firefox for Fire TV. (And if you haven’t finished your holiday shopping, you might want to add a Fire TV to your list.)

We hope you enjoy this last minute holiday gift from us, and expect more to come from Firefox for this and our other platforms, as we strive to bring our users the best the web can offer, keeping it open and accessible to all.

The post Firefox is Now on Amazon Fire TV – Happy Holiday Watching appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Wladimir Palant: Taking a break from Adblock Plus development

wo, 20/12/2017 - 10:33

After twelve years of working on Adblock Plus, the time seems right for me to take a break. The project’s dependence on me has been on the decline for quite a while already. Six years ago we founded eyeo, a company that would put the former hobby project on a more solid foundation. Two years ago Felix Dahlke took over the CTO role from me. And a little more than a month ago we launched the new Adblock Plus 3.0 for Firefox based on the Web Extensions framework. As damaging as this move inevitably was for our extension’s quality and reputation, it had a positive side effect: our original Adblock Plus for Firefox codebase is now legacy code, not to be worked on. Consequently, my Firefox expertise is barely required any more; this was one of the last areas where replacing me would have been problematic.

So I am taking all of 2018 off. It’s not merely about being tired of working on the same project. I also noticed that I’ve grown irrationally attached to XUL and Gecko, as I’ve accumulated lots of knowledge in that area over the years and helped many others learn as well. Consequently, while I see Mozilla’s motivation for their rushed Web Extensions move, I cannot feel positive about it. This isn’t a good prerequisite when staying in touch with Mozilla is part of the job description.

Next year I will only get involved in Adblock Plus if my assistance is absolutely required (in other words: most likely not at all). Instead, I want to get a clear head, and learn new things. My Easy Passwords extension is a very promising project that definitely needs more of my time, and I would like to contribute to a bunch of open source projects. I also want to spend more time doing security research again, which should help pay the bills as a side effect.

Theoretically, there is already no reason for people to contact me about Adblock Plus directly. Many still do however, so here is a quick reference:

  • If a Firefox bug affects Adblock Plus, you should add this user to Cc on Bugzilla (don’t send emails there, nobody will receive them).
  • If you have an issue with Adblock Plus, the forums are the place to ask questions.
  • If you want to report an Adblock Plus bug, the issue tracker is the right place (again, ask in the forums if you need assistance).
  • If you want to contribute to Adblock Plus development, it’s easiest to do so on GitHub (other tools are used internally but you aren’t required to use them).
  • Questions regarding eyeo can be sent via the contact page or email addresses listed there.
Categorieën: Mozilla-nl planet

Honza Bambas: Firefox 57 delays requests to tracking domains

di, 19/12/2017 - 19:48

Firefox Quantum – version 57 – introduced number of changes to the network requests scheduler.  One of them is using data of the Tracking Protection database to delay load of scripts from tracking domains when possible during the time a page is actively loading and rendering – I call it tailing.

This has a positive effect on page load performance as we save some of the network bandwidth, I/O and CPU for loading and processing of images and scripts running on the site so the web page is complete and ready sooner.

Tracking scripts are not disabled, we only delay their load for few seconds when we can.  Requests are kept on hold only while there are site sub-resources still loading and only up to about 6 seconds.  The delay is engaged only for scripts added dynamically or as async.  Tracking images and XHRs are always delayed, as well as any request made by a tracking script.  This is legal according all HTML specifications and it’s assumed that well built sites will not be affected regarding functionality.

To make it more clear what we exactly do for site and tracking requests, this is how scheduling roughly looks like when tailing is engaged:

Firefox Quantum Tracker Tailing OK

And here with the tailing turned off:

Firefox Quantum Tracker Tailing OFF

This is of course not without problems.  For sites that are either not well built or their rendering is influenced by scripts from tracking domains there can be a visible or even functional regression.  Simply said, some sites need to be fixed to be able to adopt this change in scheduling.

One example is Google’s Page-Hiding Snippet, which may cause a web page to be blank for whole 4 seconds since the navigation start.  What happens?  Google’s A/B testing initially hides the whole web page with opacity: 0.  The test script first has to do its job to prepare the page for the test and only then it unhides the page content.  The test script is dynamically loaded by the analytics.js script.  Both the analytics.js and the test script are loaded from, a tracking domain, for which we engage the tailing delay.  As the result the page is blank until one of the following wins: 4 seconds timeout elapses or we load both the scripts and execute them.  For a common user this appears as a performance drawback and not a win.

Other example can be a web page referring an API of an async tracking script from a sync script, which obviously is a race condition, since there is no guarantee that an async script loads before a sync script.  There is a real life example of such not-well-built site using a Twitter API – window.twttr.  The twttr object is simply not there when the site’s script calls on it.  An exception is thrown and the rest of the site script is not executed breaking some of the page’s functionality.  That effected web page worked before tailing just because Twitter’s servers were fast to respond and executed sooner than the site script using the window.twttr object.  Hence, worked only by a lucky accident.  Note that sites with such race condition issues are 100% broken also when opened in Private Browsing windows or when Tracking Protection with just the default list is turned on.

To conclude on how useful the tailing feature is – unfortunately, at the moment I don’t have enough data to provide (it’s on its way, though.)  So far testing was made mostly locally and on our Web Page Test internal testing infrastructure.  The effect was unfortunately just hidden in the overall noise, hence more scientific and wide testing needs to be done.


EDIT: Interesting reactions on and Hacker News.


(Note: few somewhat off-topic comments have been trashed in case you wonder why they don’t appear here ; I will only accept comments bringing a benefit to discussion of this feature and its issues, thanks for understanding)

The post Firefox 57 delays requests to tracking domains appeared first on mayhemer's blog.

Categorieën: Mozilla-nl planet

Mozilla Thunderbird: New Thunderbird Releases and New Thunderbird Staff

di, 19/12/2017 - 18:14
Thunderbird is going strong at version 52 (ESR) and 57, 58 beta

In April 2017 Thunderbird released its successful Extended Service Release (ESR) version 52. This release has just seen it’s fifth “dot update” 52.5.0, where fixes, stability and minor functionality improvements were shipped.

Thunder 57 “Photon” Visual Refresh

Thunder 57 “Photon” Visual Refresh

Thunderbird 57 beta was also very successful. While Thunderbird 58 is equally stable and offers further cutting-edge improvements to Thunderbird users, the user community is starting to feel the impact of Mozilla platform changes which are phasing out so-called legacy add-ons. The Thunderbird technical leadership is working closely with add-on authors who face the challenge of updating their add-ons to work with the Mozilla interface changes. With a few usually simple changes most add-ons can be made to work in Thunderbird 58 beta. explains what needs to be done, and Thunderbird developers are happy to lend a hand to add-on authors. 

There has been some discussion about the modernisation of Thunderbird’s user interface. Thunderbird 57 is now following Mozilla’s Photon design, and there is also a new theme available based on the design by the Monterail team.

You can download the current Thunderbird beta here.

New Staff at Thunderbird

Since November 2016 the Thunderbird project has contracted the services of long-time Thunderbird volunteer contributor Jörg Knobloch. Since Jörg moved from being a volunteer to being a contractor, his focus has changed from chasing his favourite pet-hate bugs to taking on responsibility for the product. As the continuous integration engineer, he guarantees that Thunderbird Daily is always in sync with Mozilla core changes to keep Daily in a working order. Jörg manages all code for releases (beta and ESR) and monitors regressions as reported at BMO. As a Thunderbird and Mailnews peer he reviews the work of others and is part of the Engineering Steering Committee which is in charge of the code base.

In March 2017 Andrei Hajdukewycz joined the project. Andrei is the project’s infrastructure engineer. He’s been working on transitioning the project from using Mozilla infrastructure to procuring its own. He administers all the websites used by the project. There are many:*), the ISPDB, websites for telemetry, updates and release notes. And last not least: Add-ons. Soon Thunderbird add-ons will transition to Thunderbird’s own add-ons site. Watch this space!

In June 2017 Tom Prince joined the project as a build and release engineer. He makes sure that we can always build Daily, beta and ESR in en-US English and all localisations. He also helps out when diagnosing test and other miscellaneous failures. Most recently Tom has been migrating the Thunderbird build system from Buildbot to TaskCluster to future-proof this aspect of the project.

The project’s last hire in December 2017 has been Ryan Sipes (the guy posting this) as Community Manager. His task is to organise the community of voluntary contributors including add-on authors, spread the good news about Thunderbird, engage with donors to guarantee a solid income stream and be in touch with Thunderbird users.

These four staff members are just the beginning. The project is currently in the process of hiring developers to address some technical debt, fix some sore points in the software and transition the codebase from a mix of C++, JavaScript, XUL and XPCOM to be increasingly based on web technologies.

The Thunderbird project has taken control of the domain, of which the project will make increasing use. The domain is being updated to be more helpful to users and eventually become Thunderbird’s home on the web. The in-product Thunderbird start page has already been served via this domain for several months. And, the members of the Thunderbird Council have received email accounts @, powered by FastMail, a gift that we are very grateful for.

Categorieën: Mozilla-nl planet

Air Mozilla: Martes Mozilleros, 19 Dec 2017

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

Air Mozilla: Martes Mozilleros, 19 Dec 2017

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

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