mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Bryce Van Dyk: Why Does Firefox Use e4 and e5 Values to Fill Memory?

Mozilla planet - snein, 17/09/2017 - 16:58

I was once talking to some colleagues about a Firefox crash bug. As we gazed at the crash report, one leaned over and pointed at the value in one of the CPU registers: 0xe5e5e5e9. “Freed memory,” he sagely indicated: “e5”.

Magic debug numbers

Using special numbers to indicate something in memory is an old trick. Wikipedia even has Wikipedia even has famous examples of such things! Neato! These numbers are often referred to as “poison” or “junk” in the context of filling memory (because they’re supposed to cause the program to fail, or be meaningless garbage).

Mozilla uses this trick (and the “poison” terminology) in Firefox debug builds to indicate uninitialized memory (e4), as well as freed memory (e5). Thus the presence of these values in a crash report, or other failure report, indicate that something has gone wrong with memory handling. But why e4 and e5?

jemalloc

jemalloc is a general purpose implementation of malloc. Firefox utilizes a modified version of jemalloc to perform memory allocation. There's a pretty rich history here, and it would take another blog post to cover how and why Mozilla use jemalloc. So I'm going to hand wave and say that it is used, and the reasons for doing so are reasonable.

jemalloc can use magic/poison/junk values when performing malloc or free. However, jemalloc will use the value a5 when allocating, and 5a when freeing, so why do we see something different in Firefox?

A different kind of poison

When using poison values, it's possible for the memory with these values to still be used. The hope is that when doing so the program will crash and you can see which memory is poisoned. However, with the 5a value in Firefox there was concern that 1) the program would not crash, and 2) as a result, it could be exploited: see this bug.

As a result of these concerns, it was decided to use the poison values we see today. The code that sets these values has undergone some changes since the above bug, but the same values are used. If you want to take a look at the code responsible here is a good place to start.

Categorieën: Mozilla-nl planet

Mitchell Baker: Busting the myth that net neutrality hampers investment

Mozilla planet - sn, 16/09/2017 - 06:28

This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas.

I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers.

Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States.

The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population.

At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike.

Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use:


(Video courtesy: GSMA)

If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here.

You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Busting the myth that net neutrality hampers investment

Mozilla planet - sn, 16/09/2017 - 06:03

This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas.

I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers.

Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States.

The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population.

At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike.

Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use:


(Video courtesy: GSMA)

If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here.

You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it.

The post Busting the myth that net neutrality hampers investment appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Busting the myth that net neutrality hampers investment

Mozilla Blog - sn, 16/09/2017 - 06:03

This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas.

I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers.

Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States.

The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population.

At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike.

Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use:


(Video courtesy: GSMA)

If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here.

You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it.

The post Busting the myth that net neutrality hampers investment appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Busting the myth that net neutrality hampers investment

Mitchell Baker - sn, 16/09/2017 - 06:00

This week I had the opportunity to share Mozilla’s vision for an Internet that is open and accessible to all with the audience at MWC Americas.

I took this opportunity because we are at a pivotal point in the debate between the FCC, companies, and users over the FCC’s proposal to roll back protections for net neutrality. Net neutrality is a key part of ensuring freedom of choice to access content and services for consumers.

Earlier this week Mozilla’s Heather West wrote a letter to FCC Chairman Ajit Pai highlighting how net neutrality has fueled innovation in Silicon Valley and can do so still across the United States.

The FCC claims these protections hamper investment and are bad for business. And they may vote to end them as early as October. Chairman Pai calls his rule rollback “restoring internet freedom” but that’s really the freedom of the 1% to make decisions that limit the rest of the population.

At Mozilla we believe the current rules provide vital protections to ensure that ISPs don’t act as gatekeepers for online content and services. Millions of people commented on the FCC docket, including those who commented through Mozilla’s portal that removing these core protections will hurt consumers and small businesses alike.

Mozilla is also very much focused on the issues preventing people coming online beyond the United States. Before addressing the situation in the U.S., journalist Rob Pegoraro asked me what we discovered in the research we recently funded in seven other countries into the impact of zero rating on Internet use:


(Video courtesy: GSMA)

If you happen to be in San Francisco on Monday 18th September please consider joining Mozilla and the Internet Archive for a special night: The Battle to Save Net Neutrality. Tickets are available here.

