Mozilla Nederland LogoDe Nederlandse

Firefox 36 zum Download – Mozilla-Browser im Praxistest - DIE WELT

Nieuws verzameld via Google - wo, 25/02/2015 - 16:51


Firefox 36 zum Download – Mozilla-Browser im Praxistest
Wie Mozilla-Entwickler Patrick McManus in seinem privaten Blog erklärt, braucht es aber noch ein paar Wochen, bis wirklich alle Details des neuen Standards auch in Firefox landen. Einige Elemente von HTTP/2 brachte Mozilla zudem schon im Vorgänger ...
Mozilla veröffentlicht Firefox 36Futurezone
Firefox 36: Download und Praxis-TestCOMPUTER BILD
Mozilla: Firefox 36 kann HTTP/
alle 19 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Kim Moir: Release Engineering special issue now available

Mozilla planet - wo, 25/02/2015 - 16:26
The release engineering special issue of IEEE software was published yesterday. (Download pdf here).  This issue focuses on the current state of release engineering, from both an industry and research perspective. Lots of exciting work happening in this field!

I'm interviewed in the roundtable article on the future of release engineering, along with Chuck Rossi of Facebook and Boris Debic of Google.  Interesting discussions on the current state of release engineering at organizations that scale large number of builds and tests, and release frequently.  As well,  the challenges with mobile releases versus web deployments are discussed. And finally, a discussion of how to find good release engineers, and what the future may hold.

Thanks to the other guest editors on this issue -  Stephany Bellomo, Tamara Marshall-Klein, Bram Adams, Foutse Khomh and Christian Bird - for all their hard work that make this happen!

As an aside, when I opened the issue, the image on the front cover made me laugh.  It's reminiscent of the cover on a mid-century science fiction anthology.  I showed Mr. Releng and he said "Robot birds? That is EXACTLY how I pictured working in releng."  Maybe it's meant to represent that we let software fly free.  In any case, I must go back to tending the flock of robotic avian overlords.
Categorieën: Mozilla-nl planet

David Humphrey: Repeating old mistakes

Mozilla planet - wo, 25/02/2015 - 15:51

