Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Mozilla shows off flexible RAM on $170 Firefox OS Flame - ZDNet

Nieuws verzameld via Google - fr, 15/08/2014 - 14:07


Mozilla shows off flexible RAM on $170 Firefox OS Flame
Most consumers probably want a smartphone with more RAM, but the highlight of Mozilla's newish Flame handset is that it lets developers dial it down when they want. flame-side Image: Mozilla. Building a mobile ecosystem in the shadow of iOS and Android ...
Mozilla Flame smartphone now shipping to developersSlashGear
Mozilla Flame FireFox OS Smartphone Now Shipping To DevelopersGeeky gadgets

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

Mozilla Flame smartphone now shipping to developers - SlashGear

Nieuws verzameld via Google - fr, 15/08/2014 - 12:27


Mozilla Flame smartphone now shipping to developers
The Mozilla Flame phone for developers, having been available for pre-order for a few months, is now shipping. Mozilla calls this latest handset "a milestone in Firefox OS device releases", saying its specs pave the way for developers to get busy ...
Mozilla Flame FireFox OS Smartphone Now Shipping To DevelopersGeeky gadgets

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

Mozilla Flame FireFox OS Smartphone Now Shipping To Developers - Geeky gadgets

Nieuws verzameld via Google - fr, 15/08/2014 - 10:37

Geeky gadgets

Mozilla Flame FireFox OS Smartphone Now Shipping To Developers
Geeky gadgets
Developers patiently waiting for the Mozilla Flame FireFox OS smartphone to start shipping, will be pleased to learn that today Mozilla has announced they have started the process of delivering their new Flame smartphone into the hands of Firefox OS ...

Categorieën: Mozilla-nl planet

Mozilla WebDev Community: Animating the Firefox Desktop Pages

Mozilla planet - fr, 15/08/2014 - 05:59

As you may have noticed, Firefox for desktop computers (Windows, Mac, and Linux) got a redesigned interface with the release of Firefox 29.0. This redesigned browser called for redesigned web pages to showcase the new interface (the tabs, icons, menus, etc., collectively called “browser chrome”) and new features (especially the new customization menu)

Naturally, the main audience for these pages are people using browsers that aren’t Firefox, so we wanted to illustrate the new Firefox design in a fun and compelling way that gives them a real sense of what it looks like, hopefully encouraging folks to download it and see it first hand. Another big target audience are Firefox users who haven’t yet updated, so we needed to give them an overview of what’s new.

This also gave us a chance to create some snazzy animations to show off some of the advances in CSS and SVG supported by the current generation of browsers, both on desktop computers and mobile devices. Here’s how we made it.

Browser Chrome Animations

In order to demonstrate features of Firefox, we needed to simulate the way interface elements respond to user actions; opening and closing tabs, rearranging icons, adding a bookmark, and so on. This called for fairly complicated animation sequences that had to be quick and buttery smooth. The complex interplay of multiple elements moving both sequentially and in tandem really drove home the need for a CSS animation editor (vote it up!).

Approach & structure

Each animation illustrating the browser chrome (One, Two, Three) is wrapped in a div element with a common class applied (animation-wrapper), along with an id we can use to target the specific element with JavaScript.

The first element inside the animation wrapper is a composite fallback image for browsers that don’t support CSS animations. This image has a common classname (fallback) for easy CSS targeting. We can conditionally hide this image by leveraging the cssanimations class Modernizr applies to the body. By first assuming that animation is not supported, we ensure a functional degradation for even the oldest and least capable browsers, and we can progressively enhance the page for more advanced browsers that support the more advanced features.

The next element inside the wrapper div is the stage for the entire animation – <div class="stage">, really just an invisible box in which other elements can move around. Using the same cssanimations class from Modernizr, we’ll display the stage for browsers that can handle the animation.

/* for legacy browsers */ .fallback { display: block; }   .stage { display: none; }   /* for modern browsers */ .cssanimations { .fallback { display: none; }   .stage { display: block; } }

(We use Less to preprocess our CSS, so those nested rules are converted into separate rules with descendant selectors.)

The final task is to trigger the animations only when they come into view, as there’s no sense running an animation while it’s off screen. We used jQuery Waypoints to monitor the page’s scroll position, adding an animate class to each wrapper div when it comes into view. The addition of that class sets off the CSS animation sequence.

.animating-element { position: absolute; top: 10px; right: 40px; }   /* animate class added via JavaScript/Waypoints based on scroll position */ .animate { .animating-element { animation: moveAround 0.7s ease 0s 1 normal forwards; } }

This approach worked well and helped us keep each animation block self-contained and modular. It provided a common and easily customizable HTML & CSS structure for each animation, and less capable browsers still have access to all the content in a well styled page. Within that stage box we can add any other content or elements we need.

Timing is everything

The browser chrome animations have multiple elements with multiple animations applied, so getting the timing just right became rather tedious. Because separate animations are completely independent in CSS, there’s no simple way to tell a browser to “start animationY 2.1 seconds after animationX completes.” Instead, you need to do the calculations yourself and hard code them into each animation declared in the CSS, liberally using animation-duration and animation-delay to fire off each step of the scene in sequence. The mental gymnastics go something like this:

Step 1 has a 0.7 second delay and runs for 1.5 seconds. Then Step 2 should start 1.4 seconds after Step 1 completes, so it should have a delay of… 3.6 seconds. Step 2 runs for 2 seconds, and Step 3 needs to begin a quarter of a second before Step 2 completes, so Step 3 needs a delay of 5.35 seconds…

As you can imagine, the more elements you animate and the more steps you have in the sequence, the harder the math becomes. Adjusting the timing of one step in the chain can mean adjusting all the subsequent steps to compensate.

Designer Ty Flanagan created video mockups in Adobe After Effects to serve as a guide for the CSS animation, which was an enormous help. There was still a fair amount of fine tuning to be done by hand, constantly refreshing the page and tweaking a few milliseconds until it just “felt right,” but that process could have taken much longer without the videos for reference.

Another way to do all of this would have been controlling the chained animations in JavaScript, relying on the animationend event to fire off the next step in the sequence. However, a bunch of event listeners and setTimeout calls in a script probably wouldn’t have been a faster or better approach.

Animations in a Circle

Some of our favorite animations are the customize icons, mostly because the circular mask effect is so neat in its simplicity.

The key to achieving the circular mask is a bit of absolute positioning and the incredibly versatile border-radius. The markup isn’t too complex – a stage to contain everything, a div for the circular mask, and whatever elements need to be animated.

<div class="stage"> <div class="circle-mask"></div> <div class="animated" id="animated-block1"></div> <div class="animated" id="animated-block2"></div> </div>

If you’d like to see an example and play around with the code before reading about the methodology, here’s a little demo on CodePen.

The stage

The stage has a set height and width with a hidden overflow and relative positioning. The background color of the stage fills the circular mask.

.stage { position: relative; width: 300px; height: 180px; overflow: hidden; background: #fff; } The circular mask

The circular mask is absolutely positioned at the center of the stage, calculated by (stage width - (mask width + mask border width))/2 (this equation could be simpler with box-sizing: border-box). The mask has a wide enough border to reach just past the furthest boundary of the stage. The border bumping up against the page background is what completes the illusion of the mask, so the mask’s border color matches that of the section’s background color (sadly, this means the technique only works with a solid colored background).

To make sure the mask covers the animated elements, it has a z-index at least one higher than the front-most animated element.

.circular-mask { position: absolute; width: 164px; height: 164px; border: 100px solid #ccc; border-radius: 50%; top: -100px; left: -32px; z-index: 2; }   /* animated elements share absolute positioning and a z-index lower than .circular-mask */ .animated { position: absolute; z-index: 1; } The animated elements

The only requirement for the animated elements is that they reside inside the stage and have a z-index lower than the mask. Otherwise, anything goes.

Though purely flair (as opposed to the feature demonstrations provided by the browser chrome animations), these circular animations were fun to build and we’re very pleased with the result.

Drawing Firefox in the browser

When we first watched a video mockup of the proposed intro animation for the new Firefox for Desktop landing page, we wondered if this was actually possible to pull off in a web browser. The animation involves a series of moving lines which fill in as the outlines fade onto the web page, creating an illustrated image of the Firefox browser. Definitely not a typical animation you see on the web every day!

The first step on the path of discovery was to choose an appropriate image format. SVG seemed like the most obvious choice, given that the images needed to scale. Nobody on the team had any prior experience with SVG animation but it seemed like a fun challenge! Ty came up with a rough demo showing how we might use SVG path strokes for the moving lines, which seemed like a perfect starting point. We could have chosen to use an SVG animation library such Raphael or SnapSVG, but we wanted to try to keep our dependencies as light as possible (we had plenty already; no reason to add any more if we can avoid it). The timing and intricacies of the animation made a strong case for trying to use CSS keyframe animations, and this would also be a good opportunity to show off their potential. It was then we recalled this really clever technique that could pull off the same line-drawn effect using CSS.

Animating SVG line paths using CSS

The trick to the line drawing effect is to animate the stroke-dashoffset of an SVG image path. The stroke-dasharray property allows you to apply a dashed border effect to the outline of an SVG image. The clever part is that if you set the length of the dash equal to the total length of the image path, you can then animate stroke-dashoffset to make it appear as if the line is being drawn one segment at a time. Magic!

Here’s an example of an SVG path:

<path class="circle" stroke="#5d7489" stroke-width="2" stroke-opacity="1" fill="#5d7489" fill-opacity="0" d="M33.665530413296274,58.589001490321166C43.94406883919239,58.59306994020939,52.274,66.92651000976564,52.274,77.205C52.274,87.486,43.939,95.821,33.658,95.821C23.377000000000002,95.821,15.042000000000002,87.48599999999999,15.042000000000002,77.205C15.041,66.923,23.376,58.589,33.658,58.589"> </path>

And some CSS to animate it:

.circle { stroke-dasharray: 117; stroke-dashoffset: 117; animation: draw-circle 5s linear forwards; }   @keyframes draw-circle { 100% { stroke-dashoffset: 0; } }

You can find the required length of a path pretty easily using a bit of JavaScript:

var circle = document.querySelector('.circle'); var length = circle.getTotalLength();

The animation on the finished page is quite a bit more complicated than this example, but hopefully you can get the idea. We also animated fill-opacity and stroke-opacity to color in the browser panels and fade out the lines at the end of the animation, leaving a scalable vector drawing of the new Firefox.

Scaling SVG using CSS transforms

As well as animating the line drawing, we also needed to scale the image as it zooms onto the page. From there, the icons also zoom into their appropriate places. This was all done using regular CSS transforms via translate and scale.

There are some notable cross-browser inconsistencies here when it comes to scaling SVG using this method. Both Chrome and Safari render a bitmap of an SVG prior to performing a CSS transform. This is presumably for performance reasons, but it does lead to blurry images when you blow them up. Firefox seems to weigh up performance and image quality a little differently, and renders sharper images when they scale. To get around the resizing issues, the best solution was to render icons at their largest size initially and then scale them down, as opposed to the other way around. It seems browsers still have some work to do in this area in order to improve SVG rendering under these circumstances.

Putting it all together

Combining all the separate CSS keyframe animations together was probably the most time consuming task. We can also look forward to the day when we no longer need vendor prefixes for CSS keyframe animations, as the duplication of code required is still a bit undesirable. Aside from this, getting the timing right was once again the trickiest part. For a less-than-5-second animation, having to reload and run through the whole sequence over and over made the process pretty time consuming (here’s another vote for that CSS animation editor).

The final result of all this work is a set of pages that beautifully show off what the new desktop Firefox looks like while also showing off what it can do with open web technologies. If you haven’t yet, please do check it out. It’s all responsive, mobile-friendly, progressively enhanced, retina-ready, and still pretty light weight all things considered. And without a single byte of Flash.

The team
  • Jon Petto – Developer
  • Alex Gibson – Developer
  • Holly Habstritt Gaal – UX Designer
  • Ty Flanagan – Graphic Designer
  • Matej Novak – Copywriter
  • Jennifer Bertsch – Product Manager
  • Mike Alexis – Program Manager

This article was co-written by Jon Petto and Alex Gibson, with editorial assistance from Craig Cook.

Categorieën: Mozilla-nl planet

Nicholas Nethercote: The story of a tricky bug

Mozilla planet - fr, 15/08/2014 - 04:02
The Bug Report

A few weeks ago I skimmed through /r/firefox and saw a post by a user named DeeDee_Z complaining about high memory usage in Firefox. Somebody helpfully suggested that DeeDee_Z look at about:memory, which revealed thousands of blank windows like this:

│ │ ├────0.15 MB (00.01%) ++ top(about:blank, id=1001) │ │ ├────0.15 MB (00.01%) ++ top(about:blank, id=1003) │ │ ├────0.15 MB (00.01%) ++ top(about:blank, id=1005

I filed bug 1041808 and asked DeeDee_Z to sign up to Bugzilla so s/he could join the discussion. What followed was several weeks of back and forth, involving suggestions from no fewer than seven Mozilla employees. DeeDee_Z patiently tried numerous diagnostic steps, such as running in safe mode, pasting info from about:support, getting GC/CC logs, and doing a malware scan. (Though s/he did draw the line at running wireshark to detect if any unusual network activity was happening, which I think is fair enough!)

But still there was no progress. Nobody else was able to reproduce the problem, and even DeeDee_Z had trouble making it happen reliably.

And then on August 12, more than three weeks after the bug report was filed, Peter Van der Beken commented that he had seen similar behaviour on his machine, and by adding some logging to Firefox’s guts he had a strong suspicion that it was related to having the “keep until” setting for cookies set to “ask me every time”. DeeDee_Z had the same setting, and quickly confirmed that changing it fixed the problem. Hooray!

I don’t know how Peter found the bug report — maybe he went to file a new bug report about this problem and Bugzilla’s duplicate detection identified the existing bug report — but it’s great that he did. Two days later he landed a simple patch to fix the problem. In Peter’s words:

The patch makes the dialog for allowing/denying cookies actually show up when a cookie is set through the DOM API. Without the patch the dialog is created, but never shown and so it sticks around forever.

This fix is on track to ship in Firefox 34, which is due to be released in late November.

Takeaway lessons

There are a number of takeaway lessons from this story.

First, a determined bug reporter is enormously helpful. I often see vague complaints about Firefox on websites (or even in Bugzilla) with no responses to follow-up questions. In contrast, DeeDee_Z’s initial complaint was reasonably detailed. More importantly, s/he did all the follow-up steps that people asked her/him to do, both on Reddit and in Bugzilla. The about:memory data made it clear it was some kind of window leak, and although the follow-up diagnostic steps didn’t lead to the fix in this case, they did help rule out a number of possibilities. Also, DeeDee_Z was extremely quick to confirm that Peter’s suggestion about the cookie setting fixed the problem, which was very helpful.

Second, many (most?) problems don’t affect everyone. This was quite a nasty problem, but the “ask me every time” setting is not commonly used because causes lots of dialogs to pop up, which few users have the patience to deal with. It’s very common that people have a problem with Firefox (or any other piece of software), incorrectly assume that it affects everyone else equally, and conclude with “I can’t believe anybody uses this thing”. I call this “your experience is not universal“. This is particular true for web browsers, which unfortunately are enormously complicated and have many combinations of settings get little or no testing.

Third, and relatedly, it’s difficult to fix problems that you can’t reproduce. It’s only because Peter could reproduce the problem that he was able to do the logging that led him to the solution.

Fourth, it’s important to file bug reports in Bugzilla. Bugzilla is effectively the Mozilla project’s memory, and it’s monitored by many contributors. The visibility of a bug report in Bugzilla is vastly higher than a random complaint on some other website. If the bug report hadn’t been in Bugzilla, Peter wouldn’t have stumbled across it. So even if he had fixed it, DeeDee_Z wouldn’t have known and probably would have had been stuck with the problem until Firefox 34 came out. That’s assuming s/he didn’t switch to a different browser in the meantime.

Fifth, Mozilla does care about memory usage, particularly cases where memory usage balloons unreasonably. We’ve had a project called MemShrink running for more than three years now. We’ve fixed hundreds of problems, big and small, and continue to do so. Please use about:memory to start the diagnosis, and add the “[MemShrink]” tag to any bug reports in Bugzilla that relate to memory usage, and we will triage them in our fortnightly MemShrink meetings.

Finally, luck plays a part. I don’t often look at /r/firefox, and I could have easily missed DeeDee_Z’s complaint. Also, it was lucky that Peter found the bug in Bugzilla. Many tricky bugs don’t get resolved this quickly.

Categorieën: Mozilla-nl planet

William Lachance: A new meditation app

Mozilla planet - fr, 15/08/2014 - 04:02

I had some time on my hands two weekends ago and was feeling a bit of an itch to build something, so I decided to do a project I’ve had in the back of my head for a while: a meditation timer.

If you’ve been following this log, you’d know that meditation has been a pretty major interest of mine for the past year. The foundation of my practice is a daily round of seated meditation at home, where I have been attempting to follow the breath and generally try to connect with the world for a set period every day (usually varying between 10 and 30 minutes, depending on how much of a rush I’m in).

Clock watching is rather distracting while sitting so having a tool to notify you when a certain amount of time has elapsed is quite useful. Writing a smartphone app to do this is an obvious idea, and indeed approximately a zillion of these things have been written for Android and iOS. Unfortunately, most are not very good. Really, I just want something that does this:

  1. Select a meditation length (somewhere between 10 and 40 minutes).
  2. Sound a bell after a short preparation to demarcate the beginning of meditation.
  3. While the meditation period is ongoing, do a countdown of the time remaining (not strictly required, but useful for peace of mind in case you’re wondering whether you’ve really only sat for 25 minutes).
  4. Sound a bell when the meditation ends.

Yes, meditation can get more complex than that. In Zen practice, for example, sometimes you have several periods of varying length, broken up with kinhin (walking meditation). However, that mostly happens in the context of a formal setting (e.g. a Zendo) where you leave your smartphone at the door. Trying to shoehorn all that into an app needlessly complicates what should be simple.

Even worse are the apps which “chart” your progress or have other gimmicks to connect you to a virtual “community” of meditators. I have to say I find that kind of stuff really turns me off. Meditation should be about connecting with reality in a more fundamental way, not charting gamified statistics or interacting online. We already have way too much of that going on elsewhere in our lives without adding even more to it.

So, you might ask why the alarm feature of most clock apps isn’t sufficient? Really, it is most of the time. A specialized app can make selecting the interval slightly more convenient and we can preselect an appropriate bell sound up front. It’s also nice to hear something to demarcate the start of a meditation session. But honestly I didn’t have much of a reason to write this other than the fact than I could. Outside of work, I’ve been in a bit of a creative rut lately and felt like I needed to build something, anything and put it out into the world (even if it’s tiny and only a very incremental improvement over what’s out there already). So here it is:


The app was written entirely in HTML5 so it should work fine on pretty much any reasonably modern device, desktop or mobile. I tested it on my Nexus 5 (Chrome, Firefox for Android)[1], FirefoxOS Flame, and on my laptop (Chrome, Firefox, Safari). It lives on a subdomain of this site or you can grab it from the Firefox Marketplace if you’re using some variant of Firefox (OS). The source, such as it is, can be found on github.

I should acknowledge taking some design inspiration from the Mind application for iOS, which has a similarly minimalistic take on things. Check that out too if you have an iPhone or iPad!

Happy meditating!

[1] Note that there isn’t a way to inhibit the screen/device from going to sleep with these browsers, which means that you might miss the ending bell. On FirefoxOS, I used the requestWakeLock API to make sure that doesn’t happen. I filed a bug to get this implemented on Firefox for Android.

Categorieën: Mozilla-nl planet

Zack Weinberg: I Will File Bugs For You

Mozilla planet - to, 14/08/2014 - 23:05

This post prompted by Aaron Klotz’s “Diffusion of Responsibility” and Sumana Harihareswara’s “Inessential Weirdnesses in Open Source.”

One of the most common ways to start interacting with a free software project, as opposed to just using the software produced by that project, is when you trip over a bug or a missing feature and now you need to go tell the developers about it. Unfortunately, that process is often incredibly off-putting. If there’s a bug tracking system, it is probably optimized for people who spend all day every day working with it, and may appear to demand all kinds of information you have no idea how to supply. If there isn’t, you’re probably looking at signing up for some sort of mailing list (mailing list! how retro!) Either way, it may not be easy to find, and there’s a nonzero chance that some neckbeard with a bad attitude is going to yell at you. It shouldn’t be so, but it is.

So, I make this offer to you, the general public, as I have been doing for close friends for many years: if you don’t want to deal with that shit, I will file bugs for you. I’ve been on the Internet since not quite the elder days, and I’ve been hacking free software almost as long; I know how to find these people and I know how to talk to them. We’ll have a conversation and we’ll figure out exactly what’s wrong and then I’ll take it from there. I’m best at compilers and Web browsers, but I’ll give anything a shot.

THE FINE PRINT: If you want to take me up on this, please do so only via email; my address is on the Contact page. Please allow up to one week for an initial response, as this service is provided in my copious free time.

Offer valid only for free software (also known as “open source”) (as opposed to software that you are not allowed to modify or redistribute, e.g. Microsoft Word). Offer also only valid for problems which I can personally reproduce; it’s not going to go well for anyone involved if I have to play telephone with you and the developers. Offer specifically not valid for operating system kernels or device drivers of any kind, both because those people are even less pleasant to work with than the usual run of neckbeards, and because that class of bugs tends to be hardware-dependent and therefore difficult for me to personally reproduce on account of I don’t have the exact same computer as you.

The management cannot guarantee this service will cause bugs to actually get fixed in any kind of timely fashion, or, in fact, ever.

Categorieën: Mozilla-nl planet

Sean Martell: Mozilla ID Project: Wordmark exploration

Mozilla planet - to, 14/08/2014 - 22:13

This is the first in a series of live streaming work sessions exploring a refresh of the Mozilla brand ID system.

Today’s session was exploring Fira Sans for our wordmark versus the current Meta Bold. Fira Sans is an open Web font whereas Meta is a closed commercial font. In the video I explore customizing certain characters to make a unique wordmark yet basing it on our Fira font. I also start to explore how we could show data visualization in a logo mark.

More to come! To follow along with this project, feel free to subscribe to the Youtube channel and follow me on twitter.


Categorieën: Mozilla-nl planet

Aaron Klotz: Diffusion of Responsibility

Mozilla planet - to, 14/08/2014 - 22:00

Something that I’ve been noticing on numerous social media and discussion forum sites is that whenever Firefox comes up, inevitably there are comments in those threads about Firefox performance. Given my role at Mozilla, these comments are of particular interest to me.

The reaction to roc’s recent blog post has motivated me enough to respond to a specific subset of comments. These comments all exhibit a certain pattern: their authors are experiencing problems with Firefox, they are very dissatisfied, but they are not discussing them in a way that is actionable by Mozilla.

How Mozilla Finds Problems

Mozilla encourages our contributors to run prerelease versions of Firefox, especially Nightly builds. This allows us to do some good old-fashioned dogfooding during the development of a Firefox release.

We also have many tools that run as part of our continuous integration infrastructure. Valgrind, Address Sanitizer, Leak Sanitizer, reference count tracking, deadlock detection, assertions, Talos performance tests, and xperf are some of the various tools that we apply to our builds. I do not claim that this list is exhaustive! :–)

We use numerous technologies to discover problems that occur while running on our users’ computers. We have a crash reporter that (with the user’s consent) reports data about the crash. We have Firefox Health Report and Telemetry that, when consented to, send us useful information for discovering problems.

Our ability to analyze crash report/FHR/telemetry data is limited to those users who consent to share it with us. As much as I am proud of the fact that we respect the privacy of our users, this means that we only receive data from a fraction of them; many users who are experiencing problems are not included in this data.

Despite the fact that we have all of these wonderful tools to help us deliver quality releases, the fact is that they cannot exhaustively catch every possible bug that is encountered out in the wild. There are too many combinations of extensions and configurations out there to possibly allow us to catch everything before release.

That’s where you, our users, come in!

If You See Something, Report It!

Reddit, Hacker News, Slashdot and other similar sites are fantastic for ranting. I should know — I do it with the best of them! Having said that, they are also terrible for the purposes of bug reporting!

As users it’s easy for us to assume that somebody else will encounter our problems and report them. Unfortunately that is not always the case, especially with a browser that is as configurable as Firefox.

Reporting Bugs

If you are experiencing a bug, the best way to ensure that something can be done about your bug is to report it in Bugzilla. This might seem a little bit intimidating for somebody who is new to bug reporting, but I assure you, Mozillians are really nice! As long as you follow the etiquette guidelines, you’ll be fine! One suggestion though: try to follow our bug writing guidelines. Doing so will maximize the likelihood of a contributor being able to reproduce your problem. In addition to these suggestions for bug filing, I also suggest including certain types of data for specific types of problems:

Reporting a Bug for High Memory Usage

If you’re experiencing problems with Firefox’s memory use, open a tab, and point your browser to about:memory. This nifty feature provides a breakdown of Firefox memory consumption. Save that report and attach it to the bug that you’ve filed.

Reporting a Bug for Slowness

If you want report a problem with Firefox being slow, the best way to help us is is to include data that has been generated by the Gecko Profiler. Unfortunately this is tool requires a bit of technical savvy, but attaching the URL of an uploaded profile to your performance bug can be very helpful.

Reporting a Bug for a Persistent, Reproducable Crash

As you can see in our crash report data, crashes reported to Mozilla are ranked by frequency. As you might expect, this implies that it’s often the squeaky wheels that get the grease.

If you have an easily reproducable crash and you are sending your reports to Mozilla, you can help us by pointing Firefox to about:crashes. This page lists all of the crash reports that have been generated on your computer. If the crash that you are experiencing isn’t on our list of top crashers, you can still help us to fix it: filing a bug that includes multiple crash report URLs from your about:crashes screen will help tremendously.

In Conclusion

If there is one idea that you can take away from this post (a TL;DR, if you will), it is this: Mozilla cannot fix 100% of the bugs that we do not know about.

Taking an active role in the Mozilla community by reporting your issues through the proper channels is the best way to ensure that your problems can be fixed.

EDIT: To be clear: What I am suggesting is that users who are enthusiastic enough to post a comment to Hacker News (for example) should also be savvy enough to be able to file a proper bug report. Please do not misconstrue this post as a demand that novice users start filing bugs.

Categorieën: Mozilla-nl planet

Mozilla recycles 'Flame' Firefox OS smartphone launch - VentureBeat

Nieuws verzameld via Google - to, 14/08/2014 - 18:51


Mozilla recycles 'Flame' Firefox OS smartphone launch
Update 12:48 p.m. ET: The Flame device started shipping last month. We sincerely regret the error and have updated the story below. Mozilla today announced that it has begun shipping its “Flame Developer reference phone” to Firefox OS app developers, ...
The Firefox OS Flame Developer Reference Phone Starts ShippingTechCrunch

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

Matt Thompson: What would a web literate school look like?

Mozilla planet - to, 14/08/2014 - 18:42

As we think about what’s next for Webmaker, we’re conducting interviews to better understand our audience and develop user personas. What challenges do teachers in the classroom face, for example? How can we help them spread web literacy? Here’s what Phil Macoun, an educator from Nanaimo, B.C., had to tell us.

Phil: a tech-savvy educator trying to help his school
  • Phil Macoun is the Technology Coordinator at Aspengrove School in Nanaimo
  • He’s thinking about how to implement a complete digital literacy curriculum for the entire school, from grades 1 to 12
  • He recently started pursuing a Masters in Educational Leadership. “Because real change is going to happen at a higher level. Technology alone isn’t enough — the technology needs to support the pedagogy.”

Notes from Phil’s blog

What would K to 12 digital literacy look like?

Phil’s been thinking a lot about what “digital literacy” might look like from kindergarten all the way to grade 12. As his school’s Technology Coordinator, he has the opportunity to implement a school-wide curriculum, influencing an entire staff of teachers and several hundred students.

He’s been surveying the landscape. Phil has researched various digital literacy offerings and approaches, including:

He’s familiar with Webmaker tools like Thimble, and has been following Webmaker’s Web Literacy Map.

The whole maker movement thing is a big part of what I’m thinking about right now. [Mozilla's] web literacy map outlines things kids need to do, but there also need to be attitudes and approaches tied up into the learning. How to design and be creative.”

The hard part is implementation

The biggest challenge for Phil is: how to help busy, time-strapped teachers get started teaching this stuff in their own classrooms. “In terms of implementation, this is where I get stuck,” Phil says. “[Webmaker] has got good ideas — but I don’t know how to scale them up for my school.

“I can’t possibly do all this myself — I need other teachers to be responsible for implementing it. I need a framework.”

His best solution so far?

What has worked to help him solve this problem so far? The Common Sense Media “Digital Citizenship” curriculum. By sending his fellow teachers that one link, along with a bit of context and guidance, he was able to offer time-strapped colleagues something close to a turn-key solution. They loved it.

It lowers the barrier to entry. They can quickly see the grade level, learning outcomes, download a lesson plan, get worksheets. There’s everything they need to get started.”

Phil likes that Common Sense Media also just published an e-book manual for teachers, and says that many other independent schools in BC are now adopting the Common Sense curriculum.

Parents want these skills for their kids

I mostly get parents coming and saying: thank you for teaching my kids this stuff!” Phil says. “They like that I’m telling their kids how to search the Internet properly. They know that their kids are immersed in this online world, and they’re looking for help to manage it properly.”

How Phil explains digital literacy to parents

From exploring and building to connecting

Mozilla’s Web Literacy Map is based around exploring, building and connecting. Phil says that parents and colleagues intuitively grasp the value of  “Exploring” and “Building” — but less so with “Connecting,” the piece he actually thinks is the most valuable.

Trying to get people to understand that piece is much harder,” he says. “‘Exploring’ is easy — people want kids to be able to search the internet better. The ‘building’ piece is easy as well — kids programming video games, printing stuff on a 3D printer. Parents love that stuff. Its harder to explain the connecting piece.”

“You want to get from ‘Help me to manage my kids online life’ to ‘help me teach my kids to leverage this tool to its full potential.”

How could Webmaker’s curriculum offering improve?

We recently shipped a new series of pages that we think of as a “textbook for web literacy.” I invited Phil to tale a look at the “Privacy” page, from a teacher’s perspective.

As a busy teacher what I’m looking for is: what’s the stuff that’s relevant to me.
If I was a teacher who didn’t know a lot about this topic, I’m looking for: ‘What am I teaching? What are my learning outcomes? How am I going to do it?’”

I look at this page and go: I don’t have time to figure this out right now. I had to scroll right down to the very bottom of the page to know that there was stuff here for teachers.”

“If I had a teacher portal, like the Common Sense Media stuff, it could show me what the different elements of the Web Literacy thing might look like in primary school, vs middle school, vs high school, etc. When it’s all kinda jumbled up, I don’t have time to pick out the good stuff.”

Badges as a more fluid way to recognize learning

I’d love to use badges as a formative assessment tool in my classroom. A more fluid way students could celebrate their learning.  Maybe I could find a way to loop badges into what my kids are already doing with Google Docs, or Scratch, or TinkerPad. That would be really cool.”

Cloud-based collaboration

Google Apps recently became Aspengrove school’s go-to digital platform. They moved the whole school over to it. Every student from grade 8 and up now has a Google Apps email address.

“All our students are doing their writing in Google Docs now.”

In a way, Phil’s school is using Google Docs the same way Mozilla uses etherpads — for  immediate web-based collaboration.

The first thing teachers and students do is open up a Google Doc and start putting all their ideas in one document. In many cases, teachers have been writing alongside the kids, so that students can get comments from the teacher as they go. And teachers are doing most of their classroom presentations in Google Docs as well.”

Some early conclusions and analysis

I found this interview hugely insightful. I’m going to think some more about analysis, early conclusions and next steps. But in the mean time: what do you think? Please share your thoughts as comments on this post.

Categorieën: Mozilla-nl planet

Firefox Tracking Schutz: Spezial-Version von Mozilla - Chip Online

Nieuws verzameld via Google - to, 14/08/2014 - 14:22

Firefox Tracking Schutz: Spezial-Version von Mozilla
Chip Online
Mozilla bietet ab sofort eine spezielle Firefox-Variante an, die bekannte Tracking-Seiten im Web automatisch blockiert. Derzeit nur als frühe Testversion erhätlich, verhindert der neue Firefox schon jetzt, dass Sie diverse Werbetracker beim Surfen ...
Mozilla implementiert Tracking-Schutz in

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

Mozilla to integrate tracking protection in future Firefox versions - Ghacks Technology News

Nieuws verzameld via Google - to, 14/08/2014 - 11:25

Ghacks Technology News

Mozilla to integrate tracking protection in future Firefox versions
Ghacks Technology News
Mozilla is working on a tracking protection feature in Firefox currently that goes a step further than this. It basically enforces DNT on the user side of things by blocking known tracking scripts on the Internet. Part of the feature has been ...

Categorieën: Mozilla-nl planet

Sriram Ramasubramanian: Multiple Text Layout

Mozilla planet - to, 14/08/2014 - 10:41

The pretty basic unit for developing UI in Android is a View. But if we look closely, View is a UI widget that provides user interaction. It comprises of Drawables and text Layouts. We see drawables everywhere — right from the background of a View. TextView has compound drawables too. However, TextView has only one layout. Is it possible to have more than one text layout in a View/TextView?

Multiple Text Layout

Let’s take an example. We have a simple ListView with each row having an image, text and some sub-text. Since TextView shows only one text Layout by default, we would need a LinearLayout with 2 or 3 views (2 TextViews in them) to achieve this layout. What if TextView can hold one more text layout? It’s just a private variable that can be created and drawn on the Even if it can hold and draw it, how would we be able to let TextView’s original layout account for this layout?

If we look at TextView’s onMeasure() closely, the available width for the layout accounts for the space occupied by the compound drawables. If we make TextView account for a larger compound drawable space on the right, the layout will constrain itself more. Now that the space is carved out, we can draw the layout in that space.

private Layout mSubTextLayout; @Override public int getCompoundPaddingRight() { // Assumption: the layout has only one line. return super.getCompoundPaddingRight() + mSubTextLayout.getLineWidth(0); }

Now we need to create a layout for the sub-text and draw. Ideally it’s not good to create new objects inside onMeasure(). But if we take care of when and how we create the layouts, we don’t have to worry about this restriction. And what different kind of Layouts can we create? TextView allows creating a BoringLayout, a StaticLayout or a DynamicLayout. BoringLayout can be used if the text is only single line. StaticLayout is for multi-line layouts that cannot be changed after creation. DynamicLayout is for editable text, like in an EditText.

@Override public void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int width = MeasureSpec.getSize(widthMeasureSpec); // Create a layout for sub-text. mSubTextLayout = new StaticLayout( mSubText, mPaint, width, Alignment.ALIGN_NORMAL, 1.0f, 0.0f, true); // TextView doesn't know about mSubTextLayout. // It calculates the space using compound drawables' sizes. super.onMeasure(widthMeasureSpec, heightMeasureSpec); }

The mPaint used here has all the attributes for the sub-text — like text color, shadow, text-size, etc. This is what determines the size used for a text layout.

@Override public void onDraw(Canvas canvas) { // Do the default draw. super.onDraw(canvas); // Calculate the place to show the sub-text // using the padding, available width, height and // the sub-text width and height. // Note: The 'right' padding to use here is 'super.getCompoundPaddingRight()' // as we have faked the actual value. // Draw the sub-text. mLayout.draw(canvas); }

But hey, can’t we just use a Spannable text? Well… what if the name is really long and runs into multiple lines or need to be ellipsized?

By this, we use the same TextView to draw two layouts. And that has helped us remove 2 Views! Happy hacking! ;)

P.S: The icons are from:

Categorieën: Mozilla-nl planet

Mozilla implementiert Tracking-Schutz in Firefox -

Nieuws verzameld via Google - to, 14/08/2014 - 04:22

Mozilla implementiert Tracking-Schutz in Firefox
Dass für Mozilla die Nutzer an erster Stelle stehen, das beweist Mozilla mit einem neuen Feature für Firefox: Der Browser erhält einen integrierten Tracking-Schutz, welcher bekannte Tracking-Seiten blockiert. Von den großen Browserherstellern gilt ...

Categorieën: Mozilla-nl planet

Hub Figuière: I was at Guadec

Mozilla planet - to, 14/08/2014 - 02:45
Guadec 2014 Volunteers

I was at Guadec in Strasbourg - thanks to all the volunteers who helped making this event possible.. For those who don't know Guadec is the annual Gnome User And Developer European Conference. I hadn't attended since 2008 — such is life — but I reconnected with people I hadn't seen in a while, as well as met awesome people that joined the project since. Attending this year made me regain a lot of motivation on why a Free Software desktop and why Gnome are really necessary. This is even more important as to why at Mozilla I use Fedora Linux rather than MacOS X like most of my team mates —*hint* at least on Fedora I don't have code signing break existing apps, and I have a real full screen browser to use to do presentation based on web technologies or even the risk that one day third party browser be barred like they are on iOS — and it is important to keep the alternatives alive. And Matthew Garrett gave us, during his keynote, good arguments on the importance of a Free Software desktop designed with users in mind.

I'll defintely try to figure out how I can make it to Göteborg, Sweden next year ; this year was facilitated by having a work week in Paris just before Guadec. Maybe I'll even present something as I resumed working on my projects.

Categorieën: Mozilla-nl planet

James Long: Blog Rebuild: Build Systems & Cross-Compiling

Mozilla planet - to, 14/08/2014 - 02:00

This is an entry in a series about rebuilding my custom blog with react, CSP, and other modern tech. Read more in the blog rebuild series.

A few years ago I remember being surprised at how popular grunt was getting. Not because it wasn't great software, but because I didn't understand what problem it solved. If I needed to process a few things like CSS before deploying to production, make seemed to work just fine.

Back then I thought things like build steps for JavaScript were an unnecessary complexity. I couldn't have been more wrong. A build system adds some complexity, yes, but a good one like gulp or broccoli is simple enough, and the returns are enormous. A complex Makefile for a JavaScript project would be a mistake, but these build tools are great.

tl;dr I chose gulp as my build system and webpack as my client-side module bundler. My final setup is on github, specifically gulpfile.js and webpack.config.js.

A Practical Approach

I'm going to be as practical as possible during this rebuild. I'm going to investigate newer things like ES6 modules, but if the tools are too immature I will fallback to something like CommonJS. I want something that works now with little effort.

What I need:

  1. A common module format for the client and server. Node uses CommonJS, and currently browsers do not enforce modules.
  2. For client-side code, a way to compile modules to run in the browser.
  3. An extensible pipeline for hooking in compilation stages for both server and client JS. This lets me hook in various JS transformations that I need.
  4. A watcher that will automatically trigger the necessary compilations to get updates automatically (and only re-compile the necessary files)
  5. Ability to define a few basic build tasks for moving files around and running the app

There are lots of things involved in the above requirements: compilation strategies, module bundling, and build task management. I don't know yet which combination of projects will work out, so let's investigate various solutions.

The main drive for a compilation pipeline is to compile out ES6 features into ES5. I don't want to hook something big like Traceur in because there are projects that compile out specific features better. For example, I want to use regenerator to compile out generators and then defs to compile out let. I've always enjoyed this post about ClojureScript's compilation pipeline, and I'm reminded of it when I think of this strategy of incrementally compiling an AST. Ideally, we will pass an AST around, but we'll see if the tools are good enough for that yet.

Of course, I'm a big fan of sweet.js so that will be the first compilation phase. I may compile out some ES6 features with the es6-macros project, but the reality is that the JS community has written mature ES6 transformations in the form of compilers, so it might make sense just to use them. I will still use macros for user-land syntax extensions, which I'll talk more about in future posts.

The Core Problem

I think the core problem is that the client and server are very different beasts. Node requires CommonJS and modules separated out into individual files. Browsers don't have modules and it's desirable to bundle everything together into a single JS file to deploy. To make things harder, everything should be sourcemapped.

The first question to ask is how a build system can help. Since we want to work with modules, we need support for N:M files at each build step. That means that given N files, a build step can produce M files. For example, given 1 file, a module plugin will return 10 files (all the dependencies), and then the next step could bundle them all together into 1 file.

This is important for watching and incremental builds. If a dependency changes, even if it's not listed directly in the files to watch, the build system should recompile. Additionally, it should only recompile the necessary changes, so it should cache each dependency, even if it's not explicitly listed in the original sources.

The second question to ask is what tools are out there for working with modules. The build system is the backbone, but we need plugins for actually doing things with modules. How well the build system supports N:M files affects how much the module loaders need to do.

Lastly, there's one more desirable feature. There are several transformations I want to do to my code (like sweet.jsregeneratordefs). It would be far better to pass an AST through this process rather than passing strings. This means we probably don't want to hook up this whole pipeline through whatever build system we choose, but wrap it up into a single plugin.

Gulp + Webpack

Gulp is a build system built around streams. One thing I like is that it's very simple to use and define new tasks. (Note: I'm going to skip over grunt because its config syntax is really bad and I just don't like it.)

Gulp supports the N:M file builds in the form of stream events. A plugin can take a single file from a stream and output multiple files. If you add a caching layer with gulp-cache, and use the more advanced gulp-watch, you could effectively pass in one JS file and have it watch and rebuild all of its dependencies.

I'm not sure a lot of people understand that you can do this, which emits 2 files for every file that comes down the stream:

function explode() { return es.through(function(file) { this.emit('data', new gutil.File({ base: file.base, cwd: file.cwd, path: path.join(file.base, 'foo.js'), contents: new Buffer('boo') })); this.emit('data', file); }); } gulp.task("explode", function() { gulp.src('input/main.js') .pipe(explode()) .pipe(gulp.dest('output')); });

Not very many projects use this to help with module bundling, though. There is one project, amd-optimize, that does basic dependency tracing for AMD modules. Still, the more sophisticated gulp-watch is needed if you want to watch new files from the stream (you could apply it after explode()); it is not builtin. Generally, there is very little mature code that integrates a module bundler into gulp. You have to work at it. So this doesn't really solve our problem of compiling modules for client-side. Everyone just uses browserify or webpack.

Additionally, you really only care about your local dependencies, not ones pulled from npm. You don't need to run your code transformations on npm dependencies. So it's really easy to just give the native watch all of your modules by just doing gulp.src('src/**/*.js'). Because of this, and the fact that server-side code doesn't require module bundling, gulp works well for transforming server-side code. This code transforms each file from src and generates files in the build folder with sourcemaps.

function makeNodeStream(src, withoutSourcemaps) { var stream = src.pipe(cache('src')) .pipe(sourcemaps.init()) .pipe(sweetjs({ readableNames: true, modules: ['es6-macros'] })) .pipe(regenerator()) .pipe(jsheader('var wrapGenerator = require("regenerator/runtime/dev").wrapGenerator;')) .pipe(jsheader('require("source-map-support");')); if(!withoutSourcemaps) { stream = stream.pipe(sourcemaps.write('.')); } return stream; } gulp.task("src", function(cb) { es.merge( makeNodeStream(gulp.src('src/**/*.js')) .pipe(gulp.dest('build')), makeNodeStream(gulp.src('static/js/shared/**/*.js')) .pipe(gulp.dest('build/shared')), gulp.src(['src/**/*', '!src/**/*.js']).pipe(gulp.dest('build')) ).on('end', function() { nodemon.restart(); cb(); }); });

An additional complexity is that I have a shared folder that also needs to be transformed and output to a different directory. As for as I could tell, I couldn't combine that into a single gulp.src and gulp.dest, so I created makeNodeStream to run it on both. I also copy anything that's not a JS file from src to the build folder. Lastly, when it's finished it restarts the node process using nodemon.

My transformation pipeline here goes like this: sweet.js → regenerator → header append. I will likely add more steps in the future. This is passing around strings, which I talked about before, when we really should pass around ASTs. One thing I could do is use esnext instead and integrate sweet.js with it, and then do a single pipe to it. It would probably be much faster.

It takes about 2 seconds to compile my whole src directory, which is a bunch of code. But who cares? You don't need to recompile everything when just one file changes! Note that I use the cache('src') step first from gulp-cached; this will cache all files coming through the stream, and only re-emit files that have changed. That means we only transform new files, and it only takes a few hundred ms now.


What about client-side code? As mentioned before, even though gulp could be used as a module bundler, nobody does that since mature projects like browserify and webpack exist. I chose to use webpack since I like the API and documentation better (and it has more features).

This basically requires me to use CommonJS modules for the browser. This route is well-established in the JS community so I benefit from mature tools. Eventually I'd like to use ES6 modules, but the ecosystem isn't quite there yet. I'm being conservative here so that I don't spend too much time on my tools.

Now that I'm using webpack, all of my problems for client-side development are solved. It has everything, from code splitting to hot module replacement. Here is my webpack config:

var config = { cache: true, entry: './static/js/main.js', output: { filename: './static/js/bundle.js' }, resolve: { extensions: ['', '.js', '.sjs'], fallback: __dirname }, module: { loaders: [ {test: /\.js$/, exclude: [/static\/js\/lib\/.*\.js$/, /node_modules\/.*/], loader: 'regenerator!sweetjs?modules[]=es6-macros'}, {test: /\.less$/, loader: "style!css!less"}, {test: /\.css$/, loader: "style!css"} ] } };

Webpack is explicitly a module bundler, so all it needs is just one file and it will walk the dependencies. Everything will be bundled together into a single file bundle.js. This happens by default, so you can see why this doesn't work for server-side code where we just need a 1:1 file mapping.

This uses a loader on JS files to run them through sweet.js and regenerator. Again, I really should look into esnext so that I don't keep re-parsing the code.

It also uses some really cool loaders to deal with stylesheets. less-loader compiles out lesscss. css-loader is an awesome loader that converts all @import and url statements to require so that everything is resolved the same way, and lets you apply loaders on those resources being loaded, allowing things like inlining the url content straight into the stylesheet. Having everything go through the same mechanism (and able to pull from npm dependencies) is extremely liberating.

To top it all off, style-loader is a loader that automatically adds a style tag to the page when the css file is requireed. It also inlines all the CSS into your JavaScript bundle, but you can also make it reference an external CSS file. Either way, all you have to do is require('css/main.css') in your JavaScript and it just works.

There are a few other things I do with gulp and webpack, mostly to get integration with a few modules pulled down from npm (like React) working. I also have a run task that starts my app and uses nodemon to track it so it can be restarted whenever a change happens.

View my final setup on github.

Broccoli + ES6 modules

Broccoli is a rather new build tool that operates on tree structures, so it gets good incremental rebuilds and watches for free. See the annoucement blog post for more details.

I'm not sure if broccoli competes more with gulp or webpack. It sits somewhere in the middle. It doesn't have any concept of tasks, so I can't make a run task that restarts my server on changes. But it's also not nearly as specific as webpack, and doesn't dictate anything specific about modules or how things are bundled.

I think broccoli makes it a lot easier to write something like webpack, and that's the idea. Basically, in broccoli plugins are always passing around whole trees of files, and a plugin can easily expand a tree into a much bigger tree if needed. This makes it easy to expand dependencies but still leverage the build system to handle them. So watching for changes in dependencies works great, and incremental builds are really fast because it can easily figure out what to do. Webpack has to figure all of this stuff out itself.

I like the idea of broccoli, and because working with modules is easy people are doing a lot of great work to get a workflow for compiling ES6 modules. This plugin integrates es6-module-transpiler with broccoli and does all the dependency stuff.

The thing broccoli could solve for me is not only using ES6 modules, but also to unify the JS transformation between server-side and client-side. Using gulp and webpack, I have two completely separate processes.

This was my first Brocfile.js to see how it would work out:

var pickFiles = require('broccoli-static-compiler'); var sweetjs = require('broccoli-sweetjs'); var transpileES6 = require('broccoli-es6-module-transpiler'); var src = pickFiles('src', { srcDir: '/', destDir: '/' }); src = sweetjs(src, { modules: ['es6-macros'] }); src = transpileES6(src, { type: 'cjs' }); module.exports = src;

Unfortunately, I immediately ran into a bug and it wouldn't compile my code. Somehow I was using an older version that didn't work with nested yields (I guess a newer version needs to be pushed to npm). These kinds of bugs can easily be fixed.

I also ran into a bigger issue though: that project does not have a good story for integration with npm dependencies yet (more discussion here). With webpack, I could require just require dependencies and it would look in node_modules, and it worked awesomely. I don't know why we can't do something similar with ES6 modules.

There was also another big issue in general with broccoli: sourcemaps. The sourcemap story for broccoli is very vague (es6-module-transpiler supports them just fine, but I don't know how to expand with sweet.js and pass it the result & sourcemaps and make it combine them). The standard project broccoli-filter which is supposed to be used by plugins that simply map files 1:1 states right in the README that is does not support sourcemaps. That is insane to me and I can't think about using broccoli until sourcemaps are deeply integrated through and through. Also see this discussion.

In gulp, it's really easy with the awesome gulp-sourcemaps project. You just hook into the stream and write sourcemaps to a directory:

src.pipe('src/**/*.js') .pipe(sourcemaps.init()) .pipe(sweetjs()) .pipe(regenerator()) .pipe(sourcemaps.write('.'));

Plugins have a standard method of applying sourcemaps. The sourcemap is attached to the File instances that are passed through the stream, and combined using vinyl-sourcemaps-apply. It looks like this:

var applySourceMap = require('vinyl-sourcemaps-apply'); // ... if(myGeneratedSourceMap) { applySourceMap(file, myGeneratedSourceMap); }

That incrementally combines sourcemaps as they are applied through the streams. It has worked out really well for me.

Even without all these problems, the story in general for browser-side module bundling isn't nearly as strong as browserify or webpack, which have tons of features specific for browser modules. So until we get a solid build system that has plugins that implement most of those features of a module bundler, right now using gulp/broccoli + browserify/webpack works pretty darn well.

Most likely, I will switch my project to ES6 modules when can find a good cross-compiler that works well with CommonJS and my current build system.

I could use broccoli and webpack, but at this point I'm just going to stick with gulp. It's easy to use and works really well with server-side transformation and sourcemaps. As for broccoli, I understand the design and I like it, but it does make plugin development very complicated and I'm not entirely sold on it, especially when you can do N:M compilations with gulp. Lastly, it uses temporary files so gulp is potentially faster with streams.

Stream of Thought EOF

There are several other build systems out there and a million ways to combine them. I can't possibly cover all of them, but I hope this gave some insight into my process for researching. I have something that works well, and the only thing I'll improve in the future is using ES6 modules instead of CJS.

View the full repo to see all the glorious code. Specifically, check out the full gulpfile.js and webpack.config.js. What's neat about this set up is I can run webpack from the CLI like normal, but it's also defined as a task so gulp webpack will work and it can be used as a task dependency (for tasks like gulp all). I can switch between the systems easily.

I'm sure I have made some errors in this post, as it was mostly stream of thought as I was doing my research. If something is completely off, let me know.

Categorieën: Mozilla-nl planet

Daniel Stenberg: I’m with Firefox OS!

Mozilla planet - wo, 13/08/2014 - 23:53

I have received a Firefox OS tablet as part of a development program. My plan is to use this device to try out stuff I work on and see how it behaves on Firefox OS “for real” instead of just in emulators or on other systems. While Firefox OS is a product of my employer Mozilla, I personally don’t work particularly much with Firefox OS specifically. I work on networking in general for Firefox, and large chunks of the networking stack is used in both the ordinary Firefox browser like on desktops as well as in Firefox OS. I hope to polish and improve networking on Firefox OS too over time.

Firefox OS tablet


The primary development device for Firefox OS is right now apparently the Flame phone, and I have one of these too now in my possession. I took a few photos when I unpacked it and crammed them into the same image, click it for higher res:

Flame - Firefox OS phone

A brief explanation of Firefox OS

Firefox OS is an Android kernel (including drivers etc) and a bionic libc – simply the libc that Android uses. Linux-wise and slightly simplified, it runs a single application full-screen: Firefox, which then can run individual Firefox-apps that appears as apps on the phone. This means that the underlying fundamentals are shared with Android, while the layers over that are Firefox and then a world of HTML and javascript. Thus most of the network stack used for Firefox – that I work with – the http, ftp, dns, cookies and so forth is shared between Firefox for desktop and Firefox for Android and Firefox OS.

Firefox OS is made to use a small footprint to allow cheaper smartphones than Android itself can. Hence it is targeted to developing nations and continents.

Both my devices came with Firefox OS version 1.3 pre-installed.

The phone

The specs: Qualcomm Snapdragon 1.2GHZ dual-core processor, 4.5-inch 854×480 pixel screen, five-megapixel rear camera with auto-focus and flash, two-megapixel front-facing camera. Dual-SIM 3G, 8GB of onboard memory with a microSD slot, and a 1800 mAh capacity battery.

The Flame phone should be snappy enough although at times it seems to take a moment too long to populate a newly shown screen with icons etc. The screen surface is somehow not as smooth as my Nexus devices (we have the 4,5,7,10 nexuses in the house), leaving me with a constant feeling the screen isn’t cleaned.

Its dual-sim support is something that seems ideal for traveling etc to be able to use my home sim for incoming calls but use a local sim for data and outgoing calls… I’ve never had a phone featuring that before. I’ve purchased a prepaid SIM-card to use with this phone as my secondary device.

Some Good

I like the feel of the tablet. It feels like a solid and sturdy 10″ tablet, just like it should. I think the design language of Firefox OS for a newbie such as myself is pleasing and good-looking. The quad-core 1GHz thing is certainly fast enough CPU-wise to eat most of what you can throw at it.

These are really good devices to do web browsing on as the browser is a highly capable and fast browser.

Mapping: while of course there’s Google maps app, using the openstreetmap map is great on the device and Google maps in the browser is also a perfectly decent way to view maps. Using openstreetmap also of course has the added bonus that it feels great to see your own edits in your own neck of the woods!

I really appreciate that Mozilla pushes for new, more and better standardized APIs to enable all of this to get done in web applications. To me, this is one of the major benefits with Firefox OS. It benefits all of us who use the web.

Some Bad

Firefox OS feels highly US-centric (which greatly surprised me, seeing the primary markets for Firefox OS are certainly not in the US). As a Swede, I of course want my calendar to show Monday as the first day of the week. No can do. I want my digital clock to show me the time using 24 hour format (the am/pm scheme only confuses me). No can do. Tiny teeny details in the grand scheme of things, yes, but annoying. Possibly I’m just stupid and didn’t find how to switch these settings, but I did look for them on both my devices.

The actual Firefox OS system feels like a scaled-down Android where all apps are simpler and less fancy than Android. There’s a Facebook “app” for it that shows Facebook looking much crappier than it usually does in a browser or in the Android app – although on the phone it looked much better than on the tablet for some reason that I don’t understand.

I managed to get the device to sync my contacts from Google (even with my google 2-factor auth activated) but trying to sync my Facebook contacts just gave me a very strange error window in spite of repeated attempts, but again that worked on my phone!

I really miss a proper back button! Without it, we end up in this handicapped iphone-like world where each app has to provide a back button in its own UI or I have to hit the home button – which doesn’t just go back one step.

The tablet supports a gesture, pull up from the button of the screen, to get to the home screen while the phone doesn’t support that but instead has a dedicated home button which if pressed a long time shows up cards with all currently running apps. I’m not even sure how to do that latter operation on the tablet as it doesn’t’ have a home button.

The gmail web interface and experience is not very good on either of the devices.

Building Firefox OS

I’ve only just started this venture and dipped my toes in that water. All code is there in the open and you build it all with open tools. I might get back on this topic later if I get the urge to ventilate something from it… :-) I didn’t find any proper device specific setup for the tablet, but maybe I just don’t know its proper code word and I’ve only given it a quick glance so far. I’ll do my first builds and installs for the phone. Any day now!


My seven year old son immediately found at least one game on my dev phone (he actually found the market and downloaded it all by himself the first time he tried the device) that he really likes and now he wants to borrow this from time to time to play that game – in competition with the android phones and tablets we have here already. A pretty good sign I’d say.

Firefox OS is already a complete and competent phone operating system and app ecosystem. If you’re not coming from Android or Iphone it is a step up from everything else. If you do come from Android or Iphone I think you have to accept that this is meant for the lower end spectrum of smart-phones.

I think the smart-phone world can use more competition and Firefox OS brings exactly that.


Categorieën: Mozilla-nl planet

Matt Brubeck: Let's build a browser engine! Part 3: CSS

Mozilla planet - wo, 13/08/2014 - 21:30

This is the third in a series of articles on building a toy browser rendering engine. Want to build your own? Start at the beginning to learn more:

This article introduces code for reading Cascading Style Sheets (CSS). As usual, I won’t try to cover everything in the spec. Instead, I tried to implement just enough to illustrate some concepts and produce input for later stages in the rendering pipeline.

Anatomy of a Stylesheet

Here’s an example of CSS source code:

h1, h2, h3 { margin: auto; color: #cc0000; } div.note { margin-bottom: 20px; padding: 10px; } #answer { display: none; }

Next I’ll walk through the css module from my toy browser engine, robinson. The code is written in Rust, though the concepts should translate pretty easily into other programming languages. Reading the previous articles first might help you understand some the code below.

A CSS stylesheet is a series of rules. (In the example stylesheet above, each line contains one rule.)

struct Stylesheet { rules: Vec<Rule>, }

A rule includes one or more selectors separated by commas, followed by a series of declarations enclosed in braces.

struct Rule { selectors: Vec<Selector>, declarations: Vec<Declaration>, }

A selector can be a simple selector, or it can be a chain of selectors joined by combinators. Robinson supports only simple selectors for now.

Note: Confusingly, the newer Selectors Level 3 standard uses the same terms to mean slightly different things. In this article I’ll mostly refer to CSS2.1. Although outdated, it’s a useful starting point because it’s smaller and more self-contained than CSS3 (which is split into myriad specs that reference both each other and CSS2.1).

In robinson, a simple selector can include a tag name, an ID prefixed by '#', any number of class names prefixed by '.', or some combination of the above. If the tag name is empty or '*' then it is a “universal selector” that can match any tag.

There are many other types of selector (especially in CSS3), but this will do for now.

enum Selector { Simple(SimpleSelector), } struct SimpleSelector { tag_name: Option<String>, id: Option<String>, class: Vec<String>, }

A declaration is just a name/value pair, separated by a colon and ending with a semicolon. For example, "margin: auto;" is a declaration.

struct Declaration { name: String, value: Value, }

My toy engine supports only a handful of CSS’s many value types.

enum Value { Keyword(String), Color(u8, u8, u8, u8), // RGBA Length(f32, Unit), // insert more values here } enum Unit { Px, /* insert more units here */ }

All other CSS syntax is unsupported, including @-rules, comments, and any selectors/values/units not mentioned above.


CSS has a regular grammar, making it easier to parse correctly than its quirky cousin HTML. When a standards-compliant CSS parser encounters a parse error, it discards the unrecognized part of the stylesheet but still processes the remaining portions. This is useful because it allows stylesheets to include new syntax but still produce well-defined output in older browsers.

Robinson uses a very simplistic (and totally not standards-compliant) parser, built the same way as the HTML parser from Part 2. Rather than go through the whole thing line-by-line again, I’ll just paste in a few snippets. For example, here is the code for parsing a single selector:

/// Parse one simple selector, e.g.: `type#id.class1.class2.class3` fn parse_simple_selector(&mut self) -> SimpleSelector { let mut result = SimpleSelector { tag_name: None, id: None, class: Vec::new() }; while !self.eof() { match self.next_char() { '#' => { self.consume_char(); = Some(self.parse_identifier()); } '.' => { self.consume_char(); result.class.push(self.parse_identifier()); } '*' => { // universal selector self.consume_char(); } c if valid_identifier_char(c) => { result.tag_name = Some(self.parse_identifier()); } _ => break } } result }

Note the lack of error checking. Some malformed input like ### or *foo* will parse successfully and produce weird results. A real CSS parser would discard these invalid selectors.


Specificity is one of the ways a rendering engine decides which style overrides the other in a conflict. If a stylesheet contains two rules that match an element, the rule with the matching selector of higher specificity can override values from the one with lower specificity.

The specificity of a selector is based on its components. An ID selector is more specific than a class selector, which is more specific than a tag selector. Within each of these “levels,” more selectors beats fewer.

pub type Specificity = (uint, uint, uint); impl Selector { pub fn specificity(&self) -> Specificity { // let Simple(ref simple) = *self; let a =; let b = simple.class.len(); let c = simple.tag_name.iter().len(); (a, b, c) } }

(If we supported chained selectors, we could calculate the specificity of a chain just by adding up the specificities of its parts.)

The selectors for each rule are stored in a sorted vector, most-specific first. This will be important in matching, which I’ll cover in the next article.

/// Parse a rule set: `<selectors> { <declarations> }`. fn parse_rule(&mut self) -> Rule { Rule { selectors: self.parse_selectors(), declarations: self.parse_declarations() } } /// Parse a comma-separated list of selectors. fn parse_selectors(&mut self) -> Vec<Selector> { let mut selectors = Vec::new(); loop { selectors.push(Simple(self.parse_simple_selector())); self.consume_whitespace(); match self.next_char() { ',' => { self.consume_char(); } '{' => break, // start of declarations c => fail!("Unexpected character {} in selector list", c) } } // Return selectors with highest specificity first, for use in matching. selectors.sort_by(|a,b| b.specificity().cmp(&a.specificity())); selectors }

The rest of the CSS parser is fairly straightforward. You can read the whole thing on GitHub. And if you didn’t already do it for Part 2, this would be a great time to try out a parser generator. My hand-rolled parser gets the job done for simple example files, but it has a lot of hacky bits and will fail badly if you violate its assumptions. Eventually I hope to replace it with one built on rust-peg or similar.


As before, you should decide which of these exercises you want to do, and skip the rest:

  1. Implement your own simplified CSS parser and specificity calculation.

  2. Extend robinson’s CSS parser to support more values, or one or more selector combinators.

  3. Extend the CSS parser to discard any declaration that contains a parse error, and follow the error handling rules to resume parsing after the end of the declaration.

  4. Make the HTML parser pass the contents of any <style> nodes to the CSS parser, and return a Document object that includes a list of Stylesheets in addition to the DOM tree.


Just like in Part 2, you can skip parsing by hard-coding CSS data structures directly into your program, or by writing them in an alternate format like JSON that you already have a parser for.

To be continued…

The next article will introduce the style module. This is where everything starts to come together, with selector matching to apply CSS styles to DOM nodes.

The pace of this series might slow down soon, since I’ll be busy later this month and I haven’t even written the code for some of the upcoming articles. I’ll keep them coming as fast as I can!

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox 32 beta5 to beta6

Mozilla planet - wo, 13/08/2014 - 20:00

  • 26 changesets
  • 33 files changed
  • 503 insertions
  • 244 deletions

ExtensionOccurrences cpp8 js6 h6 html2 build2 xul1 xml1 sh1 py1 java1 ini1 in1 c1

ModuleOccurrences content9 mobile4 js4 mozglue3 browser3 media2 dom2 toolkit1 testing1 netwerk1 modules1 build1

List of changesets:

Matthew GreganBug 992238 - Disable test_init_destroy_multiple_contexts_and_streams on Windows 7. r=padenot, a=test-only - 980f2d449ccb Martijn WargersBug 928678 - Hopeful fix for intermittent failure. r=jmaher, a=test-only - 04f540c59457 Chris PearceBug 1046003 - Ensure duplicate frames after a seek have an Image. r=kinetik, a=sledru - 91f078c385f8 Mike HommeyBug 1036286 - Delay registration of the faulty.lib signal handler until when it's necessary. r=nfroyd, a=sledru - ec230387fad2 Mike HommeyBug 1036286 - Ensure faulty.lib diverts libc's sigaction instead of a LD_PRELOADed one. r=nfroyd, a=sledru - 1f96d584763a Bobby HolleyBug 1042436 - Always enter the wrapper's compartment before invoking SilentFailure. r=gabor, a=sledru - 6037db66624b Bobby HolleyBug 1042436 - Lowercase the "reason" param to SilentFailure. a=sledru - 4cb373d9ce33 Bobby HolleyBug 1042436 - Warn once to the console when XrayWrappers deny access to an object. r=gabor, sr=smaug, a=sledru - 1cf7b5810eb5 Ryan VanderMeulenBacked out changesets 1cf7b5810eb5, 4cb373d9ce33, and 6037db66624b (Bug 1042436) for bustage. - 53c7aceaf1a8 Bobby HolleyBug 1042436 - Always enter the wrapper's compartment before invoking SilentFailure. r=gabor - 08c5b02a125e Bobby HolleyBug 1042436 - Lowercase the "reason" param to SilentFailure. r=me - 84bf42618416 Bobby HolleyBug 1042436 - Warn once to the console when XrayWrappers deny access to an object. r=gabor,sr=smaug a=sylvestre - c405f720f587 Georg FritzscheBug 1048793 - Skip CertUtils checks as we changed providers and PublicKeyPinningService already provides them. r=mmc, a=sledru - 7aa9781a3758 Marco BonardoBug 997970 - Add search suggest to Amazon for en-US. r=ttaubert, a=sledru - 3f7ae08da07f Paul AdenotBug 1047831. r=ehsan, a=sledru - 0c488a1d2142 Richard NewmanBug 1050690. r=wesj, a=sledru - 6b9281a057b7 Tim TaubertBug 1048133 - Check key algorithms before using them for encryption/signatures r=rbarnes a=abillings - 6a7e6708ded1 Cosmin MalutanBug 1032255 - TPS has to exit with code != 0 in case of failures. r=aeftimie, dhunt a=testonly DONTBUILD - 1b581df81c9b Mike HommeyBug 1048064 - Fix libstagefright build on GNU/kFreeBSD. r=ajones, a=NPOTB - 2e0eeb786e7d Karl TomlinsonBug 995075 - Include update_filter() changes from upstream speexdsp. r=padenot, a=sledru - 92c3567e5a0c Patrick McManusBug 1045640 - disable tls proxying Bug 378637 on gecko 32 r=backout a=lmandel r=hurley - c9dec07b4148 Ryan VanderMeulenBacked out changeset 551f71d3138f (Bug 1038243) - b8d426a326f5 Richard NewmanBug 936851 - Part 1: Remove VideoPlayer. r=mfinkle, a=lmandel - e9fc6b3efaf3 Richard NewmanBug 936851 - Part 2: Delegate to Fennec itself for YouTube video instead of VideoPlayer. r=mfinkle, a=lmandel - 086068fe1b98 Wes JohnstonBug 1046500 - Fix mediagroup parsing in feed parser. r=mak, a=sledru - f76498a1bcbd Lawrence MandelPost Beta 4: disable EARLY_BETA_OR_EARLIER a=me - 8bf5700cb82e

Categorieën: Mozilla-nl planet