You’ll be able to watch a discussion featuring former FCC Chairman Tom Wheeler; Representative Ro Khanna; Mozilla Chief Legal and Business Officer Denelle Dixon; Amy Aniobi, Supervising Producer, Insecure (HBO); Luisa Leschin, Co-Executive Producer/Head Writer, Just Add Magic (Amazon); Malkia Cyril, Executive Director of the Center for Media Justice; and Dane Jasper, CEO and Co-Founder of Sonic. The panel will be moderated by Gigi Sohn, Mozilla Tech Policy Fellow and former Counselor to Chairman Wheeler. It will discuss how net neutrality promotes democratic values, social justice and economic opportunity, what the current threats are, and what the public can do to preserve it.

Categorieën: Mozilla-nl planet

Air Mozilla: Webdev Beer and Tell: September 2017, 15 Sep 2017

Mozilla planet - fr, 15/09/2017 - 20:00

 September 2017 Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...

Categorieën: Mozilla-nl planet

David Humphrey: Why Good-First-Bugs often aren't

Mozilla planet - fr, 15/09/2017 - 18:45

Let me start by saying that I'm a huge fan of open source projects putting a Good-First-Bug type label on issues. From my own experience over the past decade trying to get students engaged in open source projects, it's often a great way to quickly find entry points for new people. Right now I've got 40 students learning open source with me at Seneca, and because I want to get them all working on bugs ASAP, you better believe that I'm paying close attention to good-first-bug labels!

Maintainers

There are a few ways that we tend to interact with good-first-bugs. First, we have project maintainers who add the label when they think they see something that might be a good fit for someone new. I've been this person, and I know that it takes some discipline to not fix every bug. To be honest, it's faster and easier to just fix small things yourself. It's also going to mean you end up having to fix everything yourself--you won't grow new contributors this way.

What you need to do instead is to write large amounts of prose of the type "Here's what you need to do if you're interested in fixing this". You need sample code, links to relevant files, screenshots, etc. so that someone who lands in this bug can readily assess whether their current skill level (or aspirational skill level), and the bug's requirements, meet.

Sometimes maintainers opt not to do this, and instead say, "I'd be willing to mentor this." The problem with this approach, in my experience, is that it becomes a kind of debt with which you saddle your future self. Are you sure you'll want to mentor this bug in 2 years, when it's no longer on your roadmap? You'd be better to "mentor" the bug upfront, and just spell out what has to happen in great detail: "Do this, this, and this." If you can't do that, the reality is it's not a good-first-bug.

New Contributors

The second way we encounter good-first-bugs is as someone looking for an opportunity to contribute. I make a habit of finding/fixing these in various projects so that I can use real examples to show my students the steps. I also tag along with my students as they attempt them, and I've seen it all. It's interesting what you encounter on this side of things. Sometimes it goes exactly as you'd hope: you make the fix and the patch is accepted. However, more often then not you run into snags.

First, before you even get going on a fix, finding a bug that isn't already being worked on can be hard. A lot of people are looking for opportunities to get started, and when you put up a sign saying "Start Here," people will! Read through the comments on many good-first-bugs and you'll find an unending parade of "I'd like to work on this bug!" and "Can you assign this to me?" followed by "Are you still working on this?" and "I'm new, can you help me get started?". That stream of comments often repeats forever, leaving the project maintainers frustrated, the contributors lost, and the bug untouched.

Expiry Dates

Once people do get started on a bug, another common problem I see is that the scope of the bug has shifted such that the problem/fix described no longer makes sense. You see a lot of responses like this: "Thanks for this fix, but we've totally refactored this code, and it's not necessary any more. Closing!" This doesn't feel great, or make you want to put more effort into finding something else to do.

The problem here wasn't that the bug was wrong...when filed. The bug has become obsolete over time. Good-first-bugs really need an expiry date. If a project isn't triaging its good-first-bugs on a somewhat regular basis, it's basically going to end up in this state eventually, with some or all of them being useless, and therefore bad-first-bugs. You're better off closing bugs like this and having no good-first-bugs listed, than to have 50 ancient bugs that no one on the project cares about, wants to review, or has time to discuss.

Good First Experience

This week I've been thinking a lot about ways to address some of the problems above. In their lab this week, I asked my students to build Firefox, and also to make some changes to the code. I had a few goals with this:

  • Build a large open source project to learn about setting up dev environments, obtaining source code, build systems, etc.
  • Gain some experience making a change and rebuilding Firefox, to prove to themselves that they could do it and to remove some of the mystery around how one does this.
  • Learn how to start navigating around in large code, see how things are built (e.g., Firefox uses JS and CSS for its front-end).
  • Have some fun doing something exciting and a bit scary

I've done this many times in the past, and often I've gone looking for a simple good-first-bug to facilitate these goals. This time I wanted to try something different. Instead of a good-first-bug, I wanted what I'll call a "Good First Experience."

A Good First Experience tries to do the following:

  • It's reproducible by everyone. Where a good-first-bug is destroyed in being fixed, a good-first-experience doesn't lose its potential after someone completes it.
  • It's not tied to the current state of the project, and therefore doesn't become obsolete (as quickly). Where a good-first-bug is always tied to the project's goals, coding practices, and roadmap, a good-first-experience is independent of the current state of the project.
  • It's meant to be fun, exploratory, and safe. Where a good-first-bug is about accomplishing a task, and is therefore defined and limited by that task, a good-first-experience can be the opposite: an unnecessary change producing an outcome whose value is measured by the participate vs the project.
Toward a Good First Experience with Firefox

I reached out to a half-dozen Mozilla colleagues for ideas on what we could try (thanks to all who replied). I ended-up going with some excellent suggestions from Blake Winton (@bwinton). Blake has a history of being whimsical in his approach to his work at Mozilla, and I think he really understood what I was after.

Based on his suggestions, I gave the students some options to try:

  • In browser/base/content/browser.js change the function OpenBrowserWindow to automatically open cat GIFs. You can alter the code like so:
function OpenBrowserWindow(options) { return window.open("http://www.chilloutandwatchsomecatgifs.com"); }
  • Look at the CSS in browser/base/content/browser.css and try changing some of the colours.

  • Modify the way tabs appear by playing with CSS in browser/themes/shared/tabs.inc.css, for example: you could alter things like min-height.

  • You could try adding a background: url(http://i.imgur.com/UkT7jcm.gif); to the #TabsToolbar in browser/themes/windows/browser.css to add something new

  • Modify the labels for menu items like "New Window" in browser/locales/en-US/chrome/browser/browser.dtd to something else.

None of these changes are necessary, prudent, or solving a problem. Instead, they are fun, exploratory, and simple. Already students are having some success, which is great to see.

Example of what students did

Nature via National Park vs. Wilderness

I was reflecting that the real difference between a good-first-experience and a real bug is a lot like experiencing nature by visiting a National Park vs. setting out in the wilderness. There isn't a right or wrong way to do this, and both have obvious advantages and disadvantages. However, what National Parks do well is to make the experience of nature accessible to everyone: manicured paths, maps with established trails to follow, amenities so you can bring your family, information. It's obviously not the same as cutting a trail into a forest, portaging your canoe between lakes, or hiking on the side of a mountain. But it means that more people can try the experience of doing the real thing in relative safety, and without a massive commitment of time or effort. It's also a mostly self-guided experience vs. something you need a guide (maintainer) to accomplish. In the end, this experience might be enough for many people, and will help bring awareness and an enriching experience. For others, it will be the beginning of bolder outings into the unknown.

I don't think my current attempt represents a definitive good-first-experience in Mozilla, but it's got me thinking more about what one might look like, and I wanted to get you thinking about them too. I know I'm not alone in wanting to bring students into projects like Mozilla and Firefox, and needing a repeatable entry point.

Categorieën: Mozilla-nl planet

The Firefox Frontier: Put your multiple online personalities in Firefox Multi-Account Containers

Mozilla planet - to, 14/09/2017 - 22:40

Our new Multi-Account Containers extension for Firefox means you can finally wrangle multiple email/social accounts. Maybe you’ve got two Gmail or Instagram or Twitter or Facebook accounts (or a few … Read more

The post Put your multiple online personalities in Firefox Multi-Account Containers appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Air Mozilla: Measuring the Subjective: The Performance Dashboard with Estelle Weyl

Mozilla planet - to, 14/09/2017 - 19:00

 The Performance Dashboard with Estelle Weyl Performance varies quite a bit depending on the site, the environment and yes, the user. And users don't check your performance metrics. Instead, they perceive...

Categorieën: Mozilla-nl planet

Air Mozilla: Measuring the Subjective: The Performance Dashboard with Estelle Weyl

Mozilla planet - to, 14/09/2017 - 19:00

 The Performance Dashboard with Estelle Weyl Performance varies quite a bit depending on the site, the environment and yes, the user. And users don't check your performance metrics. Instead, they perceive...

Categorieën: Mozilla-nl planet

About:Community: Firefox 56 new contributors

Mozilla planet - to, 14/09/2017 - 18:13

With the upcoming release of Firefox 56, we are pleased to welcome the 37 developers who contributed their first code change to Firefox in this release, 29 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Sep. 14, 2017

Mozilla planet - to, 14/09/2017 - 18:00

Reps Weekly Meeting Sep. 14, 2017 This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

Air Mozilla: Reps Weekly Meeting Sep. 14, 2017

Mozilla planet - to, 14/09/2017 - 18:00

Reps Weekly Meeting Sep. 14, 2017 This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Building the DOM faster: speculative parsing, async, defer and preload

Mozilla planet - to, 14/09/2017 - 16:54

In 2017, the toolbox for making sure your web page loads fast includes everything from minification and asset optimization to caching, CDNs, code splitting and tree shaking. However, you can get big performance boosts with just a few keywords and mindful code structuring, even if you’re not yet familiar with the concepts above and you’re not sure how to get started.

The fresh web standard <link rel="preload">, that allows you to load critical resources faster, is coming to Firefox later this month. You can already try it out in Firefox Nightly or Developer Edition, and in the meantime, this is a great chance to review some fundamentals and dive deeper into performance associated with parsing the DOM.

Understanding what goes on inside a browser is the most powerful tool for every web developer. We’ll look at how browsers interpret your code and how they help you load pages faster with speculative parsing. We’ll break down how defer and async work and how you can leverage the new keyword preload.

Building blocks

HTML describes the structure of a web page. To make any sense of the HTML, browsers first have to convert it into a format they understand – the Document Object Model, or DOM. Browser engines have a special piece of code called a parser that’s used to convert data from one format to another. An HTML parser converts data from HTML into the DOM.

In HTML, nesting defines the parent-child relationships between different tags. In the DOM, objects are linked in a tree data structure capturing those relationships. Each HTML tag is represented by a node of the tree (a DOM node).

The browser builds up the DOM bit by bit. As soon as the first chunks of code come in, it starts parsing the HTML, adding nodes to the tree structure.

The DOM has two roles: it is the object representation of the HTML document, and it acts as an interface connecting the page to the outside world, like JavaScript. When you call document.getElementById(), the element that is returned is a DOM node. Each DOM node has many functions you can use to access and change it, and what the user sees changes accordingly.

CSS styles found on a web page are mapped onto the CSSOM – the CSS Object Model. It is much like the DOM, but for the CSS rather than the HTML. Unlike the DOM, it cannot be built incrementally. Because CSS rules can override each other, the browser engine has to do complex calculations to figure out how the CSS code applies to the DOM.

 

The history of the <script> tag

As the browser is constructing the DOM, if it comes across a <script>...</script> tag in the HTML, it must execute it right away. If the script is external, it has to download the script first.

Back in the old days, in order to execute a script, parsing had to be paused. It would only start up again after the JavaScript engine had executed code from a script.

Why did the parsing have to stop? Well, scripts can change both the HTML and its product―the DOM. Scripts can change the DOM structure by adding nodes with document.createElement(). To change the HTML, scripts can add content with the notorious document.write() function. It’s notorious because it can change the HTML in ways that can affect further parsing. For example, the function could insert an opening comment tag making the rest of the HTML invalid.

Scripts can also query something about the DOM, and if that happens while the DOM is still being constructed, it could return unexpected results.

document.write() is a legacy function that can break your page in unexpected ways and you shouldn’t use it, even though browsers still support it. For these reasons, browsers have developed sophisticated techniques to get around the performance issues caused by script blocking that I will explain shortly.

What about CSS?

JavaScript blocks parsing because it can modify the document. CSS can’t modify the document, so it seems like there is no reason for it to block parsing, right?

However, what if a script asks for style information that hasn’t been parsed yet? The browser doesn’t know what the script is about to execute—it may ask for something like the DOM node’s background-color which depends on the style sheet, or it may expect to access the CSSOM directly.

Because of this, CSS may block parsing depending on the order of external style sheets and scripts in the document. If there are external style sheets placed before scripts in the document, the construction of DOM and CSSOM objects can interfere with each other. When the parser gets to a script tag, DOM construction cannot proceed until the JavaScript finishes executing, and the JavaScript cannot be executed until the CSS is downloaded, parsed, and the CSSOM is available.

Another thing to keep in mind is that even if the CSS doesn’t block DOM construction, it blocks rendering. The browser won’t display anything until it has both the DOM and the CSSOM. This is because pages without CSS are often unusable. If a browser showed you a messy page without CSS, then a few moments later snapped into a styled page, the shifting content and sudden visual changes would make a turbulent user experience.

See the Pen Flash of Unstyled Content by Milica (@micikato) on CodePen.

That poor user experience has a name – Flash of Unstyled Content or FOUC

To get around these issues, you should aim to deliver the CSS as soon as possible. Recall the popular “styles at the top, scripts at the bottom” best practice? Now you know why it was there!

Back to the future – speculative parsing

Pausing the parser whenever a script is encountered means that every script you load delays the discovery of the rest of the resources that were linked in the HTML.

If you have a few scripts and images to load, for example–

<script src="slider.js"></script> <script src="animate.js"></script> <script src="cookie.js"></script> <img src="slide1.png"> <img src="slide2.png">

–the process used to go like this:

 

That changed around 2008 when IE introduced something they called “the lookahead downloader”. It was a way to keep downloading the files that were needed while the synchronous script was being executed. Firefox, Chrome and Safari soon followed, and today most browsers use this technique under different names. Chrome and Safari have “the preload scanner” and Firefox – the speculative parser.

The idea is: even though it’s not safe to build the DOM while executing a script, you can still parse the HTML to see what other resources need to be retrieved. Discovered files are added to a list and start downloading in the background on parallel connections. By the time the script finishes executing, the files may have already been downloaded.

The waterfall chart for the example above now looks more like this:

The download requests triggered this way are called “speculative” because it is still possible that the script could change the HTML structure (remember document.write ?), resulting in wasted guesswork. While this is possible, it is not common, and that’s why speculative parsing still gives big performance improvements.

While other browsers only preload linked resources this way, in Firefox the HTML parser also runs the DOM tree construction algorithm speculatively. The upside is that when a speculation succeeds, there’s no need to re-parse a part of the file to actually compose the DOM. The downside is that there’s more work lost if and when the speculation fails.

(Pre)loading stuff

This manner of resource loading delivers a significant performance boost, and you don’t need to do anything special to take advantage of it. However, as a web developer, knowing how speculative parsing works can help you get the most out of it.

The set of things that can be preloaded varies between browsers. All major browsers preload:

  • scripts
  • external CSS
  • and images from the <img> tag

Firefox also preloads the poster attribute of video elements, while Chrome and Safari preload @import rules from inlined styles.

There are limits to how many files a browser can download in parallel. The limits vary between browsers and depend on many factors, like whether you’re downloading all files from one or from several different servers and whether you are using HTTP/1.1 or HTTP/2 protocol. To render the page as quickly as possible, browsers optimize downloads by assigning priority to each file. To figure out these priorities, they follow complex schemes based on resource type, position in the markup, and progress of the page rendering.

While doing speculative parsing, the browser does not execute inline JavaScript blocks. This means that it won’t discover any script-injected resources, and those will likely be last in line in the fetching queue.

var script = document.createElement('script'); script.src = "//somehost.com/widget.js"; document.getElementsByTagName('head')[0].appendChild(script);

You should make it easy for the browser to access important resources as soon as possible. You can either put them in HTML tags or include the loading script inline and early in the document. However, sometimes you want some resources to load later because they are less important. In that case, you can hide them from the speculative parser by loading them with JavaScript late in the document.

You can also check out this MDN guide on how to optimize your pages for speculative parsing.

defer and async

Still, synchronous scripts blocking the parser remains an issue. And not all scripts are equally important for the user experience, such as those for tracking and analytics. Solution? Make it possible to load these less important scripts asynchronously.

The defer and async attributes were introduced to give developers a way to tell the browser which scripts to handle asynchronously.

Both of these attributes tell the browser that it may go on parsing the HTML while loading the script “in background”, and then execute the script after it loads. This way, script downloads don’t block DOM construction and page rendering. Result: the user can see the page before all scripts have finished loading.

The difference between defer and async is which moment they start executing the scripts.

defer was introduced before async. Its execution starts after parsing is completely finished, but before the DOMContentLoaded event. It guarantees scripts will be executed in the order they appear in the HTML and will not block the parser.

async scripts execute at the first opportunity after they finish downloading and before the window’s load event. This means it’s possible (and likely) that async scripts are not executed in the order in which they appear in the HTML. It also means they can interrupt DOM building.

Wherever they are specified, async scripts load at a low priority. They often load after all other scripts, without blocking DOM building. However, if an async script finishes downloading sooner, its execution can block DOM building and all synchronous scripts that finish downloading afterwards.

Note: Attributes async and defer work only for external scripts. They are ignored if there’s no src.

preload

async and defer are great if you want to put off handling some scripts, but what about stuff on your web page that’s critical for user experience? Speculative parsers are handy, but they preload only a handful of resource types and follow their own logic. The general goal is to deliver CSS first because it blocks rendering. Synchronous scripts will always have higher priority than asynchronous. Images visible within the viewport should be downloaded before those below the fold. And there are also fonts, videos, SVGs… In short – it’s complicated.

As an author, you know which resources are the most important for rendering your page. Some of them are often buried in CSS or scripts and it can take the browser quite a while before it even discovers them. For those important resources you can now use <link rel="preload"> to communicate to the browser that you want to load them as soon as possible.

All you need to write is:

<link rel="preload" href="very_important.js" as="script">

You can link pretty much anything and the as attribute tells the browser what it will be downloading. Some of the possible values are:

  • script
  • style
  • image
  • font
  • audio
  • video

You can check out the rest of the content types on MDN.

Fonts are probably the most important thing that gets hidden in the CSS. They are critical for rendering the text on the page, but they don’t get loaded until browser is sure that they are going to be used. That check happens only after CSS has been parsed, and applied, and the browser has matched CSS rules to the DOM nodes. This happens fairly late in the page loading process and it often results in an unnecessary delay in text rendering. You can avoid it by using the preload attribute when you link fonts.

One thing to pay attention to when preloading fonts is that you also have to set the crossorigin attribute even if the font is on the same domain:

<link rel="preload" href="font.woff" as="font" crossorigin>

The preload feature has limited support at the moment as the browsers are still rolling it out, but you can check the progress here.

Conclusion

Browsers are complex beasts that have been evolving since the 90s. We’ve covered some of the quirks from that legacy and some of the newest standards in web development. Writing your code with these guidelines will help you pick the best strategies for delivering a smooth browsing experience.

If you’re excited to learn more about how browsers work here are some other Hacks posts you should check out:

Quantum Up Close: What is a browser engine?
Inside a super fast CSS engine: Quantum CSS (aka Stylo)

Categorieën: Mozilla-nl planet

Public Event: The Fate of Net Neutrality in the U.S.

Mozilla Blog - to, 14/09/2017 - 15:19
Mozilla is hosting a free panel at the Internet Archive in San Francisco on Monday, September 18. Hear top experts discuss why net neutrality matters and what we can do to protect it

 

Net neutrality is under siege.

Despite protests from millions of Americans, FCC Chairman Ajit Pai is moving forward with plans to dismantle hard-won open internet protections.

“Abandoning these core protections will hurt consumers and small businesses alike,” Mozilla’s Heather West penned in an open letter to Pai earlier this week, during Pai’s visit to San Francisco.

The FCC may vote to gut net neutrality as early as October. What does this mean for the future of the internet?

Join Mozilla and the nation’s leading net neutrality experts at a free, public event on September 18 to discuss just this. We will gather at the Internet Archive to discuss why net neutrality matters to a healthy internet — and what can be done to protect it.

RSVP: The Battle to Save Net Neutrality

Net neutrality is under siege. Mozilla is hosting a public panel in San Francisco to explore what’s ahead

<WHAT>

The Battle to Save Net Neutrality, a reception and discussion in downtown San Francisco. Register for free tickets

<WHO>

Mozilla Tech Policy Fellow and former FCC Counselor Gigi Sohn will moderate a conversation with the nation’s leading experts on net neutrality, including Mozilla’s Chief Legal and Business Officer, Denelle Dixon, and:

Tom Wheeler, Former FCC Chairman who served under President Obama and was architect of the 2015 net neutrality rules

Representative Ro Khanna, (D-California), who represents California’s 17th congressional district in the heart of Silicon Valley

Amy Aniobi, Supervising Producer of HBO’s “Insecure”

Luisa Leschin, Co-Executive Producer/Head Writer of Amazon’s “Just Add Magic”

Malkia Cyril, Executive Director of the Center for Media Justice

and Dane Jasper, CEO and Co-Founder of Sonic.

<WHEN>

Monday, September 18, 2017 from 6 p.m. to 9 p.m. PT

<WHERE>

The Internet Archive, 300 Funston Avenue San Francisco, CA 94118

RSVP: The Battle to Save Net Neutrality

The post Public Event: The Fate of Net Neutrality in the U.S. appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Public Event: The Fate of Net Neutrality in the U.S.

Mozilla planet - to, 14/09/2017 - 15:19
Mozilla is hosting a free panel at the Internet Archive in San Francisco on Monday, September 18. Hear top experts discuss why net neutrality matters and what we can do to protect it

 

Net neutrality is under siege.

Despite protests from millions of Americans, FCC Chairman Ajit Pai is moving forward with plans to dismantle hard-won open internet protections.

“Abandoning these core protections will hurt consumers and small businesses alike,” Mozilla’s Heather West penned in an open letter to Pai earlier this week, during Pai’s visit to San Francisco.

The FCC may vote to gut net neutrality as early as October. What does this mean for the future of the internet?

Join Mozilla and the nation’s leading net neutrality experts at a free, public event on September 18 to discuss just this. We will gather at the Internet Archive to discuss why net neutrality matters to a healthy internet — and what can be done to protect it.

RSVP: The Battle to Save Net Neutrality

Net neutrality is under siege. Mozilla is hosting a public panel in San Francisco to explore what’s ahead

<WHAT>

The Battle to Save Net Neutrality, a reception and discussion in downtown San Francisco. Register for free tickets

<WHO>

Mozilla Tech Policy Fellow and former FCC Counselor Gigi Sohn will moderate a conversation with the nation’s leading experts on net neutrality, including Mozilla’s Chief Legal and Business Officer, Denelle Dixon, and:

Tom Wheeler, Former FCC Chairman who served under President Obama and was architect of the 2015 net neutrality rules

Representative Ro Khanna, (D-California), who represents California’s 17th congressional district in the heart of Silicon Valley

Amy Aniobi, Supervising Producer of HBO’s “Insecure”

Luisa Leschin, Co-Executive Producer/Head Writer of Amazon’s “Just Add Magic”

Malkia Cyril, Executive Director of the Center for Media Justice

and Dane Jasper, CEO and Co-Founder of Sonic.

<WHEN>

Monday, September 18, 2017 from 6 p.m. to 9 p.m. PT

<WHERE>

The Internet Archive, 300 Funston Avenue San Francisco, CA 94118

RSVP: The Battle to Save Net Neutrality

The post Public Event: The Fate of Net Neutrality in the U.S. appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mike Taylor: hyperlinks in buttons are probably not a great idea

Mozilla planet - to, 14/09/2017 - 07:00

Over in web-bug #9726, there's an interesting issue reported against glitch.com (which is already fixed because those peeps are classy):

Basically, they had an HTML <button> that when clicked would display:block a descendent <dialog> element that contained some hyperlinks to help you create a new project.

screenshot of glitch.com button

The simplest test case:

<button> <a href="https://example.com">do cool thing</a> </button>

Problem is, clicking on an anchor with an href inside of a button does nothing in Firefox (and Opera Presto, which only 90s kids remember).

What the frig, web browsers.

But it turns out HTML is explicit on the subject, as it often is, stating that a button's content model must not have an interactive content descendant.

(and <a href> is totally, like, interactive content, itsho*)

Soooo, probably not a good idea to follow this pattern. And who knows what it means for accessibility.

The fix for glitch is simple: just make the <dialog> a sibling, and hide and show it the same way.

* in the spec's humble opinion

Categorieën: Mozilla-nl planet

Robert O'Callahan: Some Opinions On The History Of Web Audio

Mozilla planet - to, 14/09/2017 - 06:47

People complain that Web Audio provides implementations of numerous canned processing features, but they very often don't do exactly what you want, and working around those limitations by writing your own audio processing code in JS is difficult or impossible.

This was an obvious pitfall from the moment the Web Audio API was proposed by Chris Rogers (at Google, at that time). I personally fought pretty hard in the Audio WG for an API that would be based on JS audio processing (with allowance for popular effects to be replaced with browser-implemented modules). I invested enough to write a draft spec for my alternative and implement a lot of that spec in Firefox, including Worker-based JS sample processing.

My efforts went nowhere for several reasons. My views on making JS sample manipulation a priority were not shared by the Audio WG. Here's my very first response to Chris Rogers' reveal of the Web Audio draft; you can read the resulting discussion there. The main arguments against prioritizing JS sample processing were that JS sample manipulation would be too slow, and JS GC (or other non-realtime behaviour) would make audio too glitchy. Furthermore, audio professionals like Chris Rogers assured me they had identified a set of primitives that would suffice for most use cases. Since most of the Audio WG were audio professionals and I wasn't, I didn't have much defense against "audio professionals say..." arguments.

The Web Audio API proceeded mostly unchanged because there wasn't anyone other than me trying to make significant changes. After an initial burst of interest Apple's WG participation declined dramatically, perhaps because they were getting Chris Rogers' Webkit implementation "for free" and had nothing to gain from further discussion. I begged Microsoft people to get involved but they never did; in this and other areas they were (are?) apparently content for Mozilla and Google to spend energy to thrash out a decent spec that they later implement.

However, the main reason that Web Audio was eventually standardized without major changes is because Google and Apple shipped it long before the spec was done. They shipped it with a "webkit" prefix, but they evangelized it to developers who of course started using it, and so pretty soon Mozilla had to cave.

Ironically, soon after Web Audio won, the "extensible Web" become a hot buzzword. Web Audio had a TAG review at which it was clear Web Audio was pretty much the antithesis of "extensible Web", but by then it was too late to do anything about it.

What could I have done better? I probably should have reduced the scope of my spec proposal to exclude MediaStream/HTMLMediaElement integration. But I don't think that, or anything else I can think of, would have changed the outcome.

Categorieën: Mozilla-nl planet

Mozilla Security Blog: Verified cryptography for Firefox 57

Mozilla planet - wo, 13/09/2017 - 22:56

Traditionally, software is produced in this way: write some code, maybe do some code review, run unit-tests, and then hope it is correct. Hard experience shows that it is very hard for programmers to write bug-free software. These bugs are sometimes caught in manual testing, but many bugs still are exposed to users, and then must be fixed in patches or subsequent versions. This works for most software, but it’s not a great way to write cryptographic software; users expect and deserve assurances that the code providing security and privacy is well written and bug free.

Even innocuous looking bugs in cryptographic primitives can break the security properties of the overall system and threaten user security. Unfortunately, such bugs aren’t uncommon. In just the last year, popular cryptographic libraries have issued dozens of CVEs for bugs in their core cryptographic primitives or for incorrect use of those primitives. These bugs include many memory safety errors, some side-channels leaks, and a few correctness errors, for example, in bignum arithmetic computations… So what can we do?

Fortunately, recent advances in formal verification allow us to significantly improve the situation by building high assurance implementations of cryptographic algorithms. These implementations are still written by hand, but they can be automatically analyzed at compile time to ensure that they are free of broad classes of bugs. The result is that we can have much higher confidence that our implementation is correct and that it respects secure programming rules that would usually be very difficult to enforce by hand.

This is a very exciting development and Mozilla has partnered with INRIA and Project Everest  (Microsoft Research, CMU, INRIA) to bring components from their formally verified HACL* cryptographic library into NSS, the security engine which powers Firefox. We believe that we are the first major Web browser to have formally verified cryptographic primitives.

The first result of this collaboration, an implementation of the Curve25519 key establishment algorithm (RFC7748), has just landed in Firefox Nightly. Curve25519 is widely used for key-exchange in TLS, and was recently standardized by the IETF.  As an additional bonus, besides being formally verified, the HACL* Curve25519 implementation is also almost 20% faster on 64 bit platforms than the existing NSS implementation (19500 scalar multiplications per second instead of 15100) which represents an improvement in both security and performance to our users. We expect to ship this new code as part as our November Firefox 57 release.

Over the next few months, we will be working to incorporate other HACL* algorithms into NSS, and will also have more to say about the details of how the HACL* verification works and how it gets integrated into NSS.

Benjamin Beurdouche, Franziskus Kiefer & Tim Taubert

The post Verified cryptography for Firefox 57 appeared first on Mozilla Security Blog.

Categorieën: Mozilla-nl planet

Dave Townsend: How do you become a Firefox peer? The answer may surprise you!

Mozilla planet - wo, 13/09/2017 - 20:02

So you want to know how someone becomes a peer? Surprisingly the answer is pretty unclear. There is no formal process for peer status, at least for Firefox and Toolkit. I haven’t spotted one for other modules either. What has generally happened in the past is that from time to time someone will come along and say, “Oh hey, shouldn’t X be a peer by now?” to which I will say “Uhhh maybe! Let me go talk to some of the other peers that they have worked with”. After that magic happens and I go and update the stupid wiki pages, write a blog post and mail the new peers to congratulate them.

I’d like to formalise this a little bit and have an actual process that new peers can see and follow along to understand where they are. I’d like feedback on this idea, it’s just a straw-man at this point. With that I give you … THE ROAD TO PEERSHIP (cue dramatic music).

  1. Intro patch author. You write basic patches, request review and get them landed. You might have level 1 commit access, probably not level 3 yet though.
  2. Senior patch author. You are writing really good patches now. Not just simple stuff. Patches that touch multiple files maybe even multiple areas of the product. Chances are you have level 3 commit access. Reviewers rarely find significant issues with your work (though it can still happen). Attention to details like maintainability and efficiency are important. If your patches are routinely getting backed out or failing tests then you’re not here yet.
  3. Intro reviewer. Before being made a full peer you should start reviewing simple patches. Either by being the sole reviewer for a patch written by a peer or doing an initial review before a peer does a final sign-off. Again paying attention to maintainability and efficiency are important. As is being clear and polite in your instructions to the patch author as well as being open to discussion where disagreements happen.
  4. Full peer. You, your manager or a peer reach out to me showing me cases where you’ve completed the previous levels. I double-check with a couple of peers you’ve work with. Congratulations, you made it! Follow-up on review requests promptly. Be courteous. Re-direct reviews that are outside your area of expertise.

Does this sound like a reasonable path? What criteria am I missing? I’m not yet sure what length of time we would expect each step to take but I am imagine that more senior contributors could skip straight to step 2.

Feedback welcome here or in private by email.

Categorieën: Mozilla-nl planet

Pages