Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 11 uur 6 min geleden

Gavin Sharp: r=gfritzsche

13 uur 27 min geleden

I’m happy to announce that Georg Fritzsche is now officially a Firefox reviewer.

Georg has been contributing to Firefox for a while now – his contributions started with done some great work on Firefox’s Telemetry system, as well as investigating stability issues in plugins and Firefox itself. He played a crucial role in building the telemetry experiments system, and more recently has become familiar with a few key parts of the Firefox front-end code, including our click to play plugin UI and the upcoming “FHR self support” feature. He’s a thorough reviewer with lots of experience with Mozilla code, so don’t hesitate to ask Georg for review if you’re patching Firefox!

Thanks Georg!

Categorieën: Mozilla-nl planet

Matt Brubeck: A little randomness for Hacker News

13 uur 41 min geleden

In systems that rely heavily on “most popular” lists, like Reddit or Hacker News, the rich get richer while the poor stay poor. Since most people only look at the top of the charts, anything that’s not already listed has a much harder time being seen. You need visibility to get ratings, and you need ratings to get visibility.

Aggregators try to address this problem by promoting the items as well as popular ones. But this is hard to do effectively. For example, the “new” page at Hacker News gets only a fraction of the front page’s traffic. Most users want to see the best content, not wade through an unfiltered stream of links. Thus, very little input is available to decide which links get promoted to the front page.

As an experiment, I wrote a userscript that uses the Hacker News API to search for new or low-ranked links and randomly insert just one or two of them into the front page. It’s also available as a bookmarklet for those who can’t or don’t want to install the user script.

Install user script (may require a browser extension)

Randomize HN (drag to bookmark bar, or right-click to bookmark)

This gives readers a chance to see and vote on links that they otherwise wouldn’t, without altering their habits or wading through a ton of unfiltered content. Each user will see just one or two links per visit, but thanks to randomness a much larger number of links will be seen by the overall user population. My belief, though I can’t prove it, is that widespread use of this feature would improve the quality of the selection process.

The script isn’t perfect (search for FIXME in the source code for some known issues), but it works well enough to try out the idea. Unfortunately, the HN API doesn’t give access to all the data I’d like, and sometimes the script won’t find any suitable links to insert. (You can look at your browser’s console to see which which items were randomly inserted.) Ideally, this feature would be built in to Hacker News—and any other service that recommends “popular” items.

Categorieën: Mozilla-nl planet

Peter Bengtsson: localForage vs. XHR

wo, 22/10/2014 - 21:10

tl;dr; Fetching from IndexedDB is about 5-15 times faster than fetching from AJAX.

localForage is a wrapper for the browser that makes it easy to work with any local storage in the browser. Different browsers have different implementations. By default, when you use localForage in Firefox is that it used IndexedDB which is asynchronous by default meaning your script don't get blocked whilst waiting for data to be retrieved.

A good pattern for a "fat client" (lots of javascript, server primarly speaks JSON) is to download some data, by AJAX using JSON and then store that in the browser. Next time you load the page, you first read from the local storage in the browser whilst you wait for a fresh new JSON from the server. That way you can present data to the screen sooner. (This is how Buggy works, blogged about it here)

Another similar pattern is that you load everything by AJAX from the server, present it and store it in the local storage. Then you perdiocally (or just on onload) you send the most recent timestamp from the data you've received and the server gives you back everything new and everything that has changed by that timestamp. The advantage of this is that the payload is continuously small but the server has to make a custom response for each client whereas a big fat blob of JSON can be better cached and such. However, oftentimes the data is dependent on your credentials/cookie anyway so most possibly you can't do much caching.

Anyway, whichever pattern you attempt I thought it'd be interesting to get a feel for how much faster it is to retrieve from the browsers memory compared to doing a plain old AJAX GET request. After all, browsers have seriously optimized for AJAX requests these days so basically the only thing standing in your way is network latency.

So I wrote a little comparison script that tests this. It's here:

It retrieves a 225Kb JSON blob from the server and measures how long that took to become an object. Equally it does the same with localforage.getItem and then it runs this 10 times and compares the times. It's obviously not a surprise the local storage retrieval is faster, what's interesting is the difference in general.

What do you think? I'm sure both sides can be optimized but at this level it feels quite realistic scenarios.

Categorieën: Mozilla-nl planet

Doug Belshaw: Interim results of the Web Literacy Map 2.0 community survey

wo, 22/10/2014 - 19:02

Thanks to my colleague Adam Lofting, I’ve been able to crunch some of the numbers from the Web Literacy Map v2.0 community survey. This will remain open until the end of the month, but I thought I’d share some of the results.


This is the high-level overview. Respondents are able to indicate the extent to which they agree or disagree with each proposal on a five-point scale. The image above shows the average score as well as the standard deviation. Basically, for the top row the higher the number the better. For the bottom row, low is good.

 by location

Breaking it down a bit further, there’s some interesting things you can pull out of this. Note that the top-most row represents people who completed the survey, but chose not to disclose their location. All of the questions are optional.

Things that stand out:

  • There’s strong support for Proposal 4: I believe that concepts such as ‘Mobile’, 'Identity’, and 'Protecting’ should be represented as cross-cutting themes in the Web Literacy Map.
  • There’s also support for Proposal 1: I believe the Web Literacy Map should explicitly reference the Mozilla manifesto and Proposal 5: I believe a 'remix’ button should allow me to remix the Web Literacy Map for my community and context.
  • People aren’t so keen on Proposal 2: I believe the three strands should be renamed 'Reading’, 'Writing’ and 'Participating’. (although, interestingly, in the comments people say they like the term 'Participating’, just not 'Reading’ and 'Writing’ which many said reminded them too much of school!)

This leaves Proposal 3: I believe the Web Literacy Map should look more like a 'map’. This could have been better phrased, as the assumption in the comments seems to be that we can present it either as a grid or as a map. In fact, here’s no reason why we can’t do both. In fact, I’d like to see us produce:

Finally, a word on Proposal 5 and remixing. In the comments there’s support for this - but also a hesitation lest it 'dilutes’ the impact of the Web Literacy Map. A number of people suggested using a GitHub-like model where people can 'fork’ the map if necessary. In fact, this is already possible as v1.1 is listed as a repository under the Mozilla account.

I’m looking forward to doing some more analysis of the community survey after it closes!

Comments? Questions? Send them this way: @dajbelshaw or

Categorieën: Mozilla-nl planet

Benjamin Smedberg: How I Do Code Reviews at Mozilla

wo, 22/10/2014 - 18:00

Since I received some good feedback about my prior post, How I Hire at Mozilla, I thought I’d try to continue this is a mini-series about how I do other things at Mozilla. Next up is code review.