This morning I've been reading various posts about the difficulty ahead for the Pointer Events spec, namely, Apple's (and by extension Google's) unwillingness to implement it. I'd encourage you to read both pieces, and whatever else gets written on this in the coming days.

I want to comment not on the spec as such, but on the process on display here, and the effect it has on the growth and development of the web. There was a time when the web's course was plotted by a single vendor (at the time, Microsoft), and decisions about what was and wasn't headed for the web got made by employees of that corporation. This story is so often retold that I won't pretend you need to read it again.

And yet here we are in 2015, where the web on mobile, and therefore the web in general, is effectively in the control of one vendor; a vendor who, despite its unmatched leadership and excellence in creating beautiful hardware, has shown none of the same abilities in its stewardship and development of the web.

If the only way to improve and innovate the web is to become an employee of Apple Inc., the web is in real danger.

I think that the larger web development community has become lax in its care for the platform on which it relies. While I agree with the trend toward writing JS to supplement and extend the browser, I think that it also tends to lull developers into thinking that their job is done. We can't simply write code on the platform, and neglect writing code for the platform. To ignore the latter, to neglect the very foundations of our work, is to set ourselves up for a time when everything collapses into the sand.

We need more of our developer talent and resources going into the web platform. We need more of our web developers to drop down a level in the stack and put their attention on the platform. We need more people in our community with the skills and resources to design, implement, and test new specs. We need to ensure that the web isn't something we simply use, but something we are active in maintaining and building.

Many web developers that I talk to don't think about the issues of the "web as platform" as being their problem. "If only Vendor X would fix their bugs or implement Spec Y--we'll have to wait and see." There is too often a view that the web is the problem of a small number of vendors, and that we're simply powerless to do anything other than complain.

In actual fact there is a lot that one can do even without the blessing or permission of the browser vendors. Because so much of the web is still open, and the code freely available, we can and should be experimenting and innovating as much as possible. While there's no guarantee that code you write will be landed and shipped, there is still a great deal of value in writing patches instead of just angry tweets: it is necessary to change peoples' minds about what the web is and what it can do, and there is no better way that with working code.

I would encourage the millions of web developers who are putting time into technologies and products on top of the web to also consider investing some time in the web itself. Write a patch, make some builds, post them somewhere, and blog about the results. Let data be the lever you use to shift the conversation. People will tell you that something isn't possible, or that one spec is better than another. Nothing will do more to convince people than a working build that proves the opposite.

There's no question that working on the web platform is harder than writing things for the web. The code is bigger, older, more complicated, and requires different tooling and knowledge. However, it's not impossible. I've been doing it for years with undergraduate students at Seneca, and if 3rd and 4th years can tackle it, so too can the millions of web developers who are betting their careers and companies on the web.

Having lived through and participated in every stage of the web's development, it's frustrating to see that we're repeating mistakes of the past, and allowing large vendors to control too great a stake of the web. The web is too important for that, and it needs the attention and care of a global community. There's something you can do, something I can do, and we need to get busy doing it.

Categorieën: Mozilla-nl planet

Mozilla Firefox 36 is second major browser to bring HTTP/2 - Inquirer

Nieuws verzameld via Google - wo, 25/02/2015 - 15:40


Mozilla Firefox 36 is second major browser to bring HTTP/2
MOZILLA HAS PROMOTED Firefox 36 to full stable status, bringing a number of new treats for users. Nightly editions are currently hovering at Version 39, but the vast majority of us will now be enjoying the stable, safe world of 36 which has plenty of ...
Mozilla Firefox 36 Adds HTTP/2 Support, Pinned Tile Syncing, and MoreNDTV
Mozilla Firefox 36 is hereAfterDawn
Firefox 36 adds HTTP2 support, pinned tile syncingIndia Today
PC Advisor
alle 16 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla-Updates Firefox 36 beseitigt 18 Sicherheitslücken - PC-Welt

Nieuws verzameld via Google - wo, 25/02/2015 - 15:34


Mozilla-Updates Firefox 36 beseitigt 18 Sicherheitslücken
Mit der neuen Firefox-Version 36.0 unterstützt Mozilla nun auch den kommenden Standard HTTP/2 für schnellere Datenübertragung. Entfallen ist hingegen die Unterstützung für das schon lange als nicht mehr sicher geltende Verschlüsselungsverfahren RC4 ...
Firefox 36: Download und Praxis-TestCOMPUTER BILD
Mozilla veröffentlicht Firefox 36Futurezone
Mozilla: Firefox 36 kann HTTP/ -Macwelt
alle 16 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Air Mozilla: Bugzilla Development Meeting

Mozilla planet - wo, 25/02/2015 - 15:00

Bugzilla Development Meeting Help define, plan, design, and implement Bugzilla's future!

Categorieën: Mozilla-nl planet

Mozilla voorziet Firefox 36 al van ondersteuning voor http 2.0 - Techzine ... - Zoeterwoude Online

Nieuws verzameld via Google - wo, 25/02/2015 - 14:01

Zoeterwoude Online

Mozilla voorziet Firefox 36 al van ondersteuning voor http 2.0 - Techzine ...
Zoeterwoude Online
Mozilla heeft bekendgemaakt dat de nieuwste versie van Firefox, Firefox 36, al volledige ondersteuning biedt voor de nieuwe versie van het http-protocol, http 2.0. Daarmee is het de eerste browser die de nieuwe versie al ondersteund. Microsoft zal ...

Categorieën: Mozilla-nl planet

Christian Heilmann: Simple things: Storing a list of booleans as a single number

Mozilla planet - wo, 25/02/2015 - 13:10

This blog started as a scratch pad of simple solutions to problems I encountered. So why not go back to basics?

Yesterday I was asked by someone if there is a possibility to store the state of a collection of checkboxes in a single value. The simplest way I could think of doing this is by using binary conversion.

Tron binary

You can see the result of my approach in this JSBin:

Storing a list of booleans as a single number

What’s going on here? The state of a checkbox is a Boolean, meaning it is checked or unchecked. This could be true or false, or, as JavaScript is a lenient language, 1 or 0. That’s why we can loop over all the checkboxes and assemble a string of their state that compromises of zeros and ones:

var inputs = document.querySelectorAll('input'); var all = inputs.length; for (var i = 0; i < all; i++){ state += inputs[i].checked ? '1' : '0'; }

This results in a string like 1001010101. This could be our value to store, but looks pretty silly and with 50 or more checkboxes becomes very long to store, for example, as a URL parameter string.

That’s why we can use parseInt() to convert this binary number into a decimal one. That’s what the second parameter in parseInt() is for – not only to please Douglas Crockford and JSLint (as it is preset to decimal – 10 – people keep omitting it). The counterpart of parseInt() in this case is toString() and that one also takes an optional parameter that is the radix of the number system you convert from. That way you can convert this state back and forth:

x = parseInt('1001010101',2); // x -> 579 x.toString(2); // "1001010101"

Once converted, you turn it back into a string and loop over the values to set the checked state of the checkboxes accordingly.

A small niggle: leading zeroes don’t work

One little problem here is that if the state results in a string with leading zeroes, you get a wrong result back as toString() doesn’t create them (there is no knowing how long the string needs to be, all it does is convert the number).

x = parseInt('00001010101',2); x.toString(2); "1010101"

You can avoid this is in two ways: either pad the string by always starting it with a 1 or by reversing the string and looping over the checkboxes in reverse. In the earlier example I did the padding part, in this JSBin you can see the reversing trick:

Storing a list of booleans as a single number (reverse)r

Personally, I like the reversing method better, it just feels cleaner. It does rely a lot on falsy/truthy though as the size of the resulting arrays differs.


In any case, this only works when the amount of checkboxes doesn’t change in between the storing and re-storing, but that’s another issue.

As pointed out by Matthias Reuter on Twitter this is also limited to 52 checkboxes, so if you need more, this is not the solution.

Categorieën: Mozilla-nl planet

Mozilla voorziet Firefox 36 al van ondersteuning voor http 2.0 - Techzine

Nieuws verzameld via Google - wo, 25/02/2015 - 12:02


Mozilla voorziet Firefox 36 al van ondersteuning voor http 2.0
Mozilla heeft bekendgemaakt dat de nieuwste versie van Firefox, Firefox 36, al volledige ondersteuning biedt voor de nieuwe versie van het http-protocol, http 2.0. Daarmee is het de eerste browser die de nieuwe versie al ondersteund. Microsoft zal ...

en meer »
Categorieën: Mozilla-nl planet

Mozilla Firefox 36 Adds HTTP/2 Support, Pinned Tile Syncing, and More - NDTV

Nieuws verzameld via Google - wo, 25/02/2015 - 09:24


Mozilla Firefox 36 Adds HTTP/2 Support, Pinned Tile Syncing, and More
It is worth noting that according to the latest data from National Vulnerability Database (NVD) Mozilla Firefox, despite the regular monthly updates, still comes in top three browsers when it comes to vulnerability risk. Microsoft's Internet Explorer ...
Mozilla Firefox 36 is hereAfterDawn
Mozilla Firefox v35 review: Now with speed to match the incredible range of ...PC Advisor
Firefox 36 Gains HTTP/2 Support, Fixes Critical VulnerabilitieseWeek
Ordoh -Ghacks Technology News
alle 11 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Karl Dubost: Web Compatibility Summit 2015

Mozilla planet - wo, 25/02/2015 - 08:49

The Web Compatibility Summit was organized in Mountain View (USA) on February 18, 2015. I summarize the talks that we have been given during the day. I encourage to continue the discussion on

If you want to look at the talks:

Intro to Web Compatibility

Mike Taylor (Mozilla) has introduced the Web Compatibility topic. The Web being a giant set of new and old things. We need to care for a lot of different things sometimes incompatible. Features will disappear, new features emerge, but you still need to make the Web usable for all users whatever their devices, countries, browsers.

Mike reminded us of the evolution of User Agent strings and how they grew with more and more terms. The reason is that the User Agent string became an ID for having the content rendered. So any new User Agent is trying to get access to the Web site content by not being filtered out.

Then he went through some traditional bugs (horrors) be JavaScript, CSS, etc. has been created to give a space for users to report Web Compatibility issues they have on a Web site. But the space is useful for browser vendors, it is relatively easy to tie the bug reporting of browsers directly to

Discussions Beyond Vendor Prefixes

Jacob Rossi (Microsoft) introducing the purpose and the caveats of vendor prefixes. Vendor prefixes have been created for helping people to test the new API safely without breaking other browser vendors. It shields against collision with other implementations, but it also creates Web Compatibility issues. The main issue being that Web developers use these on production sites and on articles, examples, documentations.

Microsoft tried to contact Web sites with bogus code examples and articles. They also created new content with the correct way of writing things. The results were promising for the FullScreen API but the experiment was less successful for other properties. Basically, fix the problem before it happens.

So how do we keep the possibility to have a large surface for feedback and at the same time limit the usage so that it doesn't become a requirement to use a specific browser. The first idea to put new features behind flags. Then the issue becomes that the feedback is shallow. So Jacob is floating the idea of an API trial, where someone would register to get a key for enabling a feature. It would help the developer to test and at the same time, make it possible to set deadlines for the test.

It would probably require a community effort to set up. It has a cost. Where this discussion should happen? It could be a community group at W3C. Not all APIs need to be used at scale for having a real sense of feedback. IndexedDB, appcache would have been good candidates for this thing. If there was a community site, it would be yet another good way to build awareness about the features.

A good discussion has been recorded on the video.

How CSS is being used in the wild

Alex McPherson (QuickLeft) introduced the wonderful work he did about CSS properties on the Web as they are currently (2014) used by Web devs. The report was initially done for understanding what QuickLeft should recommend in terms of technology when they tackle a new project. For this report, they scrap the CSS of the top 15000 Web sites and checking the frequency, values, doing graph distributions. The purpose was not to be an exact academic research. So they are definitely caveats in the study, but it gives a rough overview of what is done. The data were collected through a series of HTTP requests. One of the consequences is that we probably miss everything which is set through JavaScript. A better study would include a browser crawler handling the DOM. There are probably variations with regards to the user agent too.

It would be good to have a temporal view of these data and repeat the study continuously. So we can identify how the Web is evolving. Browser vendors seems to have more resources to do this type of studies than a single person in an agency.

Engaging with Web Developers for Site Outreach

Colleen Williams (Microsoft) talked about what it takes to do daily Web Compatibility work. Contacting Web developers is really about trying to convince people that there could be a benefit for them to implement with a wider scope of platforms.

Social networking and using linkedin are very useful to be to contact the right persons in companies. It's very important to be very upfront and to tell developers:

  • Who we are?
  • What we are doing?
  • Why are we contacting them?

Microsoft IE team has a list of top sites and systematically test every new version of IE into these sites. It's an opportunity for contacting Web sites which are broken. When contacting Web sites, it's important to understand that you are building a relationship on a longterm. You might have to recontact the people working for this company and/or Web sites in a couple of months. It's important to nurture a respectful and interesting relation with the Web developers. You can't say "your code sucks". It's important to talk to technical people directly.

Do not share your contact list with business departements. We need a level of privacy with the persons we are contacting. They keep contact with you because they are eager to help of solving technical issues. Empathy in the relationship goes a long way in terms of creating a mutual trust. The relationship should always go both ways.

Having a part or the full solution for solving the issue will help you a lot in getting the issue fixed. It's better to show code and help the developer demonstrate what could work.

Companies user support channels are usually not the best tool, unfortunately, for reaching the company. There's a difference in between having a contact and having the right contact.

Web Compatibility Data: A Shared Resource

Finally Justin Crawford (Mozilla) introduced the project about having a better set of site compatibility data. But I encouraged you to read his own summary on his blog.


We discuss at the end of the day using an unconference format. Alexa Roman moderated the session. We discussed about User Agent Sniffing and the format of the UA string, console.log for reporting Web Compatibility issues, API trials, documentation, etc.

More information

You can contact and interact with us: IRC: #webcompat Discuss issues on Twitter: @webcompat Report bug:

Categorieën: Mozilla-nl planet

Ook Deutsche Telekom en Mozilla komen met veilige smartphone - Connexie B2B

Nieuws verzameld via Google - wo, 25/02/2015 - 08:04

Ook Deutsche Telekom en Mozilla komen met veilige smartphone
Connexie B2B
Via The Wall Street Journal komt het bericht dat Deutsche Telekom, eigenaar van onder andere T-Mobile, en Mozilla, bekend van Firefox en de mail-applicatie Thunderbird, op de MWC in Barcelona volgende week een extra veilige smartphone gaan ...

Categorieën: Mozilla-nl planet

Planet Mozilla Interns: Michael Sullivan: The x86 Memory Model

Mozilla planet - wo, 25/02/2015 - 05:04

Often I’ve found myself wanting to point someone to a description of the x86’s memory model, but there wasn’t any that quite laid it out the way I wanted. So this is my take on how shared memory works on multiprocessor x86 systems. The guts of this description is adapted/copied from “A Better x86 Memory Model: x86-TSO” by Scott Owens, Susmit Sarkar, and Peter Sewell; this presentation strips away most of the math and presents it in a more operational style. Any mistakes are almost certainly mine and not theirs.

Components of the System:

There is a memory subsystem that supports the following operations: store, load, fence, lock, unlock. The memory subsystem contains the following:

  1. Memory: A map from addresses to values
  2. Write buffers: Per-processor lists of (address, value) pairs; these are pending writes, waiting to be sent to memory
  3. “The Lock”: Which processor holds the lock, or None, if it is not held. Roughly speaking, while the lock is held, only the processor that holds it can perform memory operations.

There is a set of processors that execute instructions in program order, dispatching commands to the memory subsystem when they need to do memory operations. Atomic instructions are implemented by taking “the lock”, doing whatever reads and writes are necessary, and then dropping “the lock”. We abstract away from this.


A processor is “not blocked” if either the lock is unheld or it holds the lock.

Memory System Operation

Processors issue commands to the memory subsystem. The subsystem loops, processing commands; each iteration it can pick the command issued by any of the processors to execute. (Each will only have one.) Some of the commands issued by processors may not be eligible to execute because their preconditions do not hold.

  1. If a processor p wants to read from address a and p is not blocked:
    a. If there are no pending writes to a in p’s write buffer, return the value from memory
    b. If there is a pending write to a in p’s write buffer, return the most recent value in the write buffer
  2. If a processor p wants to write value v to address a, add (a, v) to the back of p’s write buffer
  3. At any time, if a processor p is not blocked, the memory subsystem can remove the oldest entry (a, v) from p’s write buffer and update memory so that a maps to v
  4. If a processor p wants to issue a barrier
    a. If the barrier is an MFENCE, p’s write buffer must be empty
    b. If the barrier is an LFENCE/SFENCE, there are no preconditions; these are no-ops **
  5. If a processor p’s wants to lock the lock, the lock must not be held and p’s write buffer must be empty; the lock is set to be p
  6. If a processor p’s wants to unlock the lock, the lock must held by p and p’s write buffer must be empty; the lock is set to be None

So, the only funny business that can happen is that a load can happen before a prior store to a different location has been flushed from the write buffer into memory. This means that if CPU0 executes “x = 1; r0 = y” and CPU1 executes “y = 1; r1 = x”, with x and y both initially zero, we can get “r0 == r1 == 0″.

The common intuition that atomic instructions act like there is an MFENCE before and after them is basically right; MFENCE requires the write buffer to empty before it can execute and so do lock and unlock.

x86 is a pleasure to compile atomics code for. The “release” and “acquire” operations in the C++11 memory model don’t require any fencing to work. Neither do the notions of “execution order” and “visibility order” in my advisor and my RMC memory model.

** The story about LFENCE/SFENCE is a little complicated. Some sources insist that they actually do things. The Cambridge model models them as no-ops. The guarantees that they are documented to provide are just true all the time, though. I think they are useful when using non-temporal memory accesses (which I’ve never done), but not in general.


Categorieën: Mozilla-nl planet

Mozilla Firefox 36 is here - AfterDawn

Nieuws verzameld via Google - wo, 25/02/2015 - 04:44


Mozilla Firefox 36 is here
Mozilla Firefox 36 is here Mozilla has released Firefox 36 to the public today, giving fans of the browser a stable version while the beta moves to 37 and the nightly alphas move to 39. On the surface, the update is minor but there are some tweaks ...
Mozilla Firefox v35 review: Now with speed to match the incredible range of ...PC Advisor
Firefox 36 Gains HTTP/2 Support, Fixes Critical VulnerabilitieseWeek
Firefox 35.0.1 Now Available for Free Download – Check Out What's NewOrdoh

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

Brad Lassey: Detecting slow add-ons

Mozilla planet - wo, 25/02/2015 - 01:03

As we have been progressing towards a multi-process Firefox we have seen many bugs filed about slowness that after investigation turned out to be related to add-ons interacting poorly with the way multi-process Firefox now operates. This doesn’t necessarily mean that the add-on author has done anything wrong. Instead code that worked fine with single-process Firefox now behaves differently as seemingly innocuous calls can cause synchronous calls from one process to the other. See my previous post on unsafe CPOW usage as example of how this can occur.

This motivated us to start trying to measure add-ons and detect when they may be slowing down a user’s browser such that we can notify the user. As luck would have it, we recently made a key change that makes all of this possible. In bug 990729 we introduced “compartment-per-add-on” (though there may be multiple compartments per add-on), such that add-on code and Firefox’s js code run in separate compartments. This allowed us to then track the amount of time we running a particular add-on by measuring the time spent in the compartments associated with that add-on. We did that in bug 1096666.

That has allowed us to start notifying users when we notice add-ons running slowly on their system. The first cut of that recently landed from bug 1071880, but a more polished UX is being tracked by bug 1124073. If you’re using Nightly and testing e10s (multi-process Firefox) and are notified of a slow add-on, please try disabling it to see if it improves how Firefox is running and report your results to You can see the raw data of what we are measuring by having a look at about:compartments. Also note that all of this is experimental. In fact, we’re already rewriting how we measure the time we spend in compartments in bug 674779.

Categorieën: Mozilla-nl planet

Rizky Ariestiyansyah: Undo git rm -r command in github

Mozilla planet - wo, 25/02/2015 - 01:00

Well, when I tried to delete remote folder on my github repository the command that I used 100% is wrong, I am using git rm -r folder/ command ;( it also delete the folder in local repo.

Categorieën: Mozilla-nl planet

Armen Zambrano: mozci 0.2.4 released - Support for intermittent oranges + major bug fixes

Mozilla planet - ti, 24/02/2015 - 23:26
Big thanks to vaibhav1994 for his intermittent orange script contribution.

Also thanks to adusca and valeriat for their many contributions in this release.

Release notes The major feature is being able to analyze data about reported intermittent oranges on bugzilla and give the user the ability to trigger jobs to spot where the regression started (

A lot of bug fixed and optimizations. I'm only highligthing some from this list: 0.2.3...0.2.4

Highlighted fixes:
  • Fixed/improved issues with jobs completed today
  • Added builds-4hr support
  • allthethings.json gets clobbered after 24 hours
    • This prevents relying on an old file
  • Drop the need to use --repo-name for all scripts
    • his prevents the user having to add a redundant option
Release notes:
PyPi package:

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Justin Crawford: Report: Web Compatibility Summit

Mozilla planet - ti, 24/02/2015 - 22:48

Last week I spoke at Mozilla’s Compatibility Summit. I spoke about compatibility data. Here are my slides.

Compatibility data…

  • is information curated by web developers about the cross-browser compatibility of the web’s features.
  • documents browser implementation of standards, browser anomalies (both bugs and features), and workarounds for common cross-browser bugs. It theoretically covers hundreds of browser/version combinations, but naturally tends to focus on browsers/versions with the most use.
  • is partly structured (numbers and booleans can answer the question, “does Internet Explorer 10 support input type=email?”) and partly unstructured (numbers and booleans cannot say, “Safari Mobile for iOS applies a default style of opacity: 0.4 to disabled textual <input> elements.”).

Compatibility data changes all the time. As a colleague pointed out last week, “Every six weeks we have all new browsers” — each with an imperfect implementation of web standards, each introducing new incompatibilities into the web.

Web developers are often the first to discover and document cross-browser incompatibilities since their work product is immediately impacted. And they do a pretty good job of sharing compatibility data. But as I said in my talk: Compatibility data is an oral tradition. Web developers gather at the town pump and share secrets for making boxes with borders float in Browser X. Web developers sit at the feet of venerated elders and hear how to make cross-browser compatible CSS transitions. We post our discoveries and solutions in blogs; in answers on StackOverflow; in GitHub repositories. We find answers on old blogs; in countless abandoned PHP forums; on the third page of search results.

There are a small number of truly canonical sources for compatibility data. We surveyed MDN visitors in January and learned that they refer to two sources far more than any others: MDN and MDN has more comprehensive information — more detailed, for more browser versions, accompanied by encyclopedic reference materials. caniuse has a much better interface and integrates with browser market share data. Both have good communities of contributors. Together, they represent the canon of compatibility data.

Respondents to our recent survey said they use the two sites differently: They use caniuse for planning new sites and debugging existing issues, and use MDN for exploring new features and when answering questions that come up when writing code.

On MDN, we’re working on a new database of compatibility data with a read/write API. This project solves some maintenance issues for us, and promises to create more opportunities for web developers to build automation around web compatibility data (for an example of this, see, which scans your CSS for features covered by caniuse and returns a browser coverage report).

Of course the information in MDN and caniuse is only one tool for improving web compatibility, which is why the different perspectives at the Compat Summit were so valuable.


If we think of web compatibility as a set of concentric circles, MDN and caniuse (and the entire, sprawling web compatibility data corpus) occupy a middle ring. In the illustration above, the rings get more diffuse as they get larger, representing the increasing challenge of finding and solving incompatibility as it moves from vendor to web developer to site.

  • By the time most developers encounter cross-browser compatibility issues, those issues have been deployed in browser versions. So browser vendors have a lot of responsibility to make web standards possible; to deploy as few standards-breaking features and bugs as possible. Jacob Rossi from Microsoft invited Compat Summit participants to collaborate on a framework that would allow browser vendors to innovate and push the web forward without creating durable incompatibility issues in deployed websites.
  • When incompatibilities land in browser releases, web developers find them, blog about them, and build their websites around them. At the Compat Summit, Alex McPherson from Quickleft presented his clever work quantifying some of these issues, and I invited all present to start treating compatibility data like an important public resource (as described above).
  • Once cross-browser incompatibilities are discussed in blog posts and deployed on the web, the only way to address incompatibilities is to politely ask web developers to fix them. Mike Taylor and Colleen Williams talked about Mozilla’s and Microsoft’s developer outreach activities — efforts like, “bug reporting for the internet”.

At the end of the Compat Summit, Mike Taylor asked the participants whether we should have another. My answer takes the form of two questions:

  1. Should someone work to keep the importance of cross-browser compatibility visible among browser vendors and web developers?
  2. If we do not, who will?

I think the answer is clear.

Special thanks to Jérémie Patonnier for helping me get up to speed on web compatibility data.

Categorieën: Mozilla-nl planet

Armen Zambrano: Listing builder differences for a buildbot-configs patch improved

Mozilla planet - ti, 24/02/2015 - 22:45
Up until now, we updated the buildbot-configs repository to the "default" branch instead of "production" since we normally write patches against that branch.

However, there is a problem with this, buildbot-configs is always to be on the same branch as buildbotcustom. Otherwise, we can have changes land in one repository which require changes on the other one.

The fix was to simply make sure that both repositories are either on default or their associated production branches.

Besides this fix, I have landed two more changes:

  1. Use the production branches instead of 'default'
    • Use -p
  2. Clobber our whole set up (e.g. ~/.mozilla/releng)
    • Use -c

Here are the two changes:

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet