Mozilla Nederland LogoDe Nederlandse

Byron Jones: happy bmo push day!

Mozilla planet - do, 02/07/2015 - 07:59

the following changes have been pushed to

  • [1174057] Authentication Delegation should add an App ID column to associate api keys with specific callbacks
  • [1163761] Allow MozReview to skip user consent screen for Authentication Delegation
  • [825946] tracking flags should be cleared when a bug is moved to a product/component where they are not valid
  • [1149593] Hovering over “Copy Summary” changes the button to a grey box
  • [1171523] Change Loop product to Hello
  • [1175928] flag changes made at the same time as a cc change are not visible without showing cc changes
  • [1175644] The cpanfile created by defines the same feature multiple times, breaking cpanm
  • [1176362] [Voting] When a user votes enough to confirm an individual bug, the bug does not change to CONFIRMED properly
  • [1176368] [Voting] When updating votestoconfirm to a new value, bugs with enough votes are not moved to CONFIRMED properly
  • [1161797] Use document.execCommand(“copy”) instead of flash where it is available
  • [1177239] Please create a “Taskcluster Platform” product
  • [1144485] Adapt upstream Selenium test suite to BMO
  • [1178301] webservice_bug_update.t Parse errors: Bad plan. You planned 927 tests but ran 921
  • [1163170] Giving firefox-backlog-drivers rights to edit the Rank field anywhere it appears in bugzilla
  • [1171758] Persistent xss is possible on Firefox

discuss these changes on

Filed under: bmo, mozilla
Categorieën: Mozilla-nl planet

Mark Finkle: Random Thoughts on Management

Mozilla planet - do, 02/07/2015 - 05:11

I have ended up managing people at the last three places I’ve worked, over the last 18 years. I can honestly say that only in the last few years have I really started to embrace the job of managing. Here’s a collection of thoughts and observations:

Growth: Ideas and Opinions and Failures

Expose your team to new ideas and help them create their own voice. When people get bored or feel they aren’t growing, they’ll look elsewhere. Give people time to explore new concepts, while trying to keep results and outcomes relevant to the project.

Opinions are not bad. A team without opinions is bad. Encourage people to develop opinions about everything. Encourage them to evolve their opinions as they gain new experiences.

“Good judgement comes from experience, and experience comes from bad judgement” – Frederick P. Brooks

Create an environment where differing viewpoints are welcomed, so people can learn multiple ways to approach a problem.

Failures are not bad. Failing means trying, and you want people who try to accomplish work that might be a little beyond their current reach. It’s how they grow. Your job is keeping the failures small, so they can learn from the failure, but not jeopardize the project.

Creating Paths: Technical versus Management

It’s important to have an opinion about the ways a management track is different than a technical track. Create a path for managers. Create a different path for technical leaders.

Management tracks have highly visible promotion paths. Organization structure changes, company-wide emails, and being included in more meetings and decision making. Technical track promotions are harder to notice if you don’t also increase the person’s responsibilities and decision making role.

Moving up either track means more responsibility and more accountability. Find ways to delegate decision making to leaders on the team. Make those leaders accountable for outcomes.

Train your engineers to be successful managers. There is a tradition in software development to use the most senior engineer to fill openings in management. This is wrong. Look for people that have a proclivity for working with people. Give those people management-like challenges and opportunities. Once they (and you) are confident in taking on management, promote them.

Snowflakes: Engineers are Different

Engineers, even great ones, have strengthens and weaknesses. As a manager, you need to learn these for each person on your team. People can be very strong at starting new projects, building something from nothing. Others can be great at finishing, making sure the work is ready to release. Some excel at user-facing code, others love writing back-end services. Leverage your team’s strengthens to efficiently ship products.

“A 1:1 is your chance to perform weekly preventive maintenance while also understanding the health of your team” – Michael Lopp (rands)

The better you know your team, the less likely you will create bored, passionless drones. Don’t treat engineers as fungible, swapable resources. Set them, and the team, up for success. Keep people engaged and passionate about the work.

Further Reading

The Role of a Senior Developer
On Being A Senior Engineer
Want to Know Difference Between a CTO and a VP of Engineering?
Thoughts on the Technical Track
The Update, The Vent, and The Disaster
Bored People Quit
Strong Opinions, Weakly Held

Categorieën: Mozilla-nl planet

Karl Dubost: Web Components, Stories Of Scars

Mozilla planet - do, 02/07/2015 - 03:51

Chris Heilmann has written about Web Components.

If you want to see the mess that is the standardisation effort around web components right now in all its ugliness, Wilson Page wrote a great post on that on Mozilla Hacks. Make sure to also read the comments – lots of good stuff there.

Indeed a very good blog post to read. Then Chris went on saying:

Web Components are a great idea. Modules are a great idea. Together, they bring us hours and hours of fun debating where what should be done to create a well-performing, easy to maintain and all around extensible complex app for the web.

This is twitching in the back of my mind for the last couple of weeks. And I kind of remember a wicked pattern from 10 years ago. Enter Compound Document Formats (CDF) with its WICD (read wicked) specifications. If you think I'm silly, check the CDF FAQ:

When combining content from arbitrary sources, a number of problems present themselves, including how rendering is handled when crossing from one markup language to another, or how events propagate across the same boundaries, or how to interpret the meaning of a piece of content within an unanticipated context.


Simply put, a compound document is a mixture of content in any number of formats. Compound documents range from static (say, XHTML that includes a simple SVG illustration) to very dynamic (a full-fledged Web Application). A compound document may include its parts directly (such as when you include an SVG image in an XHTML file) or by reference (such as when you embed a separate SVG document in XHTML using an <object> element. There are benefits to both, and the application should determine which one you use. For instance, inclusion by reference facilitates reuse and eases maintenance of a large number of resources. Direct inclusion can improve portability or offline use. W3C will support both modes, called CDR ("compound documents by reference") and CDI ("compound documents by inclusion").

At that time, the Web and W3C, where full throttle on XML and namespaces. Now, the cool kids on the block are full HTML, JSON, polymers and JS frameworks. But if you look carefully and remove the syntax, architecture parts, the narrative is the same. And with the narratives of the battle and its scars, the Web Components sound very familiar to the Coupound Document Format.

Still by Chris

When it comes to componentising the web, the rabbit hole is deep and also a maze.

Note that not everything was lost from WICD. It helped develop a couple of things, and reimagine the platform. Stay tune, I think we will have surprises on this story. Not over yet.

Modularity has already a couple of scars when thinking about large distribution. Remember Opendoc and OLE. I still remember using Cyberdog. Fun times.


Categorieën: Mozilla-nl planet

What to Look Forward to from Firefox

Mozilla Futurereleases - do, 02/07/2015 - 03:22

We created Firefox more than a decade ago with a mission to give people transparency, choice and control online. Since then, the browser has continued to evolve its critical role in how users experience the Web and control their online lives.

That’s why at Mozilla we’re always focused on one question: how do we make Firefox even better and continue to delight users? Because we are different than most tech companies and work in the open, we are sharing some experiments centered around the three focus areas of our strategy.

Firefox Pillars


Uncompromised Quality

The first focus area is delivering an uncompromised user experience that ensures Firefox meets the most rigorous of quality and performance standards. This commitment is evident in the strides we’re making to improve the richest Web experiences like HTML5 video playback and game performance.  We’ll also soon deliver Firefox to new platforms, such as Firefox for iOS and Windows 10, where we will provide an independent and high-performing alternative to the stock browser.

Best Of The Web

Firefox is well known for giving users complete control over their Web experience while pushing the boundaries of the “modern browser.” Today, we’re working with more partners and developers around the world to highlight innovation and offer the best of the Web in Firefox. We showed this with our new search strategy for Firefox to promote choice and innovation and with new open technologies we build based on standards including Firefox Hello, the first WebRTC in-browser video chat tool made in partnership with Telefonica. We continue to pioneer open standards including WebVR, WebGL and WebRTC to advance the Web as the development platform.

Uniquely Firefox

Earlier this year, we asked users to identify what’s different about Firefox and the results reaffirmed our view that it’s important for Firefox to be increasingly recognized for attributes such as performance, trust and quality that align with our mission.

We value that our users trust us because we protect their choices and protect their privacy. That’s why we are experimenting with improvements to private browsing and other unique features for a major release focused on these three areas that we’ll share with Firefox users later this year.

Stay tuned for more.

Categorieën: Mozilla-nl planet

Planet Mozilla Interns: Jonathan Wilde: A Project Called Gossamer

Mozilla planet - do, 02/07/2015 - 02:00

A few summers back, I worked on the Firefox Metro project. The big challenge I ran into the first summer–back when the project was at a very early stage–was figuring out how to distribute early builds.

I wanted to quickly test work-in-progress builds across different devices on my desk without having to maintain a working copy and rebuild on every device. Later on, I also wanted to quickly distribute builds to other folks, too.

I had a short-term hack based on Dropbox, batch scripts, and hope. It was successful at getting rapid builds out, but janky and unscalable.

The underlying problem space–how you build, distribute, and test experimental prototypes rapidly?–is one that I’ve been wanting to revisit for a while.

So, Gossamer

This summer, Lyre Calliope and I have had some spare time to tinker on this for fun.

We call this project Gossamer, in honor of the Gossamer Albatross, a success story in applying rapid prototyping methodology to building a human-powered airplane.

We’re working to enable the following development cycle:

  1. Build a prototype in a few hours or maybe a couple days, and at the maximum fidelity possible–featuring real user data, instead of placeholders.
  2. Share the prototype with testers as easily as sharing a web page.
  3. Understand how the prototype is performing in user testing relative to the status quo, qualitatively and quantitatively.
  4. Polish and move ideas that work into the real world in days or possibly weeks, instead of months or years.
A First Proof-of-Concept

We started by working to build a simple end-to-end demonstration of a lightweight prototyping workflow:

Starting a two-week Mozilla heartbeat-style project sprint with @hellojwilde tomorrow involving Mozilla's browser.html experiment. Excited!

— Lyre Calliope (@CaptainCalliope) May 25, 2015

(Yeah, it took longer than two weeks due to personal emergencies on my end.)

We tinkered around with a few different ways to do this.

Our proof-of-concept is a simple distribution service that wraps Mozilla’s browser.html project. It’s a little bit like TestFlight or HockeyApp, but for web browsers.

To try an experimental build, you log in via GitHub, and pick the build that you want to test…and presto!

Sequence shortened.

About the login step: When you pick an experiment, you’re picking it for all of your devices logged in via that account.

This makes cross-device feature testing a bit easier. Suppose you have a feature you want to test on different form factors because the feature is responsive to screen dimensions or input methods. Or suppose you’re building a task continuity feature that you need to test on multiple devices. Having the same experiment running on all the devices of your account makes this testing much easier.

It also enables us to have a remote one-click escape hatch in case something breaks in the experiment you’re running. (It happens to the best developers!)

To ensure that you can trust experiments on Gossamer, we integrated the login system with Mozillians. Only vouched Mozillians can ship experimental code via Gossamer.

To ship an experimental build…you click the “Ship” button. Boom. The user gets a message asking them if they want to apply the update.

And the cool thing about browser.html being a web application…is that when the user clicks the “Apply” button to accept the update…all we have to do is refresh the window.

We did some lightweight user testing by having Lyre (who hadn’t seen any of the implementation yet) step through the full install process and receive a new updated build from me remotely.

We learned a few things from this.

What We’re Working On Next

There’s three big points we want to focus on in the next milestone:

  1. Streamline every step. The build service web app should fade away and just be hidden glue around a web browser- and GitHub-centric workflow.
  2. Remove the refresh during updates. Tooling for preserving application state while making hot code changes to web applications based on React (such as browser.html!) is widely available.
  3. Make the build pipeline as fast as possible. Let’s see how short we can make the delay from pushing new code to GitHub (or editing through GitHub’s web interface) to updates appearing on your machine.

We also want to shift our mode of demo from screencasts to working prototypes.

Get Involved

This project is still at a very early stage, but if you’d like to browse the code, it’s in three GitHub repositories:

  • gossamer - Our fork of browser.html.
  • gossamer-server - The build and distribution server.
  • gossamer-larch-patches - Tweaks to Mozilla’s larch project branch containing the graphene runtime. We fixed a bug and made a configuration tweak.

Most importantly, we’d love your feedback:

There’s a lot of awesome in the pipeline. Stay tuned!

Categorieën: Mozilla-nl planet

Mozilla CEO: Virtual-reality Firefox could be game-changer - USA TODAY

Nieuws verzameld via Google - do, 02/07/2015 - 00:01

Mozilla CEO: Virtual-reality Firefox could be game-changer
SAN FRANCISCO—Mozilla has started letting outside developers use a test version of its Firefox browser with new virtual-reality technology that could make surfing the web more like watching movies or playing video games. If the beta version of the ...

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Add-ons Update – Week of 2015/07/01

Mozilla planet - do, 02/07/2015 - 00:00

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

Add-ons Forum

As we announced before, there’s a new add-ons community forum for all topics related to AMO or add-ons in general. The Add-ons category is already the most active one on the community forum, so thank you all for your contributions! The old forum is still available in read-only mode.

The Review Queues
  • Most nominations for full review are taking less than 10 weeks to review.
  • 272 nominations in the queue awaiting review.
  • Most updates are being reviewed within 8 weeks.
  • 159 updates in the queue awaiting review.
  • Most preliminary reviews are being reviewed within 10 weeks.
  • 295 preliminary review submissions in the queue awaiting review.

A number of factors have lead to the current state of the queues: increased submissions, decreased volunteer reviewer participation, and a Mozilla-wide event that took most of our attention last week. We’re back and our main focus are the review queues. We have a new reviewer on our team, who will hopefully make a difference in the state of the queues.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 40 Compatibility

The Firefox 40 compatibility blog post is up. The automatic compatibility validation will be run in a few weeks.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition (formerly known as Aurora) to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Extension Signing

We announced that we will require extensions to be signed in order for them to continue to work in release and beta versions of Firefox. The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions.

There’s a small change to the timeline: Firefox 40 will only warn about unsigned extensions (for all channels), Firefox 41 will disable unsigned extensions  by default unless a preference is toggled (on Beta and Release), and Firefox 42 will not have the preference. This means that we’ll have an extra release cycle before signatures are enforced by default.


Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. In a nutshell, Firefox will run on multiple processes now, running content code in a different process than browser code. This should improve responsiveness and overall stability, but it also means many add-ons will need to be updated to support this.

We will be talking more about these changes in this blog in the future. For now we recommend you start looking at the available documentation.

Categorieën: Mozilla-nl planet

Christian Heilmann: Over the Edge: Web Components are an endangered species

Mozilla planet - wo, 01/07/2015 - 22:00

Last week I ran the panel and the web components/modules breakout session of the excellent Edge Conference in London, England and I think I did quite a terrible job. The reason was that the topic is too large and too fragmented and broken to be taken on as a bundle.

If you want to see the mess that is the standardisation effort around web components right now in all its ugliness, Wilson Page wrote a great post on that on Mozilla Hacks. Make sure to also read the comments – lots of good stuff there.

Web Components are a great idea. Modules are a great idea. Together, they bring us hours and hours of fun debating where what should be done to create a well-performing, easy to maintain and all around extensible complex app for the web. Along the way we can throw around lots of tools and ideas like NPM and ES6 imports or – as Alex Russell said it on the panel: “tooling will save you”.

It does. But that was always the case. When browsers didn’t support CSS, we had Dreamweaver to create horribly nested tables that achieved the same effect. There is always a way to make browsers do what we want them to do. In the past, we did a lot of convoluted things client-side with libraries. With the advent of node and others we now have even more environments to innovate and release “not for production ready” impressive and clever solutions.

When it comes to componentising the web, the rabbit hole is deep and also a maze. Many developers don’t have time to even start digging and use libraries like Polymer or React instead and call it a day and that the “de facto standard” (a term that makes my toenails crawl up – layout tables were a “de facto standard”, so was Flash video).

React did a genius thing: by virtualising the DOM, it avoided a lot of the problems with browsers. But it also means that you forfeit all the good things the DOM gives you in terms of accessibility and semantics/declarative code. It simply is easier to write a <super-button> than to create a fragment for it or write it in JavaScript.

Of course, either are easy for us clever and amazing developers, but the fact is that the web is not for developers. It is a publishing platform, and we are moving away from that concept at a ridiculous pace.

And whilst React gives us all the goodness of Web Components now, it is also a library by a commercial company. That it is open source, doesn’t make much of a difference. YUI showed that a truckload of innovation can go into “maintenance mode” very quickly when a company’s direction changes. I have high hopes for React, but I am also worried about dependencies on a single company.

Let’s rewind and talk about Web Components

Let’s do away with modules and imports for now, as I think this is a totally different discussion.

I always loved the idea of Web Components – allowing me to write widgets in the browser that work with it rather than against it is an incredible idea. Years of widget frameworks trying to get the correct performance out of a browser whilst empowering maintainers would come to a fruitful climax. Yes, please, give me a way to write my own controls, inherit from existing ones and share my independent components with other developers.

However, in four years, we haven’t got much to show.. When we asked the very captive and elite audience of EdgeConf about Web Components, nobody raised their hand that they are using them in real products. People either used React or Polymer as there is still no way to use Web Components in production otherwise. When we tried to find examples in the wild, the meager harvest was GitHub’s time element. I do hope that this was not all we wrote and many a company is ready to go with Web Components. But most discussions I had ended up the same way: people are interested, tried them out once and had to bail out because of lack of browser support.

Web Components are a chicken and egg problem where we are currently trying to define the chicken and have many a different idea what an egg could be. Meanwhile, people go to chicken-meat based fast food places to get quick results. And others increasingly mention that we should hide the chicken and just give people the eggs leaving the chicken farming to those who also know how to build a hen-house. OK, I might have taken that metaphor a bit far.

We all agreed that XHTML2 sucked, was overly complicated, and defined without the input of web developers. I get the weird feeling that Web Components and modules are going in the same direction.

In 2012 I wrote a longer post as an immediate response to Google’s big announcement of the foundation of the web platform following Alex Russell’s presentation at Fronteers 11 showing off what Web Components could do. In it I kind of lamented the lack of clean web code and the focus on developer convenience over clarity. Last year, I listed a few dangers of web components. Today, I am not too proud to admit that I lost sight of what is going on. And I am not alone. As Wilson’s post on Mozilla Hacks shows, the current state is messy to say the least.

We need to enable web developers to use “vanilla” web components

What we need is a base to start from. In the browser and in a browser that users have and doesn’t ask them to turn on a flag. Without that, Web Components are doomed to become a “too complex” standard that nobody implements but instead relies on libraries.

During the breakout session, one of the interesting proposals was to turn Bootstrap components into web components and start with that. Tread the cowpath of what people use and make it available to see how it performs.

Of course, this is a big gamble and it means consensus across browser makers. But we had that with HTML5. Maybe there is a chance for harmony amongst competitors for the sake of an extensible and modularised web that is not dependent on ES6 availability across browsers. We’re probably better off with implementing one sci-fi idea at a time.

I wished I could be more excited or positive about this. But it left me with a sour taste in my mouth to see that EdgeConf, that hot-house of web innovation and think-tank of many very intelligent people were as confused as I was.

I’d love to see a “let’s turn it on and see what happens” instead of “but, wait, this could happen”. Of course, it isn’t that simple – and the Mozilla Hacks post explains this well – but a boy can dream, right? Remember when using HTML5 video was just a dream?

Categorieën: Mozilla-nl planet

David Burns: Who wants to be an alpha tester for Marionette?

Mozilla planet - wo, 01/07/2015 - 21:57

Are you an early adopter type? Are you an avid user of WebDriver and want to use the latest and great technology? Then you are most definitely in luck.

Marionette, the Mozilla implementation of the FirefoxDriver, is ready for a very limited outing. There is a lot of things that have not been implemented or, since we are implementing things agains the WebDriver Specification they might not have enough prose to implement (This has been a great way to iron out spec bugs).

Getting Started

At the moment, since things are still being developed and we are trying to do things with new technologies (like writing part this project using Rust) we are starting out with supporting Linux and OS X first. Windows support will be coming in the future!

Getting the driver We have binaries that you can download. For Linux and for OS X . The only bindings currently updated to work are the python bindings that are available in a branch on my fork of the Selenium project. Do the following to get it into a virtualenv:
  1. Create a virtualenv
  2. activate your virtualenv
  3. cd to where you have cloned my repository
  4. In a terminal type the following: ./go py_install
Running tests

Running tests against marionette requires that you do the following changes (which hopefully remains small)

Update the desired capability to have marionette:true and add binary:/path/to/Firefox/DeveloperEdition/or/Nightly. We are only supporting those two versions of at the moment because we have had a couple in compatible issues that we have fixed which means speaking to Marionette in the browser in the beta or release versions quite difficult.

Since you are awesome early adopters it would be great if we could raise bugs. I am not expecting everything to work but below is a quick list that I know doesn't work.

  • No support for self-signed certificates
  • No support for actions
  • No support for Proxy (but will be there soon)
  • No support logging endpoint
  • I am sure there are other things we don't remember

Thanks for being an early adopter and thanks for raising bugs as you find them!

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Ditching ElasticUtils on Input for elasticsearch-dsl-py

Mozilla planet - wo, 01/07/2015 - 20:20
What was it?

ElasticUtils was a Python library for building and executing Elasticsearch searches. I picked up maintenance after the original authors moved on with their lives, did a lot of work, released many versions and eventually ended the project in January 2015.

Why end it? A bunch of reasons.

It started at PyCon 2014, when I had a long talk with Rob, Jannis, and Erik about ElasticUtils the new library Honza was working on which became elasticsearch-dsl-py.

At the time, I knew that ElasticUtils had a bunch of architectural decisions that turned out to be make life really hard. Doing some things was hard. It was built for a pre-1.0 Elasticsearch and it would have been a monumental effort to upgrade it past the Elasticsearch 1.0 hump. The code wasn't structured particularly well. I was tired of working on it.

Honza's library had a lot of promise and did the sorts of things that ElasticUtils should have done and did them better--even at that ridiculously early stage of development.

By the end of PyCon 2014, I was pretty sure elasticsearch-dsl-py was the future. The only question was whether to gut ElasticUtils and make it a small shim on top of elasticsearch-dsl-py or end it.

In January 2015, I decided to just end it because I didn't see a compelling reason to keep it around or rewrite it into something on top of elasticsearch-dsl-py. Thus I ended it.

Now to migrate to something different.

Read more… (7 mins to read)

Categorieën: Mozilla-nl planet

Hannah Kane: Whistler Wrap-up

Mozilla planet - wo, 01/07/2015 - 19:03

What an amazing week!

Last week members of the Mozilla community met in beautiful Whistler, BC to celebrate, reflect, brainstorm, and plan (and eat snacks). While much of the week was spent in functional teams (that is, designers with designers and engineers with engineers), the Mozilla Learning Network website (known informally as “Teach”) team was able to convene for two meetings—one focused on our process, and the other on our roadmap and plans for the future.


From my perspective, the week inspired a few significant breakthroughs:

  1. The Mozilla Learning Network is one, unified team with several offerings. Those offerings can be summarized in this image: Networks, Groups, and Convenings.MLN ProgramsThe breakthrough was realizing that it’s urgent that the site reflects the full spectrum of offerings as soon as possible. We’ve adjusted our roadmap accordingly. First up: incorporate the Hive content in a way that makes sense to our audience, and provides clear pathways for engagement.
  2. Our Clubs pipeline is a bit off-balance. We have more interested Club Captains than our current (amazing) Regional Coordinators can support. This inspired an important conversation about changes to our strategy to better test out our model. We’ll be talking about how these changes are reflected on the site soon.
  3. The most important content to localize is our curriculum content. To be fair, we knew this before the work week, but it was definitely crystallized in Whistler. This gives useful shape to our localization plan.
  4. We also identified a few areas where we can begin the process of telling the full “Mozilla Learning” story. By that I mean the work that goes beyond what we call the Mozilla Learning Network—for example, we can highlight our Fellowship programs, curriculum from other teams (starting with Mozilla Science Lab!), and additional peer learning opportunities.
  5. Finally, we identified a few useful, targeted performance indicators that will help us gauge our success: 1) the # of curriculum hits, and 2) the % of site visitors who take the pledge to teach.
Site Updates

I also want to share a few site updates that have happened since I wrote last:

    • The flow for Clubs has been adjusted to reflect the “apply, connect, approve” model described in an earlier post.
    • We’ve added a Protect Your Data curriculum module with six great activities.
    • We added the “Pledge to Teach” action on the homepage. Visitors to the site can choose to take the pledge, and are then notified about an optional survey they can take. We’ll follow up with tailored offerings based on their survey responses.pledge

Questions? Ideas? Share ’em in the comments!

Categorieën: Mozilla-nl planet

Onderzoeker omzeilt Firefox NoScript via Google cloud -

Nieuws verzameld via Google - wo, 01/07/2015 - 18:44

Onderzoeker omzeilt Firefox NoScript via Google cloud
Een aantal domeinen staan standaard al op de whitelist van NoScript, zoals die van Mozilla, YouTube, Google en Yahoo. Het gaat hierbij niet alleen om de domeinen, maar ook de subdomeinen die onder het domein vallen. Naast worden ook ...

Google Nieuws
Categorieën: Mozilla-nl planet

Gervase Markham: Top 50 DOS Problems Solved: Squashing Files

Mozilla planet - wo, 01/07/2015 - 17:53

Q: I post files containing DTP pages and graphics on floppy disks to a bureau for printing. Recently I produced a file that was too big to fit on the disk and I know that I will be producing more in the future. What’s the best way round the problem?

A. There are a number of solutions, most of them expensive. For example, both you and the bureau could buy modems. A modem is a device that allows computers to be connected via a phone line. You would need software, known as a comms program, to go with the modems. This will allow direct PC-to-PC transfer of files without the need for floppy disks. Since your files are so large, you would need a fast 9600 baud modem [Ed: approx 1 kilobyte per second] with MNP5 compression/error correction to make this a viable option.

In this case, however, I would get hold of a utility program called LHA which is widely available from the shareware/PD libraries that advertise in PC Answers. In earlier incarnations it was known as LHarc. LHA enables you to squash files into less space than they occupied before.

The degree of compression depends on the nature of the file. Graphics and text work best, so for you this is a likely solution. The bureau will need a copy of LHA to un-squash the files before it can use them, or you can use LHA in a special way that makes the compressed files self-unpacking.

LHA has a great advantage over rival utilities in that the author allows you to use it for free. There is no registration fee, as with the similar shareware program PKZip, for example.

Every time they brought out a new, larger hard disk, they used to predict the end of the need for compression…

Categorieën: Mozilla-nl planet

Botond Ballo: C++ Concepts TS could be voted for publication on July 20

Mozilla planet - wo, 01/07/2015 - 16:00

In my report on the C++ standards meeting this May, I described the status of the Concepts TS as of the end of the meeting:

  • The committee’s Core Working Group (CWG) was working on addressing comments received from national standards bodies.
  • CWG planned to hold a post-meeting teleconference to complete the final wording including the resolutions of the comments.
  • The committee would then have the option of holding a committee-wide teleconference to vote the final wording for publication, or else delay this vote until the next face-to-face meeting in October.

I’m excited to report that the CWG telecon has taken place, final wording has been produced, and the committee-wide telecon to approve the final wording has been scheduled for July 20.

If this vote goes through, the final wording of the Concepts TS will be sent to ISO for publication, and the TS will be officially published within a few months!

Categorieën: Mozilla-nl planet

Mozilla delays Firefox 39 update over stability issue - Product Reviews

Nieuws verzameld via Google - wo, 01/07/2015 - 11:27

Product Reviews

Mozilla delays Firefox 39 update over stability issue
Product Reviews
Firefox 39 was finally meant to go out of beta, as its public release was due to be released yesterday for Android, Linux, Mac and Windows. However, Mozilla had to delay the Firefox 39 download because of a stability issue that plagued the browser at ...
Firefox 39 arrives with Hello link sharing, smoother animation and scrolling ...VentureBeat
Firefox 39 beta lets users link Hello to social accountsThe Next Web

alle 4 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Nicholas Nethercote: Firefox 41 will use less memory when running AdBlock Plus

Mozilla planet - wo, 01/07/2015 - 02:59

Last year I wrote about AdBlock Plus’s effect on Firefox’s memory usage. The most important part was the following.

First, there’s a constant overhead just from enabling ABP of something like 60–70 MiB. […] This appears to be mostly due to additional JavaScript memory usage, though there’s also some due to extra layout memory.

Second, there’s an overhead of about 4 MiB per iframe, which is mostly due to ABP injecting a giant stylesheet into every iframe. Many pages have multiple iframes, so this can add up quickly. For example, if I load TechCrunch and roll over the social buttons on every story […], without ABP, Firefox uses about 194 MiB of physical memory. With ABP, that number more than doubles, to 417 MiB.

An even more extreme example is this page, which contains over 400 iframes. Without ABP, Firefox uses about 370 MiB. With ABP, that number jumps to 1960 MiB.

(This description was imprecise; the overhead is actually per document, which includes both top-level documents in a tab and documents in iframes.)

Last week Mozilla developer Cameron McCormack landed patches to fix bug 77999, which was filed more than 14 years ago. These patches enable sharing of CSS-related data — more specifically, they add data structures that share the results of cascading user agent style sheets — and in doing so they entirely fix the second issue, which is the more important of the two.

For example, on the above-mentioned “extreme example” (a.k.a. the Vim Color Scheme Test) memory usage dropped by 3.62 MiB per document. There are 429 documents on that page, which is a total reduction of about 1,550 MiB, reducing memory usage for that page down to about 450 MiB, which is not that much more than when AdBlock Plus is absent. (All these measurements are on a 64-bit build.)

I also did measurements on various other sites and confirmed the consistent saving of ~3.6 MiB per document when AdBlock Plus is enabled. The number of documents varies widely from page to page, so the exact effect depends greatly on workload. (I wanted to test TechCrunch again, but its front page has been significantly changed so it no longer triggers such high memory usage.) For example, for one of my measurements I tried opening the front page and four articles from each of, and, for a total of 15 tabs. With Cameron’s patches applied Firefox with AdBlock Plus used about 90 MiB less physical memory, which is a reduction of over 10%.

Even when AdBlock Plus is not enabled this change has a moderate benefit. For example, in the Vim Color Scheme Test the memory usage for each document dropped by 0.09 MiB, reducing memory usage by about 40 MiB.

If you want to test this change out yourself, you’ll need a Nightly build of Firefox and a development build of AdBlock Plus. (Older versions of AdBlock Plus don’t work with Nightly due to a recent regression related to JavaScript parsing). In Firefox’s about:memory page you’ll see the reduction in the “style-sets” measurements. You’ll also see a new entry under “layout/rule-processor-cache”, which is the measurement of the newly shared data; it’s usually just a few MiB.

This improvement is on track to make it into Firefox 41, which is scheduled for release on September 22, 2015. For users on other release channels, Firefox 41 Beta is scheduled for release on August 11, and Firefox 41 Developer Edition is scheduled to be released in the next day or two.

Categorieën: Mozilla-nl planet

Mark Banner: Firefox Hello Desktop: Behind the Scenes – UI Showcase

Mozilla planet - wo, 01/07/2015 - 00:32

This is the third of some posts I’m writing about how we implement and work on the desktop and standalone parts of Firefox Hello. You can find the previous posts here.

The Showcase

One of the most useful parts of development for Firefox Hello is the User Interface (UI) showcase. Since all of the user interface for Hello is written in html and JavaScript, and is displayed in the content scope, we are able to display them within a “normal” web page with very little adjustment.

So what we do is to put almost all our views onto a single html page at representative sizes. The screen-shot below shows just one view from the page, but those buttons at the top give easy access, and in reality there’s lots of them (about 55 at the time of writing).

UI Showcase showing a standalone (link-clicker) view

UI Showcase showing a standalone (link-clicker) view

Faster Development

The showcase has various advantages that help us develop faster:

  • Since it is a web page, we have all the developer tools available to us – inspector, css layout etc.
  • We don’t have to restart Firefox to pick up changes to the layout, nor do we have to recompile – a simple reload of the page is enough to pick up changes.
  • We also don’t have to go through the flow each time, e.g. if we’re changing some of the views which show the media (like the one above), we avoid needing to go through the conversation setup routines for each code/css change until we’re pretty sure its going to work the way we expect.
  • Almost all the views are shown – if the css is broken for one view its much easier to detect it than having to go through the user flow to get to the view you want.
  • We’ve recently added an RTL mode so that we can easily see what the views look like in RTL languages. Hence no awkward forcing of Firefox into RTL mode to check the views.

There’s one other “feature” of the showcase as we’ve got it today – we don’t pick up the translated strings, but rather the raw string label. This tends to give us longer strings than are used normally for English, which it turns out is an excellent way of being able to detect some of the potential issues for locales which need longer strings.

Structure of the showcase

The showcase is a series of iframes. We load individual react components into each iframe, sometimes loading the same component multiple times with different parameters or stores to get the different views. The rest of the page is basically just structure around display of the views.

The iframes does have some downsides – you can’t live edit css in the inspector and have it applied across all the views, but that’s minor compared to the advantages we get from this one page.

Future improvements

We’re always looking for ways we can improve how we work on Hello. We’ve recently improved the UI showcase quite a bit, so I don’t think we have too much on our outstanding list at the moment.

The only thing I’ve just remembered is that we’ve commented it would be nice to have some sort of screen-shot comparison, so that we can make changes and automatically check for side-effects on other views.

We’d also certainly be interested in hearing about similar tools which could do a similar job – sharing and re-using code is definitely a win for everyone involved.

Interested in learning more?

If you’re interested in learning more about the UI-showcase, then you can find the code here, try it out for yourself, or come and ask us questions in #loop on irc.

If you want to help out with Hello development, then take a look at our wiki pages, our mentored bugs or just come and talk to us.

Categorieën: Mozilla-nl planet

Roberto A. Vitillo: Spark best practices

Mozilla planet - di, 30/06/2015 - 18:56

We have been running Spark for a while now at Mozilla and this post is a summary of things we have learned about tuning and debugging Spark jobs.

Spark execution model

Spark’s simplicity makes it all too easy to ignore its execution model and still manage to write jobs that eventually complete. With larger datasets having an understanding of what happens under the hood becomes critical to reduce run-time and avoid out of memory errors.

Let’s start by taking our good old word-count friend as starting example:

rdd = sc.textFile("input.txt")\       .flatMap(lambda line: line.split())\       .map(lambda word: (word, 1))\       .reduceByKey(lambda x, y: x + y, 3)\ .collect()

RDD operations are compiled into a Direct Acyclic Graph of RDD objects, where each RDD points to the parent it depends on:

DAGFigure 1

At shuffle boundaries, the DAG is partitioned into so-called stages that are going to be executed in order, as shown in figure 2. The shuffle is Spark’s mechanism for re-distributing data so that it’s grouped differently across partitions. This typically involves copying data across executors and machines, making the shuffle a complex and costly operation.

stagesFigure 2

To organize data for the shuffle, Spark generates sets of tasks – map tasks to organize the data and reduce tasks to aggregate it. This nomenclature comes from MapReduce and does not directly relate to Spark’s map and reduce operations. Operations within a stage are pipelined into tasks that can run in parallel, as shown in figure 3.

tasksFigure 3

Stages, tasks and shuffle writes and reads are concrete concepts that can be monitored from the Spark shell. The shell can be accessed from the driver node on port 4040, as shown in figure 4.

shellFigure 4 Best practices

Spark Shell

Running Spark jobs without the Spark Shell is like flying blind. The shell allows to monitor and inspect the execution of jobs. To access it remotely a SOCKS proxy is needed as the shell connects also to the worker nodes.

Using a proxy management tool like FoxyProxy allows to automatically filter URLs based on text patterns and to limit the proxy settings to domains that match a set of rules. The browser add-on automatically handles turning the proxy on and off when you switch between viewing websites hosted on the master node, and those on the Internet.

Assuming that you launched your Spark cluster with the EMR service on AWS, type the following command to create a proxy:

ssh -i ~/mykeypair.pem -N -D 8157

Finally, import the following configuration into FoxyProxy:

<?xml version="1.0" encoding="UTF-8"?> <foxyproxy>   <proxies>     <proxy name="emr-socks-proxy" notes="" fromSubscription="false" enabled="true" mode="manual" selectedTabIndex="2" lastresort="false" animatedIcons="true" includeInCycle="true" color="#0055E5" proxyDNS="true" noInternalIPs="false" autoconfMode="pac" clearCacheBeforeUse="false" disableCache="false" clearCookiesBeforeUse="false" rejectCookies="false">       <matches>         <match enabled="true" name="*ec2**" pattern="*ec2**" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="*ec2*.compute*" pattern="*ec2*.compute*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="10.*" pattern="http://10.*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="*10**" pattern="*10**" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="*10*.compute*" pattern="*10*.compute*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />         <match enabled="true" name="*localhost*" pattern="*localhost*" isRegEx="false" isBlackList="false" isMultiLine="false" caseSensitive="false" fromSubscription="false" />       </matches>       <manualconf host="localhost" port="8157" socksversion="5" isSocks="true" username="" password="" domain="" />     </proxy>   </proxies> </foxyproxy>

Once the proxy is enabled you can open the Spark Shell by visiting localhost:4040.

Use the right level of parallelism

Clusters will not be fully utilized unless the level of parallelism for each operation is high enough. Spark automatically sets the number of partitions of an input file according to its size and for distributed shuffles, such as groupByKey and reduceByKey, it uses the largest parent RDD’s number of partitions. You can pass the level of parallelism as a second argument to an operation. In general, 2-3 tasks per CPU core in your cluster are recommended. That said, having tasks that are too small is also not advisable as there is some overhead paid to schedule and run a task.

As a rule of thumb tasks should take at least 100 ms to execute; you can ensure that this is the case by monitoring the task execution latency from the Spark Shell. If your tasks take considerably longer than that keep increasing the level of parallelism, by say 1.5, until performance stops improving.

Reduce working set size

Sometimes, you will get terrible performance or out of memory errors, because the working set of one of your tasks, such as one of the reduce tasks in groupByKey, was too large. Spark’s shuffle operations (sortByKey, groupByKey, reduceByKey, join, etc) build a hash table within each task to perform the grouping, which can often be large.

Even though those tables spill to disk, getting to the point where the tables need to be spilled increases the memory pressure on the executor incurring the additional overhead of disk I/O and increased garbage collection. If you are using pyspark, the memory pressure will also increase the chance of Python running out of memory.

The simplest fix here is to increase the level of parallelism, so that each task’s input set is smaller.

Avoid groupByKey for associative operations

Both reduceByKey and groupByKey can be used for the same purposes but reduceByKey works much better on a large dataset. That’s because Spark knows it can combine output with a common key on each partition before shuffling the data.

In reduce tasks, key-value pairs are kept in a hash table that can spill to disk, as mentioned in “Reduce working set size“. However, the hash table flushes out the data to disk one key at a time. If a single key has more values than can fit in memory, an out of memory exception occurs. Pre-combining the keys on the mappers before the shuffle operation can drastically reduce the memory pressure and the amount of data shuffled over the network.

Avoid reduceByKey when the input and output value types are different

Consider the job of creating a set of strings for each key: p: (p[0], {p[1]}))\     .reduceByKey(lambda x, y: x | y)\     .collect()

Note how the input values are strings and the output values are sets. The map operation creates lots of temporary small objects. A better way to handle this scenario is to use aggregateByKey:

def seq_op(xs, x):     xs.add(x)     return xs def comb_op(xs, ys):     return xs | ys rdd.aggregateByKey(set(), seq_op, comb_op).collect()

Avoid the flatMap-join-groupBy pattern

When two datasets are already grouped by key and you want to join them and keep them grouped, you can just use cogroup. That avoids all the overhead associated with unpacking and repacking the groups.

Python memory overhead

The spark.executor.memory option, which determines the amount of memory to use per executor process, is JVM specific. If you are using pyspark you can’t set that option to be equal to the total amount of memory available to an executor node as the JVM might eventually use all the available memory leaving nothing behind for Python.

Use broadcast variables

Using the broadcast functionality available in SparkContext can greatly reduce the size of each serialized task, and the cost of launching a job over a cluster. If your tasks use any large object from the driver program, like a static lookup table, consider turning it into a broadcast variable.

Cache judiciously

Just because you can cache a RDD in memory doesn’t mean you should blindly do so. Depending on how many times the dataset is accessed and the amount of work involved in doing so, recomputation can be faster than the price paid by the increased memory pressure.

It should go without saying that if you only read a dataset once there is no point in caching it, i it will actually make your job slower. The size of cached datasets can be seen from the Spark Shell.

Don’t collect large RDDs

When a collect operation is issued on a RDD, the dataset is copied to the driver, i.e. the master node. A memory exception will be thrown if the dataset is too large to fit in memory; take or takeSample can be used to retrieve only a capped number of elements instead.

Minimize amount of data shuffled

A shuffle is an expensive operation since it involves disk I/O, data serialization, and network I/O. As illustrated in figure 3, each reducer in the second stage has to pull data across the network from all the mappers.

As of Spark 1.3, these files are not cleaned up from Spark’s temporary storage until Spark is stopped, which means that long-running Spark jobs may consume all available disk space. This is done in order to don’t re-compute shuffles.

Know the standard library

Avoid re-implementing existing functionality as it’s guaranteed to be slower.

Use dataframes

A DataFrame is a distributed collection of data organized into named columns. It is conceptually equivalent to a table in a relational database or a pandas Dataframe in Python.

props = get_pings_properties(pings,                              ["environment/system/os/name",                               "payload/simpleMeasurements/firstPaint",                               "payload/histograms/GC_MS"],                              only_median=True) frame = sqlContext.createDataFrame( x: Row(**x))) frame.groupBy("environment/system/os/name").count().show()


environment/system/os/name count Darwin 2368 Linux 2237 Windows_NT 105223

Before any computation on a DataFrame starts, the Catalyst optimizer compiles the operations that were used to build the DataFrame into a physical plan for execution. Since the optimizer generates JVM bytecode for execution, pyspark users will experience the same high performance as Scala users.

Categorieën: Mozilla-nl planet

Michael Kaply: The End of Firefox 31 ESR

Mozilla planet - di, 30/06/2015 - 18:03

With the release of Firefox 39 today also comes the final release of the Firefox 31 ESR (barring any security updates in the next six weeks).
That means you have six weeks to manage your switch over to the Firefox 38 ESR.

If you've been wondering if you should use the ESR instead of keeping up with current Firefox releases, now might be a good time to switch. That's because there are a couple features coming in the Firefox mainline that might affect you. These include the removal of the distribution/bundles directory as well as the requirement for all add-ons to be signed by Mozilla.

It's much easier going from Firefox 38 to the Firefox 38 ESR then going from Firefox 39 to the Firefox 38 ESR.

If you want to continue on the Firefox mainline, you can use the CCK2 to bring back some of the distribution/bundles functionality, but I won't be able to do anything about the signing requirement.

Categorieën: Mozilla-nl planet

Mark Banner: Firefox Hello Desktop: Behind the Scenes – Architecture

Mozilla planet - di, 30/06/2015 - 15:39

This is the second of some posts I’m writing about how we implement and work on the desktop and standalone parts of Firefox Hello. The first post was about our use of Flux and React, this second post is about the architecture.

In this post, I will give an overview of the Firefox browser software architecture for Hello, which includes the standalone UI.

User-visible parts of Hello

Although there’s many small parts to Hello, most of it is shaped by what is user visible:

Firefox Hello Desktop UI (aka Link-Generator)

Hello Standalone UI (aka Link-clicker)

Firefox Browser Architecture for Hello

The in-browser part of Hello is split into three main areas:

  • The panel which has the conversation and contact lists. This is a special about: page that is run in the content process with access to additional privileged APIs.
  • The conversation window where conversations are held. Within this window, similar to the panel, is another about: page that is also run in the content process.
  • The backend runs in the privileged space within gecko. This ties together the communication between the panels and conversation windows, and provides access to other gecko services and parts of the browser to which Hello integrates.
Outline of Hello's Desktop Architecture

Outline of Hello’s Desktop Architecture

MozLoopAPI is our way of exposing small bits of the privileged gecko (link) code to the about: pages running in content. We inject a navigator.mozLoop object into the content pages when they are loaded. This allows various functions and facilities to be exposed, e.g. access to a backend cache of the rooms list (which avoids multiple caches per window), and a similar backend store of contacts.

Standalone Architecture

The Standalone UI is simply a web page that’s shown in any browser when a user clicks a conversation link.

The conversation flow is in the standalone UI is very similar to that of the conversation window, so most of the stores and supporting files are shared. Most of the views for the Standalone UI are currently different to those from the desktop – there’s been a different layout, so we need to have different structures.

Outline of Hello's Standalone UI Architecture

Outline of Hello’s Standalone UI Architecture

File Architecture as applied to the code

The authoritative location for the code is mozilla-central it lives in the browser/components/loop directory. Within that we have:

  • content/ – This is all the code relating to the panel and conversation window that is shipped on in the Firefox browser
  • content/shared/ – This code is used on browser as well as on the standalone UI
  • modules/ – This is the backend code that runs in the browser
  • standalone/ – Files specific to the standalone UI

Future Work

There’s a couple of likely parts of the architecture that we’re going to rework soon.

Firstly, with the current push to electrolysis, we’re replacing the current exposed MozLoopAPI with a message-based RPC mechanism. This will then let us run the panel and conversation window in the separated content process.

Secondly, we’re currently reworking some of the UX and it is moving to be much more similar between desktop and standalone. As a result, we’re likely to be sharing more of the view code between the two.

Interested in learning more?

If you’re interested in learning more about Hello’s architecture, then feel free to dig into the code, or come and ask us questions in #loop on irc.

If you want to help out with Hello development, then take a look at our wiki pages, our mentored bugs or just come and talk to us.

Categorieën: Mozilla-nl planet