Even though I have found new module owners for some of the code I own, I still end up doing 8-12 review/feedback cycles per week. Reviews are only as good as the time you spend on them: I approach reviews in a fairly systematic way.

When I load a patch for review, I don’t read it top-to-bottom. I also try to avoid reading the bug report: a code change should be able to explain itself either directly in the code or in the code commit message which is part of the patch. If bugzilla comments are required to understand a patch, those comments should probably be part of the commit message itself. Instead, I try to understand the patch by unwrapping it from the big picture into the small details:

The Commit Message
  • Does the commit message describe accurately what the patch does?
  • Am I the right person to make a decision about this change?
  • Is this the right change to be making?
  • Are there any external specifications for this change? This could include a UX design, or a DOM/HTML specification, or something else.
  • Should there be an external specification for this change?
  • Are there other experts who should be involved in this change? Does this change require a UX design/review, or a security, privacy, legal, localization, accessibility, or addon-compatibility review or notification?
Read the Specification

If there is an external specification that this change should conform to, I will read it or the appropriate sections of it. In the following steps of the review, I try to relate the changes to the specification.


If there is in-tree documentation for a feature, it should be kept up to date by patches. Some changes, such as Firefox data collection, must be documented. I encourage anyone writing Mozilla-specific features and APIs to document them primarily with in-tree docs, and not on In-tree docs are much more likely to remain correct and be updated over time.

API Review

APIs define the interaction between units of Mozilla code. A well-designed API that strikes the right balance between simplicity and power is a key component of software engineering.

In Mozilla code, APIs can come in many forms: IDL, IPDL, .webidl, C++ headers, XBL bindings, and JS can all contain APIs. Sometimes even C++ files can contain an API; for example Mozilla has an mostly-unfortunate pattern of using the global observer service as an API surface between disconnected code.

In the first pass I try to avoid reviewing the implementation of an API. I’m focused on the API itself and its associated doccomments. The design of the system and the interaction between systems should be clear from the API docs. Error handling should be clear. If it’s not perfectly obvious, the threading, asynchronous behavior, or other state-machine aspects of an API should be carefully documented.

During this phase, it is often necessary to read the surrounding code to understand the system. None of our existing tools are very good at this, so I often have several MXR tabs open while reading a patch. Hopefully future review-board integration will make this better!

Brainstorm Design Issues

In my experience, the design review is the hardest phase of a review, the part which requires the most experience and creativity, and provides the most value.

  • How will this change interact with other code in the tree?
  • Are there edge cases or failure cases that need to be addressed in the design?
  • Is it likely that this change will affect performance or security in unexpected ways?
Testing Review

I try to review the tests before I review the implementation.

  • Are there automated unit tests?
  • Are there automated performance tests?
  • Is there appropriate telemetry/field measurement, especially for error conditions?
  • Do the tests cover the specification, if there is one?
  • Do the tests cover error conditions?
  • Do the tests strike the right balance between “unit” testing of small pieces of code versus “integration” tests that ensure a feature works properly end-to-end?
Code Review

The code review is the least interesting part of the review. At this point I’m going through the patch line by line.

  • Make sure that the code uses standard Mozilla coding style. I really desperately want somebody to automated lots of this as part of the patch-submission process. It’s tedious both for me and for the patch author if there are style issues that delay a patch and require another review cycle.
  • Make sure that the number of comments is appropriate for the code in question. New coders/contributors sometimes have a tendency to over-comment things that are obvious just by reading the code. Experienced contributors sometimes make assumptions that are correct based on experience but should be called out more explicitly in the code.
  • Look for appropriate assertions. Assertions are a great form of documentation and runtime checking.
  • Look for appropriate logging. In Mozilla we tend to under-log, and I’d like to push especially new code toward more aggressive logging.
  • Mostly this is scanning the implementation. If there is complexity (such as threading!), I’ll have to slow down a lot and make sure that each access and state change is properly synchronized.
Re-read the Specification

If there is a specification, I’ll briefly re-read it to make sure that it was covered by the code I just finished reading.


Currently, I primarily do reviews in the bugzilla “edit” interface, with the “edit attachment as comment” option. Splinter is confusing and useless to me, and review-board doesn’t seem to be ready for prime-time.

For long or complex reviews, I will sometimes copy and quote the patch in emacs and paste or attach it to bugzilla when I’m finished.

In some cases I will cut off a review after one of the earlier phases: if I have questions about the general approach, the design, or the API surface, I will often try to clarify those questions before proceeding with the rest of the review.

There’s an interesting thread in about whether it is discouraging to new contributors to mark “review-” on a patch, and whether there are less-painful ways of indicating that a patch needs work without making them feel discouraged. My current practice is to mark r- in all cases where a patch needs to be revised, but to thank contributors for their effort so that they are still appreciated and to be as specific as possible about required changes while avoiding any words that could be perceived as an insult.

If I haven’t worked with a coder (paid or volunteer) in the past, I will typically always ask them to submit an updated patch with any changes for re-review. This allows me to make sure that the changes were completed properly and didn’t introduce any new problems. After I gain some experience, I will often trust people to make necessary changes and simply mark “r+ with review comments fixed”.

Categorieën: Mozilla-nl planet

Michael Kaply: Disabling Buttons In Preferences

wo, 22/10/2014 - 17:55

I get asked a lot how to disable certain buttons in preferences like Make Firefox the default browser or the various buttons in the Startup groupbox. Firefox does have a way to disable these buttons, but it's not very obvious. This post will attempt to remedy that.

These buttons are controlled through preferences that have the text "disable_button" in them. Just changing the preference to true isn't enough, though. The preference has to be locked, either via the CCK2 or AutoConfig. What follows is a mapping of all the preferences to their corresponding buttons.

Advanced->General->Make Firefox the default browser
General->Use Current Pages
General->Use Bookmark
General->Restore to Default
Advanced->Certificates->View Certificates
Advanced->Certificates->Security Devices
Advanced->Update->Show Update History
Privacy->History->Show Cookies
Security->Passwords->Saved Paswords

As a bonus, there's one more preference you can set and lock - pref.downloads.disable_button.edit_actions. It prevents the changing of any actions on the Applications page in preferences.

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox 34 beta1 to beta2

wo, 22/10/2014 - 17:31

  • 60 changesets
  • 135 files changed
  • 2926 insertions
  • 673 deletions

ExtensionOccurrences js32 cpp23 cc17 jsm9 html9 css9 jsx7 h7 ini3 sh2 patch2 mm2 manifest2 list2 xul1 xml1 txt1 py1 mozilla1 mk1 json1 build1

ModuleOccurrences browser60 gfx21 security12 content11 toolkit5 layout4 widget3 testing3 media3 gfx3 js2 xulrunner1 xpcom1 netwerk1 mobile1 +gfx1 dom1

List of changesets:

Justin DolskeBug 1068290 - UI Tour: Add ability to highlight New Private Window icon in chrome. r=MattN a=dolske - aa77bc7b59e3 Justin DolskeBug 1072036 - UI Tour: Add ability to highlight new privacy button. r=mattn a=dolske - d37b92959827 Justin DolskeBug 1071238 - UI Tour: add ability to put a widget in the toolbar. r=mattn a=dolske - 1c96180e6a5b Blair McBrideBug 1068284 - UI Tour: Add ability to highlight search provider in search menu. r=MattN a=dolske - 9d4b08eecd9a Joel MaherBug 1083369 - update talos.json to include fixes for mainthreadio whitelist and other goodness. r=dminor a=test-only - 184bc1bea651 Bas SchoutenBug 1074272 - Use exception mode 0 for our D3D11 devices. r=jrmuizel, a=sledru - 46d2991042df Gijs KruitboschBug 1079869 - Fix closing forget panel by adding a closemenu=none attribute. r=jaws, a=sledru - e6441f98f159 Patrick BrossetBug 1020038 - Disable test browser/devtools/layoutview/test/browser_layoutview_update-in-iframes.js. a=test-only - da7c401c5aa7 Jeff GilbertBug 1079848 - Large allocs should be infallible and handled. r=kamidphish, a=sledru - 03d4ab96c271 Mike HommeyBug 1081031 - Unbust xulrunner mac builds by not exporting all JS symbols (Bug 920731). r=bsmedberg, a=npotb - 5967c4a96835 Mark BannerBug 1081906 - Fix unable to start Firefox due to 'Couldn't load XPCOM'. r=bsmedberg, a=sledru - c212fd07fd32 Georg FritzscheBug 1079312 - Fix invalid log.warning() to log.warn(). r=irving, a=sledru - ae6317e02f72 Mike de BoerBug 1081130 - Fix importing contacts with only a phone number and fetch the correct format. r=abr, a=sledru - 1f7f807b6362 Simon MontaguTest for Bug 1067268. r=jfkthame, a=lmandel - 4f904d9bcff2 Simon MontaguBug 1067268 - Don't mix physical and logical coordinates when calculating width to clear past floats. r=jfkthame, a=lmandel - 29dd7b8ee41f JW WangBug 1069289 - Take |mAudioEndTime| into account when updating playback position at the end of playback. r=kinetik, a=lmandel - 31fc68be9136 David KeelerBug 1058812 - mozilla::pkix: Add SignatureAlgorithm::unsupported_algorithm to better handle e.g. roots signed with RSA/MD5. r=briansmith, a=lmandel - 2535e75ff9c6 David KeelerBug 1058812 - mozilla::pkix: Test handling unsupported signature algorithms. r=briansmith, a=lmandel - a7b8a4567262 Jonathan KewBug 1074223 - Update OTS to pick up fixes for upstream issues 35, 37. Current rev: c24a839b1c66c4de09e58fabaacb82bf3bd692a4. r=jdaggett, a=lmandel - 6524ec11ce53 Gijs KruitboschBug 1050638 - Should be able to close tab with onbeforeunload warning if clicking close a second time. r=ttaubert, a=lmandel - 98fc091c4706 JW WangBug 760770 - Allow 'progress' and 'suspend' events after 'ended'. r=roc, a=test-only - 915073abfd8b Benjamin ChenBug 1041362 - Modify testcases because during the oncanplaythrough callback function, the element might not ended but the mediastream is ended. r=roc, a=test-only - c3fa7201e034 Jean-Yves AvenardBug 1079621 - Return error instead of asserting. r=kinetik, a=lmandel - 9be2b1620955 Andrei OpreaBug 1020449 Loop should show caller information on incoming calls. Patch originally by Andrei, updated and polished by Standard8. r=nperriault a=lmandel - 742beda04394 Mark BannerBug 1020449: Fix typo in addressing review comments in Bug 1020449 that caused broken jsx. rs=NiKo a=lmandel - 0033bca3ce22 Mark BannerBug 1029433 When in a Loop call, the title bar should display the remote party's information. r=nperriault a=lmandel - 530ec559a14c Simone BrunoBug 1058286 - Add in-tree manifests needed for tests. DONTBUILD a=NPOTB - 0b7106ef79d2 Jonathan KewBug 1074809 - For OTS warning (rather than failure) messages, only log the first occurrence of any given message per font. r=jdaggett, a=lmandel - 1875f4aff106 Ed LeeBug 1081157 - "What is this page" link appears on "blank" version of about:newtab. r=ttaubert, a=sledru - c00a4cfe83e9 Matthew GreganBug 1080986 - Check list chunk is large enough to read list ID before reading. r=giles, a=sledru - bb851de524c2 Matthew GreganBug 1079747 - Follow WhatWG's MIMESniff spec for MP4 more closely. r=cpearce, a=sledru - f752e25f4c42 Steven MichaudBug 1084589 - Fix a Yosemite topcrasher. r=gijskruitbosch a=gavin - 3a24d0c65745 Mike de BoerBug 1081061: switch to a different database if a userProfile is active during the first mozLoop.contacts access to always be in sync with the correct state. r=MattN. a=lmandel - 6b4c22bfe385 Mark BannerBug 1081066 Incoming call window stays open forever if the caller closes the window/tab or crashes. r=nperriault a=lmandel - 8c329499cf7d Matthew NoorenbergheBug 1079656 - Make the Loop Account menu item work after a restart. r=jaws a=lmandel - ada526904539 Mike de BoerBug 1076967: fix Error object data propagation to Loop content pages. r=bholley a=lmandel - 880cfb4ef6f8 Mark BannerBug 1078226 Unexpected Audio Level indicator on audio-only calls for Loop, also disable broken low-quality video warning indicator. r=nperriault a=lmandel - 5ad9f4e96214 Nicolas PerriaultBug 1048162 Part 1 - Add an 'Email Link' button to Loop desktop failed call view. r=Standard8 a=lmandel - f705ffd06218 Mark BannerBug 1081154 - Loop direct calls should attempt to call phone numbers as well as email addresses. r=mikedeboer a=lmandel - 191b3ce44bea Nicolas PerriaultBug 1048162 Part 2 - Display an error message if fetching an email link fails r=standard8,darrin a=lmandel - 3fc523fcc7da Mike de BoerBug 1013989: change the label of the Loop button to Hello. r=MattN a=lmandel - 2edc9ed56fa4 Romain GauthierBug 1079811 - A new call won't start if the outgoing call window is opened (showing feedback or retry/cancel). r=Standard8 a=lmandel - a4e22c4da890 Mike de BoerBug 1079941: implement to allow searching for contacts by query and use that to find out if a contact who's trying to call you is blocked. r=abr a=lmandel - bda95894a692 Randell JesupBug 1084384: support importing contacts with phone numbers in a different format r=abr a=lmandel - 8c42ccaf8aa1 Mike de BoerBug 1084097: make sure that the Loop button only shows up in the palette when unthrottled. r=Unfocused a=lmandel - 5840764c4312 Randell JesupBug 1070457: downgrade assertion about cubeb audiostreams to a warning r=roc a=lmandel - 9e420243b962 Randell JesupBug 1075640: Don't return 0-length frames for decoding; add comments about loss handling r=ehugg a=lmandel - bb26f4854630 Ethan HuggBug 1075640 - Check for zero length frames in GMP H264 decode r=jesup a=lmandel - 452bc7db811e Luke WagnerBug 1064668 - OdinMonkey: Only add AsmJSActivation to profiling stack after it is fully initialized. r=djvj, a=lmandel - eb43a2c05eb3 Bas SchoutenBug 1060588 - Use PushClipRect when possible in ClipToRegionInternal. r=jrmuizel, a=lmandel - 6609fd74488b Gijs KruitboschBug 1077404 - subviewradio elements in panic button panel are elliptical and labels get borders. r=jaws, a=lmandel - 2418d9e17dd0 Markus StangeBug 1081160 - Update window shadows for Yosemite. r=smichaud, a=lmandel - fc032520a26e Chenxia LiuBug 1079761 - Add 'stop tab mirroring' one level higher in the menu. r=rbarker, a=lmandel - 4018d170ab06 Mike HommeyBug 1082323 - Reject pymake in r=mshal, a=sledru - f19a52b7e6ec Tomasz KołodziejskiBug 1074817 - Allow downgrade of content-prefs.sqlite. r=MattN, a=lmandel - 2235079fe205 Gijs KruitboschBug 1083895 - Favicon should not change if link element isn't in DOM. r=bz, a=lmandel - 73bc0bc9343b Dragana DamjanovicBug 1081794 - Fixing a test for dns request cancel. On e10s, the dns resolver is sometimes faster than a cancel request. Use a random string to be resolved instead of a fix one. r=sworkman, a=test-only - 6d2e5afd8b75 Nicolas SilvaBug 1083071 - Add some old intel drivers to the blocklist. r=Bas, a=sledru - 53b97e435f10 Nicolas SilvaBug 1083071 - Blacklist device family IntelGMAX4500HD drivers older than 7-19-2011 because of OMTC issues on Windows. r=Bas, a=sledru - b5d97c1c71b7 Ryan VanderMeulenBug 1083071 - Change accidentally-used periods to commas. rs=nical, a=bustage - 8cc403ad710b

Categorieën: Mozilla-nl planet

Robert Nyman: The editors I’ve been using – which one is your favorite?

wo, 22/10/2014 - 16:09

The other day when I wrote about Vim and how to get started with it, I got a bit nostalgic with the editors I’ve been using over the years.

Therefore, I thought I’d list the editors I’ve been using over the years. I remember dabbling around with a few and trying to understand them, but this list is made up of editors that I’ve been using extensively:

    Allaire HomeSite
    Ah, good ol’ HomeSite. You never forget your first real editor that you used for your creations. It was later bought by MacroMedia and then, in 2009, it was retired. Its creator, Nick Bradbury, wrote a bit about that in HomeSite Discontinued. I also sometimes used TopStyle, also created by Nick, as a complement to HomeSite – and that one is actually still alive!
    Visual Studio.NET
    I was young and I needed the money.
    After my switch to Mac OS X, I quickly started using TextMate and it was my main editor for a good number of years.
    When I had used TextMate for a long time, a number of developers told me I should really get into Vim, where MacVim seemed like the most suitable alternative. I tried, really hard, with it for about 6 months; learned a lot, but eventually went back to TextMate.
    Sublime Text
    Later, along came Sublime Text and seemed to have a lot of nice features and active development, while TextMate had been pretty stale for a long time.
    MacVim (again)
    And now, as explained in my recent blog post on Vim, I’m back there again. :-)

I also do like to dabble around with various editors, to see what I like, get another perspective on workflow and general inspiration. One thing I’m toying around with there is Atom from GitHub, and I look forward to testing it more as well.

Which editor are you using?

It would be very interesting and great if you’d like to share in the comments which editor you are using, and why you prefer it! Or with which editor you started your developer career!

Categorieën: Mozilla-nl planet

Nick Cameron: Thoughts on numeric types

wo, 22/10/2014 - 05:31
Rust has fixed width integer and floating point types (`u8`, `i32`, `f64`, etc.). It also has pointer width types (`int` and `uint` for signed and unsigned integers, respectively). I want to talk a bit about when to use which type, and comment a little on the ongoing debate around the naming and use of these types.

Choosing a type
Hopefully you know whether you want an integer or a floating point number. From here on in I'll assume you want an integer, since they are the more interesting case. Hopefully you know if you need your integer to be signed or not. Then it gets interesting.

All other things being equal, you want to use the smallest integer you can for performance reasons. Programs run as fast or faster on smaller integers (especially if the larger integer has to be emulated in software, e.g., `u64` on a 32 bit machine). Furthermore, smaller integers will give smaller code.

At this point you need to think about overflow. If you pick a type which is too small for your data, then you will get overflow and usually bugs. You very rarely want overflow. Sometimes you do - if you want arithmetic modulo 2^n where n is 8, 16, 32, or 64, you can use the fixed width type and rely on overflow behaviour. Sometimes you might also want signed overflow for some bit twiddling tricks. But usually you don't want overflow.

If your data could grow to any size, you should use a type which will never overflow, such as Rust's `num::bigint::BigInt`. You might be able to do better performance-wise if you can prove that values might only overflow in certain places and/or you can cope with overflow without 'upgrading' to a wider integer type.

If, on the other hand, you choose a fixed width integer, you are asserting that the value will never exceed that size. For example, if you have an ascii character, you know it won't exceed 8 bits, so you can use `u8` (assuming you're not going to do any arithmetic which might cause overflow).

So far, so obvious. But, what are `int` and `uint` for? These types are pointer width, that means they are the same size as a pointer on the system you are compiling for. When using these types, you are asserting that a value will never grow larger than a pointer (taking into account details about the sign, etc.). This is actually quite a rare situation, the usual case is when indexing into an array, which is itself quite rare in Rust (since we prefer using an iterator).

What you should never do is think "this number is an integer, I'll use `int`". You must always consider the maximum size of the integer and thus the width of the type you'll use.
Language design issues
There are a few questions that keep coming up around numeric types - how to name the types? Which type to use as a default? What should `int`/`uint` mean?

It should be clear from the above that there are only very few situations when using `int`/`uint` is the right choice. So, it is a terrible choice for any kind of default. But what is a good choice? Well first of all, there are two meanings for 'default': the 'go to' type to represent an integer when programming (especially in tutorials and documentation), and the default when a numeric literal does not have a suffix and type inference can't infer a type. The first is a matter of recommendation and style, and the second is built-in to the compiler and language.

In general programming, you should use the right width type, as discussed above. For tutorials and documentation, it is often less clear which width is needed. We have had an unfortunate tendency to reach for `int` here because it is the most familiar and the least scary looking. I think this is wrong. We should probably use a variety of sized types so that newcomers to Rust get aquainted with the fixed width integer types and don't perpetuate the habit of using `int`.

For a long time, Rust had `int` as the default type when the compiler couldn't decide on something better. Then we got rid of the default entirely and made it a type error if no precise numeric type could be inferred. Now we have decided we should have a default again. The problem is that there is no good default. If you aren't being explicit about the width of the value, you are basically waving your hands about overflow and taking a "it'll be fine, whatever" approach, which is bad programming. There is no default choice of integer which is appropriate for that situation (except a growable integer like BigInt, but that is not an appropriate default for a systems langauge). We could go with `i64` since that is the least worst option we have in terms of overflow (and thus safety). Or we could go with `i32` since that is probably the most performant on current processors, but neither of these options are future-proof. We could use `int`, but this is wrong since it is so rare to be able to reason that you won't overflow when you have an essentially unknown width. Also, on processors with less than 32 bit pointers, it is far to easy to overflow. I suspect there is no good answer. Perhaps the best thing is to pick `i64` because "safety first".

Which brings us to naming. Perhaps `int`/`uint` are nor the best names since they suggest they should be the default types to use when they are not. Names such as `index`/`uindex`, `int_ptr`/`u_ptr`, and `size`/`usize` have been suggested. All of these are better in that they suggest the proper use for these types. They are not such nice names though, but perhaps that is OK, since we should (mostly) discourage their use. I'm not really sure where I stand on this, again I don't really like any of the options, and at the end of the day, naming is hard.
Categorieën: Mozilla-nl planet

Raniere Silva: The Status of Math in Open Access

wo, 22/10/2014 - 04:00
The Status of Math in Open Access

This week, October 20–26, 2014, held the Open Access Week (see the announcement) and will end with Mozilla Festival that has a awesome science track. This post has some thoughts about math and open access and this two events.

Leia mais...

Categorieën: Mozilla-nl planet

Curtis Koenig: Thanks for all the Fish

wo, 22/10/2014 - 03:11

I’ve always loved that book or in fact any of Douglas Adams books as they made me laugh while reading for the first time. And like the ending of that series it always seemed a good way to start a ending. This is only the 3rd real job I’ve ever had and they’ve all ended with that as the subject line, so by now you all know where this is going.

The last 3 years 9 months and 21 days have been the best of my adult working life. Mozilla has been more than a job, more than a career. It was a home. The opportunity to apply ones talent in conjunction with values and mission is a gift. It’s a dream state, even on bad days, that I gladly would have remained a slumberer in. The Community of Mozilla is a powerful and wonderful uniqueness that embodies the core of what it means to be Open, and if we ever lose that we’ve lost a precious gem.

I hope to work with many of you again at some future time. If we cross paths somewhere I’d happily lift a libation in remembrance.

With that I shall end with one of my favorite bits of poetry:

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;

Then took the other, as just as fair,
And having perhaps the better claim
Because it was grassy and wanted wear,
Though as for that the passing there
Had worn them really about the same,

And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way
I doubted if I should ever come back.

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I,
I took the one less traveled by,
And that has made all the difference.



Categorieën: Mozilla-nl planet

Ben Kero: Missoula visit, day 1

di, 21/10/2014 - 22:30

NOTE: This is a personal post, so if these sort of things do not interest you please feel free to disregard.

Yesterday I drove from Seattle to Missoula to visit my mother and help her sort out her health issues. I left later than usual, but with the drive time reduced by an hour compared to Portland combined with the relatively straight and boring I-90 I made it to Missoula with energy to spare (which also might have been why I was up far later than my arrival time).

The purpose of my visit is to visit my mother, show that I still care about my family, and help her sort out her medical issues (she’s currently going through her third round of cancer). When I arrived last night around 2300 I didn’t get a very good look at her. She had stayed awake past her normal 2000 time to await my arrival and greet me. Last night was relatively uneventful besides my restful sleep. She showed me to the apartment’s single bedroom. Each surface was meticulously cleaned, although none of the multitude of tchotchkes or personal accessories were organized or put away. While using the bathroom I noticed there was a small mop and bucket. Normally I wouldn’t think much of it, but in previous weeks my sister told me that my mother had given herself a panic attack making sure the apartment was spotless for my arrival. Unfortunately my trip over was waylaid for a few weeks, so I hope that she hasn’t been in such a state the whole time.

Last year I sent her an air purifier to remove all the pet danger from the air, and although she couldn’t figure out what it was or its purpose, thankfully she had finally figured it out and was using it. As a result the air was much cleaner and her phlegm-laden smoker’s cough was slightly better than last time I visited.

This morning I woke up later because I also fell asleep quite late into the morning combined with the timezone change. She has a few friends here in Missoula who (as far as I can tell) provide her with some company and source of gossip and usefulness. when I emerged from my room this morning I found her on the phone with one such friend. I didn’t get much from the conversation, but apparently the daily phone calls are a routine for her. That’s good.

What I really didn’t like though was the television. During the day it was a large part of her unchanging environment. Equipped with a “digital cable” box, this tube never showed anything besides Informative Murder Porn. Likewise, the bookshelves were chocked full of James Patterson books, promising more tripe romance and novelized informative murder porn. Although I fear that it’s rotting her brain I refrained from commenting about it.

After my emergence this morning we finally got a good look at each other. She finally noticed my attempt at growing a beard and I finally noticed her emaciation. Her weight is below 100lb now, and she looks positively skeletal. It’s not a pretty sight. It appears she attempted to dye her hair recently, but even with that effort it’s resisted, instead opting for a grey and wispy appearance. I offered to pick her up a meal with my lunch, but she refused saying that she already had breakfast.

We talked for a while about how she’s been. Besides the new medical situation nothing ever seems to change with her. She remains cloistered in her dark, smoke-smelling apartment with nothing to keep her company save her pets, her informative murder porn, and trashy novels. She hasn’t expressed any dissatisfaction with the situation, so perhaps she enjoys it. I haven’t asked, and haven’t decided if it’s appropriate to ask yet. Perhaps it’s imposing my values on her to think that she would be unhappy with this bountiful life she’s living.

This morning we talked about her medical situation. The gist of the situation is that she believes that she’s been caught up in a catch-22 with a set of doctors, each waiting to hear from another before proceeding to make a diagnosis and start a treatment. I asked her about what she knows (red blood cell count is down), and what kind of treatment she was currently undergoing. The answer was no treatment, so I continued by asking which doctor’s she’s seen and what their next steps would be (or what they’re waiting on). I got quite a few answers about quite a few doctors, and was unfortunately unable to follow most of it. I asked her to write a list of doctors down, along with what she thinks they’re waiting on and the last time they’ve been in contact. Hopefully when I get home this evening I can help untangle this and get her the treatment she needs. She didn’t seem particularly worried about things, which frustrated me. The scenario in front of me was her off-the-cuff attitude about it combined with the television showing an emotionally charged lady with a bloody knife crumpled into a heap on the ground, the police intervening to save the day and arrest the paedophile, had caused me to want to ragequit and give her some time to compile the list of doctors. I do not have much hope of returning home this evening to any list.

This afternoon, as usual for my Missoula visits, I’ve holed up at The Break coffee shop. It’s an old standby for spending uninterrupted time on my laptop to get a little work done. It’s also conveniently located far away from that apartment, and near the other goodness of downtown Missoula. The espresso might have been burnt, but the well worn tables, music reminiscent of my high school days in Missoula, and mixed clientèle lead to a very pleasing atmosphere. As I sit at my stained and worn coffee table typing away at my laptop I can see a young man in a cowboy hat and vest conversing with a friend in a denim jacket over a cup of joe, a dreadlocked young lady enjoying an iced coffee alone, equipped with Macbook and textbooks. Various others including a suited businessman, and a few white collar workers taking a lunch break are around. The bright but persistently drizzling conditions outside add to the hearth-like atmosphere of the shop. This place is going to get sick of me before the week is out.

This afternoon I’m going to attempt to do a bit do a bit of work and get in contact with my father and sister for their obligatory visits. I hope that I can return to my mother’s place and provide some sort of assistance besides moral support.

I’ll be in Missoula until Thursday evening.

Categorieën: Mozilla-nl planet

Mic Berman: What Does Your Life Design Look Like?

di, 21/10/2014 - 19:53

I would guess many people would react to this title like what on earth is she talking about? Design my life - what does that even mean? Many people I coach and work with have not thought about their life’s design - meaning the focused work you do, is it in support of your values and vision? the people you surround yourself with - do they inspire and motivate you? the physical space you live in - does it give you energy?  


Your life design includes more than your career. I invite my clients to think beyond what's on paper. Your career is your role, salary, title, industry company. I’m asking you also think of -  who you will be surrounded with, where it might take you beyond the role right now, how it will honour or not honour your values and how it will fit with your vision for your life.


If we jump mindlessly from one opportunity to the next - even if they are great opportunities on the surface eg more money, bigger title etc it can cost us in our personal lives in ways we may not consider. Arianna Huffington recently wrote about this in her book Thrive, “Our relentless pursuit of the two traditional metrics of success - money and power - has led to an epidemic of burnout and stress-related illnesses, and an erosion in the quality of our relationships, family life, and, ironically, our careers”. In addition to this sentiment, everyone’s heard repeated stories of those on their deathbed who never regret not having worked more or harder - what they always say is they wished they'd spent more time with people they loved or doing things that inspire and nurture. These are our regrets. So how do you want to design your life with no regrets in mind?


Here are my 3 tips on designing which I hope inspires you to re-create your designed life:

  1. Know your values and how you want to honour them

  2. Define your vision if not for 5 years at least for the next year - what are the big impressions you want to leave

  3. Who are your stakeholders (the people that matter to you) and how will you honour them

Categorieën: Mozilla-nl planet

Doug Belshaw: A 10-point #MozFest survival guide

di, 21/10/2014 - 19:11

It’s the Mozilla Festival in London this weekend. It’s sold out, so you’ll have to beg, borrow or steal a ticket! This will will be my fourth, and third as a paid contributor (i.e. Mozilla employee).

Here’s my tips for getting the most of it.

1. Attend the whole thing

There’s always the temptation with multi-day events not to go to each of the days. It’s easy to slip off into the city – especially if it’s one you haven’t been to before. However, that would a real shame as there’s so much to do and see at MozFest. Plus, you really should have booked a few days either side to chill out.

2. Sample everything

Some tracks will grab you more than others. However, with nine floors and multiple sessions happening at the same time, there’s always going to be something to keep you entertained. Feel free to vote with your feet if you’re not getting maximum value from a session – and drop into something you don’t necessarily know a lot about!

3. Drink lots

Not alcohol or coffee – although there’ll be plenty of that on offer! I mean fluids that will rehydrate you. At the Mozilla Summit at the end of last year we were all given rehydration powder along with a Camelbak refillable bottle. This was the perfect combination and I urge you to bring something similar. Pro tip: if you can’t find the powder (it’s harder to come by in the UK) just put a slice of lemon in the bottom of the bottle to keep it tasting fresh all day!

4. Introduce yourself to people

The chances are that you don’t know all 1,600 people who have tickets for MozFest. I know I don’t! You should feel encouraged to go up and introduce yourself to people who look lost, bewildered, or at a loose end. Sample phrases that seem to work well:

  • “Wow, it’s pretty crazy, eh?”
  • “Hi! Which session have you just been to?”
  • “Is this your first MozFest?”
5. Take time out

It’s easy to feel overwhelmed, so feel free to find a corner, put your headphones on and zone out for a while. You’ll see plenty of people doing this – on all floors! Pace yourself – it’s a marathon, not a sprint.

6. Wear comfortable shoes/clothing

There are lifts at the venue but, as you can imagine, with so many people there they get full quickly. As a result there’ll be plenty of walking up and down stairs. Wear your most comfortable pair of shoes and clothing that’ll still look good when you’re a sticky mess. ;-)

7. Expect tech fails

I’ve been to a lot of events and at every single one, whether because of a technical problem or human error, there’s been a tech fail. Expect it! Embrace it. The wifi is pretty good, but mobile phone coverage is poor. Plan accordingly and have a backup option.

8. Ask questions

With so many people coming from so many backgrounds and disciplines, it’s difficult to know the terminology involved. If someone ‘drops a jargon bomb’ then you should call them out on it. If you don’t know what they mean, then the chances are others won’t know either. And if you’re the one doing the explaining, be aware that others may not share your context.

9. Come equipped

Your mileage may vary, but I’d suggest the following:

  • Bag
  • Laptop
  • Mobile phone and/or tablet
  • Pen
  • Notepad
  • Multi-gang extension lead
  • Charging cables
  • Headphones
  • Snacks (e.g. granola bars)
  • Refillable water bottle

I’d suggest a backpack as something over one shoulder might eventually cause pain. You might also want to put a cloth bag inside the bag you’re carrying in case you pick up extra stuff.

10. Build (and network!)

MozFest is a huge opportunity to meet and co-create stuff with exceptionally talented and enthusiastic people. So get involved! Bring your skills and lend a hand in whatever’s being built. If nothing else, you can take photos and help document the festival.

The strapline of MozFest is ‘arrive with an idea, leave with a community’. Unlike some conferences that have subtitles that, frankly, bear no relation to what actually happens, this one is dead on. You’ll want to keep in touch with people, so in addition to the stuff listed above you might want to bring business cards. Far from being a 20th century thing, I’ve found them much more useful than just writing on a scrap of paper or exchanging Twitter usernames.

This isn’t meant to be comprehensive, just my top tips. But I’d be very interested to hear your advice to newbies if you’re a MozFest veteran! Leave a comment below. :-)

Image CC BY-SA Alan Levine

Update: my colleague Kay Thaney has a great list of blighty sights that you should check out too!

Categorieën: Mozilla-nl planet

Mic Berman: How are you taking care of yourself?

di, 21/10/2014 - 18:43

The leaders I coach drive themselves and their teams to great achievements, are engaged in what they do, love their work and have passion and compassion in how they work for their teams and customers. They face tough situations - impossible-seeming deadlines or goals, difficult conversations, constant re-balancing of work-life priorities, and crazy business scenarios we’ve never faced before.

Their days can be both energizing and completely draining. And each day they face those choices and predicaments at times with full grace and others with total foolishness.

Along the way I hear and offer the questions - how are you taking care of yourself? how will you rejuvenate? how will you maintain balance? so you I ask these questions of the leaders I work with so that they can keep driving their goals, over-achieving each day and showing up for the important people in your life :)


I focus on three ways to do this myself.

  • Knowing myself - spending time to understand and check in with my values, triggers, and motivations.

  • Doing a daily practice - i’ve created a daily and weekly practice that touches on my mind, body and spirit. this discipline and evolving practice keeps me learning, present and ‘in balance’

  • Being discerning about my influences - choose the people, experiences and beauty that influence my life and what’s important about that today, this week or month or year.

Categorieën: Mozilla-nl planet

Jen Fong-Adwent: Distribute everything

di, 21/10/2014 - 17:00
I've been thinking about the how our online communication and interactions have cost our personal relationships and helped others profit.
Categorieën: Mozilla-nl planet

Priyanka Nag: Mozilla and WeTech Women's Maker Party, Delhi

di, 21/10/2014 - 14:29
Well, I love the name Larissa came up with for today's event. It is kind of a little long but defines the event best - "Mozilla and WeTech Woman’s Maker Party".

We had landed in Delhi on the 22nd of July 2014 and as Larissa defines it, Delhi was indeed a 'steam sauna'. We did spend most of that day going around and visiting a few famous places like the Red Fort, the India Gate, Parliament house etc. In the evening, we did meet the local Mozillians in Delhi. Well, it was an informal meeting of all Mozillians, talking all 'sh!t mozillians say' ;)

23rd morning began with all excitement. It was a small crowd, but a really awesome crowd in that conference room. Right from the introduction session, we could feel the high intellectual capabilities these young ladies were filled with. After a small game of spectrogram, we immediately moved to introduce Mozilla as an organization as well as all the Mozilla projects. To my surprise, most of the participants already knew about Open Source and had a fair idea about Mozilla. To my greater surprise, all of our participants had used Firefox at some point of time (even if it was not their default/regular browser). It was thus easy to introduce the different Mozilla projects and contribution pathways to them.

Serious hacking in progress... The confidence these dynamic ladies did showcase was beyond appreciation.
One thing each person in the room agreed to was - "being a woman in technology is indeed tough". But these girls were ready to face the tough world and fight it out for themselves!

Post lunch, we got to some webmaking. So much hacking, so much was tough to believe that many of these people were "not from a technical background".
Some of the awesome makes can be found listed on this spreadsheet.

Well, it goes beyond saying that these superstarts definitely deserved some awards for their awesomeness and thus, we did give them some webmaker badges.

Very few events have given me the happiness of being able to convert almost all participants into Mozillians and this was one of those rare ones.

The awesome woman Webmakers of Delhi :)

Categorieën: Mozilla-nl planet

Priyanka Nag: Maker Party Bhubaneshwar

di, 21/10/2014 - 14:28
Last weekend I had a blast in Bhubaneshwar. Over two days, I was there at two different colleges for two Maker parties.

Saturday (23rd August 2014), we were at the Center of IT & Management Education (CIME) where we were asked to address a crowd of 100 participants whom we were supposed to teach webmaking. Trust me, very rarely do we get such crowd in events where we get the opportunity to be less of a teacher and more of a learner. We taught them Webmaking, true, but in return we learnt a lot from them.

Maker Party at Center of IT & Management Education (CIME)
On Sunday, things were even more fabulous at Institute of Technical Education & Research(ITER), Siksha 'O' Anusandhan University college, where we were welcomed by around 400 participants, all filled with energy, enthusiasm and the willingness to learn.

Maker Party at Institute of Technical Education & Research(ITER)
Our agenda for both days were have loads and loads of fun! We kept the tracks interactive and very open ended. On both days, we did cover the following topics:
  • Introduction to Mozilla
  • Mozilla Products and projects
  • Ways of contributing to Mozilla
  • Intro to Webmaker tools
  • Hands-on session on Thimble, Popcorn and X-ray goggles and Appmaker
Both days, we concluded our sessions by giving away some small tokens of appreciation like e T-shirts, badges, stickers etc, to the people who had been extra awesome among the group. We concluded the awesomeness of the two days by cutting a very delicious cake and fighting over it till its last pieces.Cake.....Bading goodbye after two days was tough, but after witnessing the enthusiasm of everyone we met during these two events, I am very sure we are going to return soon to Bhubaneshwar for even more awesomeness.A few people who are two be thanked for making these events sucessful and very memorable are:
  1. Sayak Sarkar, the co-organizer for this event.
  2. Sumantro, Umesh and Sukanta from travelling all the way from Kolkata and helping us out with the sessions.
  3. Rish and Prasanna for organizing these events.
  4. Most importantly, the entire team of volunteers from both colleges without whom we wouldn't havebeen able to even move a desk.
 p.s - Not to forget, we did manage to grab media's attention as well. The event was covered by a local newspaper.The article in the newspaper next morning
Categorieën: Mozilla-nl planet

Christian Heilmann: Removing private metadata (geolocation, time, date) from photos the simple way:

di, 21/10/2014 - 12:28

When you take photos with your smartphone or camera it adds much more to the image than meets the eye. This EXIF data contains all kind of interesting information: type of device, flash on or off, time, date and most worrying – geographical location. Services like Flickr or Google Plus use this data to show your photos on a map, which is nice, but you may find yourself in situations where you share images without wanting to tell the recipient in detail where and when they were taken.

For example the photo of me here:

christian heilmann, not sure about the shirt

Doesn’t only tell you that I am not sure about this shirt, but also the following information:

  • GPSInfoIFDPointer: 462
  • Model: Nexus 5
  • ExifIFDPointer: 134
  • YCbCrPositioning: 1
  • YResolution: 72
  • ResolutionUnit: 2
  • XResolution: 72
  • Make: LGE
  • ApertureValue: 3.07
  • InteroperabilityIFDPointer: 432
  • DateTimeDigitized: 2014:10:19 16:06:20
  • ShutterSpeedValue: 5.321
  • ColorSpace: 1
  • DateTimeOriginal: 2014:10:19 16:06:20
  • FlashpixVersion: 0100
  • ExposureBias: 0
  • PixelYDimension: 960
  • ExifVersion: 0220
  • PixelXDimension: 1280
  • FocalLength: 1.23
  • Flash: Flash did not fire
  • ExposureTime: 0.025
  • ISOSpeedRatings: 102
  • ComponentsConfiguration: YCbCr
  • FNumber: 2.9
  • GPSImgDirection: 105
  • GPSImgDirectionRef: M
  • GPSLatitudeRef: N
  • GPSLatitude: 59,19,6.7941
  • GPSLongitudeRef: E
  • GPSLongitude: 18,3,35.5311
  • GPSAltitudeRef: 0
  • GPSAltitude: 0
  • GPSTimeStamp: 14,6,10
  • GPSProcessingMethod: ASCIIFUSED
  • GPSDateStamp: 2014:10:19

I explained that this might be an issue in the case of nude photos people put online in my TEDx talk on making social media social again and showed that there is a command line tools called EXIFtool that allows for stripping out this extra data. This article describes other tools that do the same. EXIFtool is the 800 pound gorilla of this task as it allows you to edit EXIF data.

As a lot of people asked me for a tool to do this, I wanted to make it easier for you without having to resort to an installable tool. Enter

Remove photo data in action

This is a simple web page that allows you to pick an image from your hard drive, see the data and save an image with all the data stripped by clicking a button. You can see it in action in this screencast

Under the hood, all I do is use Jacob Seidelin’s EXIF.js and copy the photo onto a CANVAS element to read out the raw pixel data without any of the extra information. The source code is on GitHub.

The tool does not store any image data and all the calculations and information gathering happens on your computer. Nothing gets into the cloud or onto my server.

So go and drag and drop your images there before uploading them. Be safe® out there.

Categorieën: Mozilla-nl planet

Karl Dubost: Monitoring Web page differences on a long term with screenshots

di, 21/10/2014 - 04:20

Hallvord has created a very nice system for testing regressions automatically. The results are displayed on Are We Compatible Yet?. I had explained in a blog post how to add or fix tests there.

I was reading yesterday another type of large scale testing for link rot on the UK Web. They share some of the challenges we meet in terms of guessing if the Web page has changed or not meaningfully. It's a very interesting read. They try at a point to determine if something is similar or dissimilar. Here what they say.

The easy case is when the content is exactly the same – we can just record that the resources are identical at the binary level. If not, we extract whatever text we can from the archived and live URLs, and compare them to see how much the text has changed. To do this, we compute a fingerprint from the text contained in each resource, and then compare those to determine how similar the resources are. This technique has been used for many years in computer forensics applications, such as helping to identify ‘bad’ software, and here we adapt the approach in order to find similar web pages.

Specifically, we generate ssdeep ‘fuzzy hash’ fingerprints, and compare them in order to determine the degree of overlap in the textual content of the items. If the algorithm is able to find any similarity at all, we record the result as ‘SIMILAR’. Otherwise, we record that the items are ‘DISSIMILAR’.

I remember in the past for a talk I had given about quality on how to use selenium to take screenshots at different stages of the development and check if the rendering was the same. One way to evaluate the differences is to create a comparison of the images by first taking a screenshot

from selenium import webdriver browser = webdriver.Firefox() browser.get('') browser.save_screenshot('moz-home.png') browser.close()

And then, if you get multiple screenshots of the same page, to compare two images. Such as the reference image and the new screenshot:

def diff_ratio(screen_ref, screen_new): s = difflib.SequenceMatcher(None, s1, s2) return s.quick_ratio()

SequenceMatcher is a tool for comparing pairs of sequences of any type and quick_ratio return an upper bound on .ratio() relatively quickly, which is a measure of the sequences' similarity (float in [0,1]). Just to give an example of the type of results.

import difflib a = 'Life is a long slow river.' b = 'Life is among slow rivers.' s = difflib.SequenceMatcher(None, a, b) s.quick_ratio() # returns 0.9230769230769231 s2 = difflib.SequenceMatcher(None, a, a) s2.quick_ratio() # returns 1.0

So if the images are quite similar it will return a number close to 1.

And For Web Compatibility Issues?

Most of our use cases are Web sites not sending the right version of the Web site, such as desktop content instead of the mobile version. So I was wondering if we could have a very quick check which would involve less human checking during our surveys of sites for certain countries.

One possible challenge (among maybe many) is Website relying heavily on advertisements and sending different images. In this case, the site would be different even if sending the same version.

Another one is press Web sites, changing the content of the home page quite often.

Maybe it's worth testing. Maybe we would get an acceptable ratio.


I had forgotten but Hallvord did that already for quickly selecting the screenshots which were worth testing. He added:

I suppose we could explore stuff like hashing all the CSS code included in a page and compare hashes to find different styling. Although my next project is going to be using Compatipede 2, finding all the elements in a DOM that are styled with -webkit- properties or values, then generate XPath identifiers or JS to locate the same element and see if it has equivalent styles when the page loads in a different rendering engine.


Categorieën: Mozilla-nl planet