Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Daniel Stenberg: Why curl defaults to stdout

Mozilla planet - mo, 17/11/2014 - 10:11

(Recap: I founded the curl project, I am still the lead developer and maintainer)

When asking curl to get a URL it’ll send the output to stdout by default. You can of course easily change this behavior with options or just using your shell’s redirect feature, but without any option it’ll spew it out to stdout. If you’re invoking the command line on a shell prompt you’ll immediately get to see the response as soon as it arrives.

I decided curl should work like this, and it was a natural decision I made already when I worked on the predecessors during 1997 or so that later would turn into curl.

On Unix systems there’s a common mantra that “everything is a file” but also in fact that “everything is a pipe”. You accomplish things on Unix by piping the output of one program into the input of another program. Of course I wanted curl to work as good as the other components and I wanted it to blend in with the rest. I wanted curl to feel like cat but for a network resource. And cat is certainly not the only pre-curl command that writes to stdout by default; they are plentiful.

And then: once I had made that decision and I released curl for the first time on March 20, 1998: the call was made. The default was set. I will not change a default and hurt millions of users. I rather continue to be questioned by newcomers, but now at least I can point to this blog post! :-)

About the wget rivalry

cURLAs I mention in my curl vs wget document, a very common comment to me about curl as compared to wget is that wget is “easier to use” because it needs no extra argument in order to download a single URL to a file on disk. I get that, if you type the full commands by hand you’ll use about three keys less to write “wget” instead of “curl -O”, but on the other hand if this is an operation you do often and you care so much about saving key presses I would suggest you make an alias anyway that is even shorter and then the amount of options for the command really doesn’t matter at all anymore.

I put that argument in the same category as the people who argue that wget is easier to use because you can type it with your left hand only on a qwerty keyboard. Sure, that is indeed true but I read it more like someone trying to come up with a reason when in reality there’s actually another one underneath. Sometimes that other reason is a philosophical one about preferring GNU software (which curl isn’t) or one that is licensed under the GPL (which wget is) or simply that wget is what they’re used to and they know its options and recognize or like its progress meter better.

I enjoy our friendly competition with wget and I seriously and honestly think it has made both our projects better and I like that users can throw arguments in our face like “but X can do Y”and X can alter between curl and wget depending on which camp you talk to. I also really like wget as a tool and I am the occasional user of it, just like most Unix users. I contribute to the wget project well, both with code and with general feedback. I consider myself a friend of the current wget maintainer as well as former ones.

Categorieën: Mozilla-nl planet

Andreas Gal: VP8 and H.264 to both become mandatory for WebRTC

Mozilla planet - snein, 16/11/2014 - 23:39

WebRTC is one of the most exciting things to happen to the Web in years: it has the potential to bring instant voice and video calling to anyone with a browser, finally unshackling us from proprietary plugins and installed apps. Firefox, Chrome, and Opera already support WebRTC, and Microsoft recently announced future support.

Unfortunately, the full potential of the WebRTC ecosystem has been held back by a long-running disagreement about which video codec should be mandatory to implement. The mandatory to implement audio codecs were chosen over two years ago with relatively little contention: the legacy codec G.711 and Opus, an advanced codec co-designed by Mozilla engineers. The IETF RTCWEB Working Group has been deadlocked for years over whether to pick VP8 or H.264 for the video side.

Both codecs have merits. On the one hand, VP8 can be deployed without having to pay patent royalties. On the other hand, H.264 has a huge installed base in existing systems and hardware. That is why we worked with Cisco to develop their free OpenH264 plugin and as of October this year, Firefox supports both H.264 and VP8 for WebRTC.

At the last IETF meeting in Hawaii the RTCWEB working group reached strong consensus to follow in our footsteps and make support for both H.264 and VP8 mandatory for browsers. This compromises was put forward by Mozilla, Cisco and Google. The details are a little bit complicated, but here’s the executive summary:

  • Browsers will be required to support both H.264 and VP8 for WebRTC.
  • Non-browser WebRTC endpoints will be required to support both H.264 and VP8. However, if either codec becomes definitely royalty free (with no outstanding credible non-RF patent claims) then endpoints will only have to do that codec.
  • “WebRTC-compatible” endpoints will be allowed to do either codec, both, or neither.

See the complete proposal by Mozilla Principal Engineer Adam Roach here. There are still a few procedural issues to resolve, but given the level of support in the room, things are looking good.

We believe that this compromise is the best thing for the Web at this time: It lets us move forward with confidence in WebRTC interoperability and allows people who for some reason or another really can’t do one of these two codecs to be “WebRTC-compatible” and know they can interoperate with any WebRTC endpoint. This is an unmitigated win for users and Web application developers, as it provides broad interoperability within the WebRTC ecosystem.

It also puts a stake in the ground that what the community really needs is a codec that everyone agrees is royalty-free, and provides a continuing incentive for proponents of each codec to work towards this target.

Mozilla has been working for some time on such a new video codec which tries to avoid the patent thickets around current codec designs while surpassing the quality of the latest royalty-bearing codecs. We hope to contribute this technology to an IETF standardization effort following the same successful pattern as with Opus.

Filed under: Mozilla Tagged: Mozilla, VP8, WebRTC
Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2014-11-16 Calendar builds

Thunderbird - snein, 16/11/2014 - 18:20

Common (excluding Website bugs)-specific: (11)

  • Fixed: 373562 – All day events should be printed at the top
  • Fixed: 610152 – Events randomly disappear from the view pane. View returns when TB is restarted.
  • Fixed: 723906 – 301 on PUT only partially honored
  • Fixed: 947615 – Event description shows escaped comma and line breaks
  • Fixed: 985863 – Event dialog: setFieldValue: aElement.removeAttribute couldn’t remove disabled from null e: TypeError: aElement is null
  • Fixed: 992669 – Navigation bar’s label “Current Week” (CW CWs) sometimes is set with a wrong week number
  • Fixed: 1074159 – Freebusy requests fail with Google CalDAV if the first calendar in the realm is disabled
  • Fixed: 1074645 – ReferenceError: acceptDialog is not defined [TEST-UNEXPECTED-FAIL | testTodayPane.js | testTodayPane.js::testTodayPane] [TEST-UNEXPECTED-FAIL | testLocalICS.js | testLocalICS.js::testLocalICS]
  • Fixed: 1075048 – During Build, lightning is installed in wrong directory
  • Fixed: 1084474 – Views are broken [Error: NS_NOINTERFACE accessing nsIScrollBoxObject in calendar-multiday-view.xml]
  • Fixed: 1090784 – Calendar xpcshell tests fail with ReferenceError: _passedChecks is not defined at …/calendar/test/unit/head_consts.js:217

Sunbird will no longer be actively developed by the Calendar team.

Windows builds Official Windows

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac

Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2014-11-16 Thunderbird comm-central builds

Thunderbird - snein, 16/11/2014 - 18:18

Thunderbird-specific: (58)

  • Fixed: 118798 – News message read should be centered in list pane
  • Fixed: 456663 – (Re)move |pref(“mailnews.ui.threadpane.version”, 1);|
  • Fixed: 511625 – move other actions button in line with header buttons (chevron like)[polish]
  • Fixed: 778907 – Highlighting/selecting 18000+ of emails inside a folder keeps giving the javascript is unresponsive script warning message, because TB is building the summary pane.
  • Fixed: 779714 – mail.tabs.autoHide=true causes tilebar is too narrow after australis tab design
  • Fixed: 789397 – searching virtual folder. crash in nsACString_internal::Assign due to out of range access from nsMsgSearchSession::GetNextUrl. Often compact related.
  • Fixed: 837205 – Put more space or separator between “delete” and the print preview menu items in the context menu (right-click) or move “delete” to somewhere else.
  • Fixed: 912116 – A 6×6-pixel context menu appears when you right-click in a message folder where there are no messages
  • Fixed: 929903 – place cursor in Address Book search field upon open, instead of focus on first contact in address book
  • Fixed: 938829 – optimize attachmentWorker.onmessage to not construct the whole attachment notification bar when it is already shown
  • Fixed: 956101 – Thunderbird data is missing from
  • Fixed: 970456 – Recipient autocomplete: Implement scoring algorithm to prioritize “beginsWith” wordwise matches over “contains” matches: search for “be” should toplist “Ben” and “Betty” over “HolBErt” (having “be” in the middle of word)
  • Fixed: 986078 – Menupopup of “Default font” isn’t using the full width, cuts of font-names
  • Fixed: 1000775 – For AB Quicksearch / contacts side bar, implement split multiword search pattern (*foo* AND *bar* for XXL search power; port bug 558931 to AB)
  • Fixed: 1003716 – Update character encoding-related pref UI not to use the nsCharsetMenu RDF data source
  • Fixed: 1018259 – Thunderbird should stop using SHA-1 when signing email messages
  • Fixed: 1025488 – Clickable area of some preferences too large
  • Fixed: 1039003 – Port |Bug 633773 – Use Google’s HTTPS search by default|, |Bug 958883 – Use HTTPS for Yahoo searches| and search plugin parts of |Bug 959576 – Create a component to get the list of priority domains| to Thunderbird
  • Fixed: 1039714 – TEST-UNEXPECTED-FAIL | test-attachment-reminder.js | test-attachment-reminder.js::test_attachment_reminder_appears_properly
  • Fixed: 1043784 – after confirming autocomplete suggestion with TAB key combination, Thunderbird adds a new addressing line, does not move focus to the subject text box
  • Fixed: 1045753 – Compose email LDAP erases text (autocompletes to blank entry when result email not set)
  • Fixed: 1052062 – Error console doesn’t show all error messages shown by remote debugging
  • Fixed: 1052396 – Error after creating profile (while there are still no accounts): “Error in setting AccountCentral Items: TypeError: server is null”
  • Fixed: 1052464 – error when adding first account: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgAccountManager.defaultAccount]” mailInstrumentation.js in minst_postStateObject line 101
  • Fixed: 1052566 – Opening ‘File’ menu without account configured throws exception: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgAccountManager.defaultAccount] mail3PaneWindowCommands.js :: IsSendUnsentMsgsEnabled
  • Fixed: 1053121 – [10.10] Add vibrancy to the folderpane.
  • Fixed: 1053761 – L10n nightly builds failing post build changes
  • Fixed: 1056649 – Port |Bug 559505 – localstore.rdf kills ponies| to Thunderbird
  • Fixed: 1059927 – Extend the inverted icon logic from bug 1046563 to AB, Composer and Lightning
  • Fixed: 1076773 – ReferenceError: EnableDisableAllowedReceipts is not defined in receipts.xul
  • Fixed: 1078003 – Port bug 1076926 to TB – Add windows 10 support to exe manifest
  • Fixed: 1080587 – Freeze current set of Hightail users
  • Fixed: 1081400 – l10n packager error since new file structure
  • Fixed: 1081818 – The Spell Check Dialog in Thunderbird Message Compose to small for long words. Make it resizable.
  • Fixed: 1084109 – displayStatusText() is not implemented in Thunderbird
  • Fixed: 1084633 – Sender name shown for sessionstart messages as well as messages without a sender name in search results.
  • Fixed: 1084974 – Appmenu styling is incorrect on OS X 10.10
  • Fixed: 1085003 – JavaScript error: chrome://messenger/content/systemIntegrationDialog.xul, line 1: ReferenceError: gSystemIntegrationDialog is not defined
  • Fixed: 1085762 – MozMill test step “get buildId” is failing to find the application.ini / doesn’t run tests due to path changes
  • Fixed: 1086605 – JavaScript error: chrome://messenger/content/editContactOverlay.js, line 166: TypeError: Components.interfaces.nsIPopupBoxObject is undefined [TEST-UNEXPECTED-FAIL | test-message-header.js | test-message-header.js::test_address_book_switch_disabled_on_con
  • Fixed: 1087529 – Revert do not track preferences to be a simple on/off switch
  • Fixed: 1087627 – Perma-orange on Thunderbird-Trunk: TEST-UNEXPECTED-FAIL | C:/slave/test/build/tests/xpcshell/tests/services/datareporting/tests/xpcshell/test_client_id.js | TypeError: Cc[';1'] is undefined
  • Fixed: 1089025 – C-C TB: Chrome file doesn’t exist: chrome/toolkit/content/global/charsetOverlay.js
  • Fixed: 1089410 – Package failures because of move from content/ to dom/
  • Fixed: 1089426 – Remove the blueish background on AB’s abResultsTree and CardViewBox on Win7
  • Fixed: 1092200 – Thunderbird crashing on start in HTMLInputElement.cpp:193
  • Fixed: 1092539 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/dom/tv/test/xpcshell/test_tv_tuner_data.js
  • Fixed: 1092584 – Fix Thunderbird’s OS X disclosure button styling once bug 1085134 is resolved
  • Fixed: 1092627 – _testLogger in test-folder-display-helpers.js should be also renamed.
  • Fixed: 1092811 – Print Preview not working in Thunderbird and SeaMonkey since Bug 1082575
  • Fixed: 1092815 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/toolkit/mozapps/update/tests/unit_base_updater/marAppApplyUpdateSuccess.js + marAppApplyUpdateStageSuccess.js
  • Fixed: 1095121 – Error when running Mozmill tests: “SyntaxError: const declaration not directly within block” due to const changes
  • Fixed: 1095297 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/mozmill/content-tabs/test-install-xpi.js | test-install-xpi.js::test_install_corrupt_xpi
  • Fixed: 1095918 – Improve chat input box styling for OS X
  • Fixed: 1097484 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/toolkit/components/places/tests/unifiedcomplete/test_swap_protocol.js
  • Fixed: 1097486 – Mozmill tests failed with the message ‘Exception: Sorry, cannot connect to jsbridge extension, port 24242′
  • Fixed: 1097748 – Thunderbird Daily failing to start, with “Couldn’t load XPCOM.” error
  • Fixed: 1098021 – TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/dom/base/test/unit/test_cspreports.js

MailNews Core-specific: (37)

  • Fixed: 132453 – Multi select cards and the Properties button should be disabled
  • Fixed: 166860 – Incorrect comparison in morkNode.cpp
  • Fixed: 243833 – Attachments of Content-Type: application/pkcs7-mime that contain non-standard contents fail to decode and are not shown
  • Fixed: 255948 – Remove stored password after the account is deleted.
  • Fixed: 304917 – Permanent Redirect from an RSS feed should update the stored URL
  • Fixed: 323911 – should not play sound when new feed items arrive
  • Fixed: 659244 – p7m attachments are skipped in printing
  • Fixed: 718279 – Collapsed Thread lines colored according to tags inside
  • Fixed: 733535 – selecting an empty mailing list causes an error “cards[i] is null”
  • Fixed: 765803 – Reply above quote (no signature, HTML composition) no longer leaves a blank line
  • Fixed: 902158 – crash in nsInterfaceRequestorAgg::Release / NS_ProxyRelease at 0x5a5a5a5a
  • Fixed: 935934 – Filter log don’t give infos about filtered mails (No From:/Subject:/Message-ID: data and 1970/01/01 as Date in filter move log, when “Filter before Junk Classification” is used )
  • Fixed: 936466 – React to the removal of TIS-620, ISO-8859-11 and ISO-8859-9
  • Fixed: 1048872 – L10n builds broken on comm-central (34.0a1 builds)
  • Fixed: 1050840 – “Maximum number of server connections to cache” advanced account setting defaults to 1 for new accounts
  • Fixed: 1053782 – Add a Learn more link to the support page in feeds subscribe dialog
  • Fixed: 1054252 – wrong values in From and Recipient columns in message list due to improper RFC 2047 decoding / parsing order
  • Fixed: 1059171 – Make the editor field of nsIMsgCompose read-write
  • Fixed: 1062559 – Port |Bug 1055627 – Pass MOZ_GLUE_PROGRAM_LDFLAGS after STATIC_LIBS to linker| to c-c
  • Fixed: 1069819 – Update newsblog to address non-backward compatible changes to JS let semantics
  • Fixed: 1071754 – Filter to move messages to IMAP folder on getting new mail doesn’t work unless Filter after Junk Classification is selected
  • Fixed: 1074711 – mach configure calls unsupported MSYS make instead of mozmake [error processing mozbuild file: illegal file access outside of the top source directory: /..\{suite|mail}/app.mozbuild]
  • Fixed: 1075913 – Select proper (currently used) account in account manager when possible.
  • Fixed: 1079783 – OAuth2 forgets token when offline and a few other minor OAuth2.jsm fixes
  • Fixed: 1082237 – Port |Bug 1077212 – Move MOZ_FOLD_LIBS to configure| to comm-central
  • Fixed: 1083941 – Port Bug 1041180 (Remove deprecated nsIChannelPolicy) to comm-central MailNews
  • Fixed: 1084481 – Build error: ‘NS_NewInputStreamChannel’ : no overloaded function takes 4 arguments
  • Fixed: 1085151 – char signed vs unsigned build failures
  • Fixed: 1085562 – TEST-UNEXPECTED-FAIL | ../../../resources/logHelper.js | Error console says [stackFrame [Exception… “Failure arg 0 [nsITreeView.setTree]” nsresult: “0x80004005 (NS_ERROR_FAILURE)” location: “JS frame :: /builds/slave/test/build/tests/xpcshell/tests/mai
  • Fixed: 1086705 – -Werror=switch causes TB build failure
  • Fixed: 1087322 – New mail notification on OS X shuts down during xpcom-shutdown, should use profile-before-change
  • Fixed: 1087409 – FORCE_PR_LOG is now globally defined
  • Fixed: 1088497 – Implement NewChannel2 in mailnews
  • Fixed: 1091077 – gloda test timeout: TEST-UNEXPECTED-TIMEOUT | C:/slave/test/build/tests/xpcshell/tests/mailnews/db/gloda/test/unit/test_cleanup_msf_databases.js | Test timed out
  • Fixed: 1092625 – TEST-UNEXPECTED-FAIL | C:/slave/test/build/tests/xpcshell/tests/mailnews/mime/jsmime/test/test_mime_tree.js | xpcshell return code: 0
  • Fixed: 1094560 – Use m-c instead of a clone
  • Fixed: 1096778 – Include browser-element.xpt that defines the nsIBrowserElementAPI interface

Windows builds Official Windows, Official Windows installer

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac

Categorieën: Mozilla-nl planet

Kartikaya Gupta: Killing the office suite

Mozilla planet - sn, 15/11/2014 - 17:44

Have you ever had the experience of trying to write a document in MS Word (or Open/LibreOffice) and it keeps "correcting" your formatting to something you don't want? The last time I experienced that was about a year ago, and that was when I decided "screw it, I'll just write this in HTML instead". That was a good decision.

Pretty much anything you might want to use a word processor for, you can do in HTML - and oftentimes it's simpler. Sure, there's a bit of a learning curve if you don't know HTML, but that's true for anything. Now anytime I need to create "a document" (a letter, random notes or signs to print, etc.) I always do it in HTML rather than LibreOffice, and I'm the happier for it. I keep all my data in git repositories, and so it's a bonus that these documents are now in a plaintext format rather than a binary blob.

I realized that this is probably part of a trend - a lot of people I know nowadays to "powerpoint" presentations using web technologies such as reveal.js. I haven't seen many people comment on using web tech to do word processing, but I know I do it. The only big "office suite" thing left is the spreadsheet. It would be awesome if somebody wrote a drop-in JS spreadsheet library that you could include into a HTML page and instantly turn a table element into a spreadsheet.

I'm reminded of this old blog post by Joel Spolsky: How Trello is different. He talks about most of the people who use Excel really just use it because it provides a table format for entering things, rather than it's computational ability. HTML already provides that, but whenever I've tried doing that I find the markup/content ratio too high, so it always seemed like a pain. It would be nice to have a WSYIWYG tool that let you build a table (or spreadsheet) and import/export it as raw HTML that you can publish, print, share, etc.

As an addendum, that blog post by Joel also introduced me to the concept of unshipped code as "inventory", which is one of the reasons I really hate finding old bugs sitting around in Bugzilla with perfectly good patches that never landed!

Categorieën: Mozilla-nl planet

Software-update: Mozilla Firefox 33.1.1 - Tweakers

Nieuws verzameld via Google - sn, 15/11/2014 - 11:41

Software-update: Mozilla Firefox 33.1.1
Mozilla Firefox 2013 logo (75 pix) Mozilla heeft een update voor versie 33.1 van zijn webbrowser Firefox uitgebracht. In versie 33.1 is onder meer een "vergeet me"-knop toegevoegd. Hiermee is het mogelijk om de laatste vijf minuten, twee uur of zelfs ...

en meer »
Categorieën: Mozilla-nl planet

Niko Matsakis: Allocators in Rust

Mozilla planet - sn, 15/11/2014 - 03:13

There has been a lot of discussion lately about Rust’s allocator story, and in particular our relationship to jemalloc. I’ve been trying to catch up, and I wanted to try and summarize my understanding and explain for others what is going on. I am trying to be as factually precise in this post as possible. If you see a factual error, please do not hesitate to let me know.

The core tradeoff

The story begins, like all interesting design questions, with a trade-off. The problem with trade-offs is that neither side is 100% right. In this case, the trade-off has to do with two partial truths:

  1. It is better to have one global allocator than two. Allocators like jemalloc, dlmalloc, and so forth are all designed to be the only allocator in the system. Of necessity they permit a certain amount of “slop”, allocating more memory than they need so that they can respond to requests faster, or amortizing the cost of metadata over many allocations. If you use two different allocators, you are paying those costs twice. Moreover, the allocator tends to be a hot path, and you wind up with two copies of it, which leaves less room in the instruction cache for your actual code.
  2. Some allocators are more efficient than others. In particular, the default allocators shipped with libc on most systems tend not to be very good, though there are exceptions. One particularly good allocator is jemalloc. In comparison to the default glibc or windows allocator, jemalloc can be noticeably more efficient both in performance and memory use. Moreover, jemalloc offers an extended interface that Rust can take advantage of to gain even more efficiency (for example, by specifying the sizes of a memory block when it is freed, or by asking to reallocate memory in place when possible).

Clearly, the best thing is to use just one allocator that is also efficient. So, to be concrete, whenever we produce a Rust executable, everyone would prefer if that Rust executable – along with any C code that it uses – would just use jemalloc everywhere (or whatever allocator we decide is ‘efficient’ tomorrow).

However, in some cases we can’t control what allocator other code will use. For example, if a Rust library is linked into a larger C program. In this case, we can opt to continue using jemalloc from within that Rust code, but the C program may simply use the normal allocator. And then we wind up with two allocators in use. This is where the trade-off comes into play. Is it better to have Rust use jemalloc even when the C program within which Rust is embedded does not? In that case, the Rust allocations are more efficient, but at the cost of having more than one global allocator, with the associated inefficiencies. I think this is the core question.

Two extreme designs

Depending on whether you want to prioritize using a single allocator or using an efficient allocator, there are two extreme designs one might advocate for the Rust standard library:

  1. When Rust needs to allocate memory, just call malloc and friends.
  2. Compile Rust code to invoke jemalloc directly. This is what we currently do. There are many variations on how to do this. Regardless of which approach you take, this has the downside that when Rust code is linked into C code, there is the possibility that the C code will use one allocator, and Rust code another.

It’s important to clarify that what we’re discussing here is really the default behavior, to some extent. The Rust standard library already isolates the definition of the global allocator into a particular crate. End users can opt to change the definition of that crate. However, it would require recompiling Rust itself to do so, which is at least a mild pain.

Calling malloc

If we opted to default to just calling malloc, this does not mean that end users are locked into the libc allocator or anything like that. There are existing mechanisms for changing what allocator is used at a global level (though I understand this is relatively hard on Windows). Presumably when we produce an actual Rust executables, we would default to using jemalloc.

Calling malloc has the advantage that if a Rust library is linked into a C program, both of them will be using the same global allocator, whatever it is (unless of course that C program itself doesn’t call malloc).

However, one downside of this is that we are not able to take advantage of the more advanced jemalloc APIs for sized deallocation and reallocation. This has a measureable effect in micro-benchmarks. I am not aware of any measurements on larger scale Rust applications, but there are definitely scenarios where the advanced APIs are useful.

Another potential downside of this approach is that malloc is called via indirection (because it is part of libc; I’m a bit hazy on the details of this point, and would appreciate clarification). This implies a somewhat higher overhead for calls to malloc/free than if we fixed the allocator ahead of time. It’s worth noting that this is the normal setup that all C programs use by default, so relative to a typical C program, this setup carries no overhead.

(When compiling a statically linked executables, rustc could opt to redirect malloc and friends to jemalloc at this point, which would eliminate the indirection overhead but not take advantage of the specialized jemalloc APIs. This would be a simplified variant of the hybrid scheme I eventually describe below.)

Calling jemalloc directly

If we opt to hardcode Rust’s default allocator to be jemalloc, we gain several advantages. The performance of Rust code, at least, is not subject to the whims of whatever global allocator the platform or end-user provides. We are able to take full advantage of the specialized jemalloc APIs. Finally, as the allocator is fixed to jemalloc ahead of time, static linking scenarios do not carry the additional overhead that calling malloc implies (though, as I noted, one can remove that overhead also when using malloc via a simple hybrid scheme).

Having Rust code unilatelly call jemalloc also carries downsides. For example, if Rust code is embedded as a library, it will not adopt the global allocator of the code that it is embedded within. This carries the performance downsides of multiple allocators but also a certain amount of risk, because a pointer allocated on one side cannot be freed on the other (some argue this is bad practice; this is certainly true if you do not know that the two sides are using the same allocator, but is otherwise legitimate, see the section below for more details).

The same problem can also occur in reverse, when C code is used from within Rust. This happens today with rustc: due to the specifics of our setup, LLVM uses the system allocator, not the jemalloc allocator that Rust is using. This causes extra fragmentation and memory consumption. It’s also not great because jemalloc is better than the system allocator in many cases.

To prefix or not to prefix

One specific aspect of calling jemalloc directly concerns how it is built. Today, we build jemalloc using name prefixes, effectively “namespacing” it so that it does not interfere with the system allocator. This is what causes LLVM to use a different allocator in rustc. This has the advantage of clarity and side-stepping certain footguns around dynamic linking that could otherwise occur, but at the cost of forking the allocators.

A recent PR aimed to remove the prefix. It was rejected because in a dynamic linking scenario, this creates a fragile situation. Basically, the dynamic library (“client”) defines malloc to be jemalloc. The host process also has a definition for malloc (the system allocator). The precise result will depend on the flags and platform that you’re running on, but there are basically two possible outcomes, and both can cause perfectly legitimate code to crash:

  1. The host process wins, malloc means the same thing everywhere (this occurs on linux by default).
  2. malloc means different things in the host and the client (this occurs on mac by default, and on linux with the DEEPBIND flag).

In the first case, crashes can arise if the client code should try to intermingle usage of the nonstandard jemalloc API (which maps to jemalloc) with the standard malloc API (which the client believes to also be jemalloc, but which has been remapped to the system allocator by the host). The jemalloc documentation isn’t 100% explicit on the matter, but I believe it is legal for code to (e.g.) call mallocx and then call free on the result. Hence if Rust should link some C code that did that, it would crash under the first scenario.

In the second case, crashes can arise if the host/client attempt to transfer ownership of memory. Some claim that this is not a legitimate thing to do, but that is untrue: it is (usually) perfectly legal for client code to (e.g.) call strdup and then pass the result back to the host, expecting the host to free it. (Granted, it is best to be cautious when transfering ownership across boundaries like this, and one should never call free on a pointer unless you can be sure of the allocator that was used to allocate that pointer in the first place. But if you are sure, then it should be possible.)

Fundamentally, the problems here are due to the fact that the client is attempting to redefine the allocator on behalf of the host. Forcing this kind of name conflict to occur intentionally seems like a bad idea if we can avoid it.

A hybrid scheme

There is also the possibility of various hybrid schemes. One such option that Alex Crichton and I put together, summarized in this gist, would be to have Rust call neither the standard malloc nor the jemalloc symbols, but rather an intermediate set of APIs (let’s call them rust_alloc). When compiling Rust libraries (“rlibs”), these APIs would be unresolved. These rust allocator APIs would take all the information they need to take full advantage of extended jemalloc APIs, if they are available, but could also be “polyfilled” using the standard system malloc interface.

So long as Rust libraries are being compiled into “rlibs”, these rust_alloc dependencies would remain unresolved. An rlib is basically a statically linked library that can be linked into another Rust program. At some point, however, a final artifact is produced, at which point the rust_alloc dependency must be fulfilled. The way we fulfill this dependency will ultimately depend on what kind of artifact is produced:

  • Static library for use in a C program: link rust_alloc to malloc
  • Dynamic library (for use in C or Rust): link rust_alloc to malloc
  • Executable: resolve rust_alloc to jemalloc, and override the system malloc with jemalloc as well.

This seems to offer the best of both worlds. Standalone, statically linked Rust executables (the recommended, default route) get the full benefit of jemalloc. Code that is linked into C or dynamically loaded uses the standard allocator by default. Any C code used from within Rust executables will also call into jemalloc as well.

However, there is one major caveat. While it seems that this scheme would work well on linux, the behavior on other platforms is different, and it’s not yet clear if the same scheme can be made to work as well on Mac and Windows.

Naturally, even if we sort out the cross-platform challenges, this hybrid approach too is not without its downsides. It means that Rust code built for libraries will not take full advantage of what jemalloc has to offer, and in the case of dynamic libraries there may be more overhead per malloc invocation than if jemalloc were statically linked. However, by the same token, Rust libraries will avoid the overhead of using two allocators and they will also be acting more like normal C code. And of course the embedding program may opt, in its linking phase, to redirect malloc (globally) to jemalloc.

So what should we do?

The decision about what to do has a couple of facets. In the immediate term, however, we need to take steps to improve rustc’s memory usage. It seems to me that, at minimum, we ought to accept strcat’s PR #18915, which ensures that Rust executables can use jemalloc for everything, at least on linux. Everyone agrees that this is a desirable goal.

Longer term, it is somewhat less clear. The reason that this decision is difficult is that there is no choice that is “correct” for all cases. The most performant choice will depend on the specifics of the case:

  • Is the Rust code embedded?
  • How much allocation takes place in Rust vs in the other language?
  • What allocator is the other language using?

(As an example, the performance and memory use of rustc improved when we adopted jemalloc, even partially, but other applications will fare differently.)

At this point I favor the general principle that Rust code, when compiled as a library for use within C code, should more-or-less behave like C code would behave. This seems to suggest that, when building libraries for C consumption, Rust should just call malloc, and people can use the normal mechanisms to inject jemalloc if they so choose. However, when compiling Rust executables, it seems advantageous for us to default to a better allocator and to get the maximum efficiency we can from that allocator. The hybrid scheme aims to achieve both of these goals but there may be a better way to go about it, particularly around the area of dynamic linking.

I’d like to see more measurement regarding the performance impact of foregoing the specialized jemalloc APIs and using weak linking. I’ve seen plenty of numbers suggesting jemalloc is better than other allocators on the whole, and plenty of numbers saying that using specialized APIs helps in microbenchmarks. But it is unclear what the impact of such APIs (or weak linking) is on the performance of larger applications.

I’d also like to get the input from more people who have experience in this area. I’ve talked things over with strcat a fair amount, who generally favors using jemalloc even if it means two allocators. We’ve also reached out to Jason Evans, the author of jemalloc, who stressed the fact that multiple global allocators is generally a poor choice. I’ve tried to reflect their points in this post.

Note though that whatever we decide we can evolve it as we go. There is time to experiment and measure. One thing that is clear to me is that we do not want Rust to “depend on” jemalloc in any hard sense. That is, it should always be possible to switch from jemalloc to another allocator. This is both because jemalloc, good as it is, can’t meet everyone’s needs all the time, and because it’s just not a necessary dependency for Rust to take. Establishing an abstraction boundary around the “Rust global allocator” seems clearly like the right thing to do, however we choose to fulfill it.

Categorieën: Mozilla-nl planet

Patrick Cloke: Thunderbird Summit 2014

Mozilla planet - sn, 15/11/2014 - 00:37

Last month (Oct. 15th to Oct. 18th, to be precise), twenty volunteers descended on Mozilla’s Toronto office to discuss Mozilla Thunderbird. This included Mozilla employees, Thunderbird contributors of all sorts (developers, user interface designers, add-on reviewers), Lightning contributors, and chat/Instantbird contributors.

The entire group of volunteers.

It was great to spend some quality hacking time with Florian and to meet Nihanth, both Instantbird guys who I talk to most days on IRC! I also had the pleasure of re-meeting a few people from the Mozilla Summit last year (I attended in Toronto) and to meet some brand new people!

Nihanth hacking.  me, Florian and Nihanth. Daniel joining us over Vidyo.

A few pictures of the chat contributors: Nihanth; me, Florian and Nihanth; and Daniel (dialing in!)

It was really nice to actually sit down for a few days and work on Instantbird/Thunderbird without the distractions of "real life". I, unfortunately, spent the first day fixing an Instantbird bustage (from a mozilla-central change that removed some NSS symbols…why, I have no idea). But after that, we got some really exciting work done! We started cleaning up and finalizing some patches from Google Summer of Code 2014 to add WebRTC support to XMPP! You can check out the progress in bug 1018060.

First working call over Instantbird WebRTC. Screenshot of first working call over Instantbird WebRTC.

First working call over Instantbird WebRTC.

Eating some poutine!

Other highlights of the trip include eating the "Canadian delicacy" of poutine (with pulled pork on it)!

Categorieën: Mozilla-nl planet

Mozilla start met tonen van advertenties in Firefox - Techzine

Nieuws verzameld via Google - fr, 14/11/2014 - 16:32


Mozilla start met tonen van advertenties in Firefox
Mozilla heeft overeenkomsten gesloten met adverteerders en begint in 25 landen met het tonen van advertenties in de browser. De advertenties worden getoond in de "Enhanced Tiles"-weergave. Deze weergave verschijnt standaard wanneer je een nieuw ...
Mozilla start met tonen advertenties in FirefoxDe Morgen
Firefox gaat advertenties
Advertentieloze dagen FireFox zijn geteldAutomatisering Gids
alle 8 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Mozilla start met tonen advertenties in Firefox - De Morgen

Nieuws verzameld via Google - fr, 14/11/2014 - 15:42

De Morgen

Mozilla start met tonen advertenties in Firefox
De Morgen
Wel geeft Mozilla toe dat via de tegels gebruikersgegevens verzameld worden, maar deze zouden geanonimiseerd worden zodra de data binnen is. Daarnaast kunnen gebruikers de Directional Tiles eenvoudig uitschakelen door voor de klassieke weergave ...
Firefox gaat advertenties
Advertentieloze dagen FireFox zijn geteldAutomatisering Gids

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

Mozilla Reps Community: Reps Weekly Call – November 13rd 2014

Mozilla planet - fr, 14/11/2014 - 13:45

Last Thursday we had our regular weekly call about the Reps program, where we talk about what’s going on in the program and what Reps have been doing during the last week.


  • New Reps dashboard
  • Portal UX initiative
  • WoMoz update
  • FX10 celebrations

Detailed notes

AirMozilla video

Don’t forget to comment about this call on Discourse and we hope to see you next week!

Categorieën: Mozilla-nl planet

Doug Belshaw: MozFest Web Literacy Map roundup

Mozilla planet - fr, 14/11/2014 - 12:23

Because late is better than never, right?

Web literacy was, of course, a theme that ran through all of the Mozilla Festival this year. However, in this post I want to focus on a couple of sessions that focused specifically on the Web Literacy Map.

Prototypes and Pathways for Web Literacy

Session details (from schedule)

Karen Smith introducing the MozFest 2014 session 'Pathways & Prototypes for Web Literacy'

This session was led by Karen Smith, with me supporting. It was a practical, hands-on session where participants were able to chart learning pathways around the Privacy competency of the Web Literacy Map. This was based on a deliverable from the Badge Alliance working group on Digital & Web Literacies. We also used the recent UX Personas work to help frame the discussion.

 Pathways & Prototypes for Web Literacy

Participants were asked to choose a persona and stick it to a large sheet of paper. They then explored what things that person was likely to want around privacy, and which things they’d like to avoid.

Planning in the Pathways & Prototypes for Web Literacy session at MozFest 2014

We then went through the kinds of badges from the Badge Alliance deliverable, and participants were asked to construct pathways that would make sense in their persona’s context.

Pathways and Prototypes for Web Literacy at MozFest 2014

Towards v2 of Mozilla’s Web Literacy Map

Session details (from schedule)

Alvar Maciel's thinking around representations of the Web Literacy Map at MozFest 2014

I ran this session with community members Ibrahima Saar, Alvar Maciel, and Kim Wilkens. We led three groups of participants through the current Web Literacy Map and encouraged through what’s changed in the year since v1 was launched. What’s missing? How could it be better represented?

Talking, planning, eating in the MozFest 2014 session 'Toward v2 of Mozilla's Web Literacy Map'

We ended up with some interesting results. As you can see with the group above, they imagined the Mozilla Manifesto as being the roots of a ‘tree’ that also included additional competencies.

One way of graphically modelling web literacy from the MozFest 2014 session 'Toward v2 of Mozilla's Web Literacy Map'

Another group though three-dimensionally almost in terms of 'synapses’. The also experimented with a 'layered’ approach.

Outputs from MozFest 2014 session 'Toward v2 of Mozilla's Web Literacy Map'

The third group used 'refurbishing a house’ as an organising metaphor. The journey started by looking underneath the carpets, then exploring further…

Remotee challenge

My super-talented colleague Jess Klein unfortunately couldn’t be at MozFest, so she put together a number of 'remotee challenges’. One of these was how might we visualize the information in the Web Literacy Map?

Web Literacy visualization

It’s worth reading the whole thread, as there’s a lot of back-and-forth. I’d like to highlight a few things in particular:

We’ll be discussing these approaches in next Monday’s community call. The focus of that call is on looking at responses to Proposal 3 of the community survey: 'I believe the Web Literacy Map should look more like a 'map’.

Join us!

The canonical URL for all development relating to v2.0 of the Web Literacy Map is:

Comments? Questions? Direct them to or add them to the #TeachTheWeb discussion forum

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox 34 beta7 to beta8

Mozilla planet - fr, 14/11/2014 - 11:44

  • 28 changesets
  • 109 files changed
  • 4554 insertions
  • 219 deletions

ExtensionOccurrences cpp17 html11 js10 build9 h6 ini4 in4 xul3 xml3 webidl3 manifest3 html^headers^3 sh2 py2 mn2 jsm2 java2 idl2 txt1 mk1 list1 json1 conf1 c1 automation1 asan1

ModuleOccurrences security30 browser19 dom18 content12 mobile7 gfx6 b2g5 build4 toolkit3 tools1 testing1 modules1 media1

List of changesets:

Phil RingnaldaBug 978211 followup, make compare-mozconfig work on Win64 again, r=glandium a=NPOTB - 8201c42832ef Mike ShalBug 1072073 - pretty-l10n-check should also be -j1; r=glandium a=NPOTB - 6ab542eb236d Mike ShalBug 1013730 - Have mach ignore broken disk io stats; r=gps a=NPOTB - daabf4d8995f Mike ShalBug 1077597 - force -j1 for {pretty-}package-tests; r=glandium a=NPOTB - 8a6160e2ef98 Mike ShalBug 1084163 - Remove 'make check' from automation/build; r=glandium a=NPOTB - 5591e0a83c4d Mike ShalBug 1085026 - Use sha512 hashes for mar files; r=glandium a=NPOTB - 72d8ba95b2db Mike ShalBug 1087104 - Implement partial mar generation in make for 'mach build'; r=glandium a=NPOTB - ee2c3cfb4a7b Mike ShalBug 1087104 - Set the partialInfo property for Balrog; r=glandium a=NPOTB - dc18ad2b4816 David KeelerBug 1085509 - Add telemetry for how many permanent certificate overrides users have. r=mmc, r=jcj, a=lsblakk - 1f1e5b70a075 Christoph KerschbaumerBug 1069762 - Make CSP violation reports match the spec for redirects. r=sstamm, a=dveditz - b77384b124a4 Gavin SharpBug 1061736: add DuckDuckGo as a search engine option in Firefox, r=dolske, a=gavin - 2231ed05a1b8 Paul Kerr [:pkerr]Bug 1023539: Fix occasional timeouts of TURN webrtc transports with one-way connections r=bwc a=lmandel - d73c4671a18f Jan KeromnesBug 1011562 - Ship Firefox OS fonts in Mulet. r=mshal, a=NPOTB - 00f9c65b2f83 Gijs KruitboschBug 1062096 - browser_aboutHome should use a fake search engine instead of google to test FHR reporting. r=adw, a=test-only - e32540fb1289 Gijs KruitboschBug 1094421 - Prepend www. to the search suggestion URL to avoid intermittent timeouts. rs=Mossop,me, a=test-only - db6d19e2b8e6 Mark FinkleBug 883254 - Add the duckduckgo searchplugin. r=margaret, a=sledru - f1c1658280cd Nick AlexanderBug 883254 - Add the duckduckgo searchplugin to certain locales. f=glandium, r=mfinkle, a=sledru - 32c3529eb076 Markus StangeBug 1061327 - Don't stop searching for scrolled layers when encountering a ScrollInfoLayer. r=botond, a=lmandel - 0174d3047d1a Markus StangeBug 1061327 - When the scrolled layer is not an ancestor of the scrollbar layer, search the whole layer tree. r=botond, a=lmandel - eed413466305 Panos AstithasBug 1090967 - Don't use the Aurora-specific profile by default if this is not Aurora. r=bsmedberg, a=lmandel - 46829698a2b9 Gijs KruitboschBug 690307 - Make trimURL not generate URLs that parse back into search queries. r=mak, a=lmandel - ffb4891a237d Gijs KruitboschBug 690307 - Add more tests for the localhost + spaces case. r=mak, a=test-only - 9ebc7ee50a9c Margaret LeibovicBug 1093871 - Telemetry probe for number of items in reading list. r=rnewman, a=lmandel - f85f63d11f68 Dão GottwaldBug 1093368 - Customize mode theme picker shouldn't pass the default theme object to LightweightThemeManager.previewTheme. r=jaws, a=lmandel - fa1706ebf845 Jeff MuizelaarBug 1021265. Fix DisplayLink version expansion code. r=Bas,a=lawrence - 252c3ab238d0 Benoit GirardBug 1089380 - Remove ClipRectInLayersCoordinates. r=mattwoodrow, a=lmandel - 1e8f0a8c4474 David KeelerBug 1083118 - backout removal of unsafe, non-standardized legacy window.crypto functions r=bz a=lmandel ba=lmandel - fea4ac1165f9 David KeelerBug 1083118 - re-enable unsafe legacy window.crypto functions by default r=bz a=lmandel ba=lmandel - 87fd4f56cfed

Categorieën: Mozilla-nl planet

First Firefox OS Smartphones Available in the Philippines

Mozilla Blog - fr, 14/11/2014 - 07:51
Mozilla, the mission-based organization dedicated to promoting openness, innovation and opportunity on the Web, is happy to announce that Cherry Mobile will launch the first Firefox OS smartphone in the Philippines in the coming days. Cherry Mobile will offer the … Continue reading
Categorieën: Mozilla-nl planet

Jeff Walden: Ten years

Mozilla planet - fr, 14/11/2014 - 04:17

It was summer 2002, and I was on a bike tour across Michigan. For downtime reading I’d brought a bunch of unread magazines. One of the magazines I brought was a semi-recent PC Magazine with a review of the various browsers of the time. The major browsers were the focus, but a sidebar mentioned the Mozilla Suite and noted its being open source and open to downloads and contributions from anyone. It sounded unique and piqued my interest, so I filed the information away for future reference.

Sometime after I got home I downloaded a version of the Mozilla Suite: good, certainly better than Internet Explorer, but ponderous in its UI. I recommended it to a few people, but because of the UI somewhat half-heartedly, in an “if you can tolerate the UI, it’s better” sort of sense. Somehow I stumbled into downloading betas and later nightlies, and I began reading and triaging bugs, even reporting a few bugs (duplicates!) of my own.

Sometime later, probably through the MozillaZine default bookmark, I learned about Phoenix, the then-current name of the browser whose ultimate name would be Firefox. (Very shortly after this it acquired the Firebird name, which stuck for only a couple releases until the ultimate rename.) It seemed to do everything the Suite did (or at least everything I cared about) without the horrible UI. I began recommending it unreservedly to people, surreptitiously installing it on high school computers, and so on.

One notable lack in Firebird of the time was its lack of help documentation. Firebird was good stuff. I wanted to see it succeed. I could fix this. So I began contributing to the Firebird Help project that wrote built-in help documentation for the browser. At the time this was an external project whose contents were occasionally imported into the main tree. (I believe it later moved directly into the tree, although I’m not certain. Ultimately the entire system was replaced with fully-online documentation, which fixed a whole bunch of problems around ease of contribution — not least that I’d lost time to contribute to that particular aspect, mostly having moved onto other things in the project.) Thus began the start of several years of work writing help documentation describing various parts of the UI, including a late-breaking October 2004 weekend spent documenting the new preferences UI in 1.0 — in just before the buzzer!

I observed release day from a distance in my dorm room, but Air Mozilla made that experience more immediate than it might have been. (218 users on the IRC channel! How times have changed. Our main developer channel as I write this contains 448 people, and that seems pretty typical.) Air Mozilla wasn’t nearly as polished or streamlined as it is now. Varying-quality Creative Commons music as interludes between interviews, good times. But it was a start.

Air Mozilla on the Firefox 1.0 launch day (Ogg Vorbis). My first inclination is to say this was recorded by people on the ground in the release itself, and I downloaded it later. But on second thought, I can’t be certain I didn’t stream-capture live using VLC.

Ten years (and two internships, one proto-summit and two summits, and fulltime employment) later, I think it’s both surprising and unsurprising just how far Mozilla and Firefox have come. Surprising, in that entering a market where the main competitor has 95% of the market usually isn’t a winning strategy. (But you can’t win if you don’t try.) Yet also unsurprising, as Internet Explorer was really bad compared to its competition. (When released, IE6 was a really good browser, just as Tinderbox [now doubly-replaced] was once a really good continuous-integration system. But it’s not enough to be good at one instant.) And a serendipitously-timed wave of IE security vulnerabilities over summer 2003 helped, too. :-)

Here’s to another ten years and a new round of challenges.

Categorieën: Mozilla-nl planet

Yunier José Sosa Vázquez: Mozilla planea llevar la realidad virtual a Firefox

Mozilla planet - fr, 14/11/2014 - 03:46

A principios de este año Mozilla inició un proyecto para explorar las posibilidades de llevar la realidad virtual a la Web, y en junio lanzó una versión experimental de Firefox con soporte para Oculus Rift, uno de los más populares receptores de cabeza de realidad virtual.


MozVR tiene como objetivo compartir todo tipo de experiencias virtuales en la Web, proporcionar recursos y mostrar el trabajo de los desarrolladores en la creciente comunidad web relacionada con la realidad virtual. Permitiendo que los usuarios experimenten la potencia de las posibilidades de la RV en Internet. Hasta el momento han sido creados varios demos demostrando hasta donde puede llegar la creatividad humana, entre estos demos podemos encontrar: Sechelt (un vuelo en 3D basado en WebGL a través de la Columbia Británica) y The Polar Sea (un documental que llevará a los usuarios a través del ártico mediante videos de 360º).


Al visitar, los usuarios podrán seguir una serie de indicaciones para configurar y usar Oculus Rift sin problemas con Firefox. Para disfrutar de esta nueva experiencia, hay que utilizar una versión de Firefox que debe descargarse desde aquí, en estos momentos no tenemos disponible su descarga desde Firefoxmanía. En Mozilla también están trabajando para llevar la realidad virtual a Chromuim y su código fuente está publicado en GitHub.

Fuente: MozVR

Categorieën: Mozilla-nl planet

Mozilla WebDev Community: Webdev Extravaganza – November 2014

Mozilla planet - to, 13/11/2014 - 18:50

Once a month, web developers from across Mozilla get together to work on a sequel to The Pragmatic Programmer titled The Unhinged Technical Architect. While we argue over the use of oxford commas, we find time to talk about the work that we’ve shipped, share the libraries we’re working on, meet new folks, and talk about whatever else is on our minds. It’s the Webdev Extravaganza! The meeting is open to the public; you should stop by!

You can check out the wiki page that we use to organize the meeting, view a recording of the meeting in Air Mozilla, or attempt to decipher the aimless scrawls that are the meeting notes. Or just read on for a summary!

Shipping Celebration

The shipping celebration is for anything we finished and deployed in the past month, whether it be a brand new site, an upgrade to an existing one, or even a release of a library.

New Pages and The Open Standard

craigcook stopped by to share a bunch of new things that launched from the Web Productions team, including a new homepage and a new contribute page. He also mentioned The Open Standard, which was launched with support from the Web Productions team.

Sites using contribute.json

We heard from peterbe about a new listing of sites with a contribute.json file. The listing pulls info hourly from the contribute.json files for each site in the list. Pull requests are welcome to add more Mozilla sites to the list.

Humble Mozilla Bundle and Voxatron Snippet

Yours truly mentioned the Humble Mozilla Bundle, a promotion with Humble Bundle where we offered several popular games for purchase that can run within a web browser.

To promote the bundle, jgruen and other Mozillians worked with Joseph White to make a minimal port of the Voxatron for use in an about:home snippet. All told, the snippet was about 200kb large and still managed to cram in a full 3d voxel engine that Firefox users were able to play with on their home page.

Open-source Citizenship

Here we talk about libraries we’re maintaining and what, if anything, we need help with for them. Except this week there was nothing shared. Never mind!

New Hires / Interns / Volunteers / Contributors

Here we introduce any newcomers to the Webdev group, including new employees, interns, volunteers, or any other form of contributor.

Name IRC Nick Role Project Kristján Oddsson koddsson Volunteer and Roundtable

The Roundtable is the home for discussions that don’t fit anywhere else.


ErikRose wanted to use configobj and asked for opinions on the library. peterbe gave a positive recommendation based on his experience using it in configman.

Tabzilla Update Bar

mythmon wanted to let people know about a new feature in Tabzilla. You can now trigger a feature called the Update Bar, which notifies users on old versions of Firefox that they should update their browser. pmac also called out the Translation Bar, which offers localized versions of the current page to users viewing your site in a language that doesn’t match their preferred locale.

Workweek at Bernie’s

I also gave a reminder about the Webdev meetup happening at the Portland Coincidental Workweek, an event now known as the Workweek at Bernie’s. Follow that link for more details, and if you’re going to be at the workweek and want to attend, contact me to RSVP.

After skimming the back cover of The Pragmatic Programmer, we came up with an outline describing how our book can teach you how to:

  • Fight software;
  • Not just duplicate knowledge, but infinitely copy it for massive gains;
  • Write code so solid and enduring that it will run until AWS randomly kills your box;
  • Encourage programming by fate;
  • Nuke-proof your code using aspect-oriented programming and a few pounds of refrigerator-grade steel;
  • Capture real, living requirements for sale as folk medicine in foreign countries;
  • Test ruthlessly and physically punish any code that misbehaves;
  • Delight your users with micro-transactions;
  • Build teams of slouching young programmers wearing hoodies and jeans to attract investors; and
  • Automate yourself out of a job.

If you’re interested in web development at Mozilla, or want to attend next month’s Extravaganza, subscribe to the mailing list to be notified of the next meeting, and maybe send a message introducing yourself. We’d love to meet you!

See you next month!

Categorieën: Mozilla-nl planet

David Dahl: Crypton: The Privacy Framework

Mozilla planet - to, 13/11/2014 - 18:17

Crypton Logo

Since I left Mozilla last year, I have been working on Crypton ( ), an HTML5 application framework that places privacy above all else. Last month, my team was invited to the ‘Hack In The Box’, Malaysia security conference to lead a Lab Session on Crypton.

We were required to write a whitepaper for HiTB to publish, which was a great exercise, as my team has been meaning to write a paper for some time. It was a long trip, but worth it. We led a group of engineers through most of the Crypton API in about 2 hours.

I lived-coded the ‘skeleton’ of a messaging application in 74 lines of JavaScript. The coolest thing about this session was using Firefox’s Scratchpad for all of the live-coding. It worked so well, we plan on doing more sessions like this.

Crypton is intended for use inside of mobile and desktop applications (FirefoxOS, too). Our initial target for development is via Cordova and node-webkit. The API hides all of the complexity of cryptography from the developer. Developers use APIs that look like any other hosted API, for instance, account creation looks something like this:

var myAccount; crypton.generateAccount('alice', 'password', function callback(error, successResult){ if (error) { console.error(err); return;} myAccount = successResult; });

Beneath this elegant, every-day-looking API call, a set of encryption keys are generated for encryption, signing and HMAC as well as a stretched key via the password that wraps all other keys. This keyring is then stored on the server making multiple-device operations easy.

As we move forward with the Crypton framework, we are building a “private backend service” which will make using Crypton trivially easy to use and require no system administration. More on this in a future post.

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: Designing Tiles for Trust

Mozilla planet - to, 13/11/2014 - 17:38

In August, I wrote about why we believe that trust is the most important currency of the Web. As I explained then, putting the user first, through transparency, choice and control is the only way to bring about the Web we want. In that post, I described several of our efforts designed to help us positively influence the ecosystem to garner more trust from users. One of those efforts was the Tiles feature. To influence the ecosystem, we have to participate in it.

As we move forward with Tiles, we wanted to share more details on our approach and invite your feedback. On November 10, we announced the release of a 10th anniversary edition of Firefox and firmly took our stand as an independent voice on the Web. With the anniversary edition, we made the Tiles experiment a part of Firefox.

We developed Tiles as an engaging and useful experience for our users. We designed the feature with a core focus on our Privacy Principles. Here are a few examples of how those principles influenced the feature:

  1. We ensure that no data is sent to us until you interact with the feature.
  2. You control the feature and can turn it off easily if you don’t find it useful.
  3. You can audit us – all of our code is open and auditable by you. In particular, you can learn more about the code that powers this feature here.
  4. If a user has previously opted into Do Not Track, we assume this means the user does not want to see Tiles so we pref Tiles off for those users. (Note: If a user subsequently opts in to DNT, the user will need to switch Tiles off).
  5. The data we collect is transmitted over HTTPS/TLS.

We’d love your feedback on these principles, and any ideas or suggestions you might have to make Tiles more valuable to users. Leave a comment, or better yet, use this form to submit feedback directly to the Tiles team.

We’re excited to move forward with Tiles and will continue to innovate with ways we can create positive impacts through this feature. Simultaneously, we will use our experiments through our Polaris initiative to test additional ways we can help create transparency, choice and control for our users.

Categorieën: Mozilla-nl planet

Advancing Content: Announcing Firefox Tiles Going Live Today

Mozilla planet - to, 13/11/2014 - 15:11

With the 10th anniversary update to Firefox, there was an important update to the new tab experience, promoting Tiles to the Firefox stable build, and making them available to hundreds of millions of users around the world.  Today we are excited to announce our first two sponsored Tiles partners: CVS Health and their media agency Mindshare North America, and

What are Tiles for?

For years, the new tab page in Firefox was unique in being intentionally blank – but by 2012, we learned that we could facilitate many users’ workflow through the new tab page.  We added thumbnails based on a calculation of “frecency” (frequency and recency of a user’s browsing history, essentially the same way that the Awesome bar calculates relevance). We learned that many users find these history thumbnails useful; but we were not entirely satisfied with the feature.  Thumbnails might be broken, and the experience could be much more dynamic.

We need to be able to use our voice with our users, for example to raise awareness around issues that affect the future of the Internet, and to promote those causes that we believe are important to that future.

We have been exploring the content discovery space.  There are many aspects of digital advertising that concern us: from the overall integrity of the advertising system on the Web, to the user having control over what happens to their data, and then to what happens to the data once the user has given their consent.  I have been writing for a while on this blog about the principles we follow and the ideas we have to improve digital advertising.

Lastly, we wanted to explore ways to contribute to the sustainability of the project in a way that we felt could align with Mozilla’s values.

Tiles are our first iteration on starting to solve these problems.  They create a more useful, attractive and dynamic new tab page.  Tiles also represent an important part of our efforts to create new communications, content and advertising experiences over which Firefox users maintain control.

Partnering with Mozilla

We’re very excited to have partnered with CVS Health (and Mindshare/GroupM) in the United States and globally as our first two Firefox sponsored Tiles partners.  We are live in 8 languages and 25 different countries*, and will continue to iterate with Mindshare/GroupM and, as well as with our community, as we continue to improve on the experience.

We have been delighted to work with Mindshare/GroupM and  When we collaborate, we need to understand the vision and objectives of the partner, and to understand if that partner is able to work within the framework of Mozilla’s principles.  Running sponsored content in Tiles is results-based, not surveillance-based. We do not allow tracking beacons or code in Tiles. We are not collecting, or providing them with, the data about you that most digital ad networks do.  There are certain categories that require screening or what’s commonly known as age-gating, or have other sensitivities, that we will stay away from, such as alcohol and pharmaceuticals.

The user’s experience

CVS Health Placed in Firefox Tiles

For users with no browsing history (typically a new installation), they will see Directory Tiles offering an updated, interactive design and suggesting useful sites.  A separate feature, Enhanced Tiles, will improve upon the existing new tab page experience for users who already have a history in their browser.

Tiles provides Mozilla (including our local communities) new ways to interact with and communicate with our users.  (If you’ve been using a pre-release Firefox build, you might have seen promotions for Citizenfour, a documentary about Edward Snowden and the NSA, appearing in your new tab in the past few weeks.)

Tiles also offers Mozilla new partnership opportunities with advertisers and publishers all while respecting and protecting our users. These sponsorships serve several important goals simultaneously by balancing the benefits to users of improved experience, control and choice, with sustainability for Mozilla.

What users currently see in the New:Tab page on Firefox desktop will continue to evolve, just like any digital product would.  And it will evolve along the lines I discussed earlier here. Above all, we need to earn and maintain users’ trust.

Looking ahead

User control and transparency are embedded in all of our design and architecture, and principles that we seek to deliver our users throughout their online life: trust is something that you earn every day.  The Tiles-related user data we collect is anonymized after we receive it – as it is for other parts of Firefox that we instrument to ensure a good experience.  And of course, a user can simply switch the new tab page Tiles feature off.   One thing I must note: users of ad blocking add-ons such as Ad Block Plus will see adverts by default and will need to switch Tiles off in Firefox if they wish to see no ads in their New Tab page.  You can read more about how we design for trust here.  (Note:  AdBlock Plus is not a Mozilla product and their content blocking mechanism is under their control.  We expect that they may add support for the Tiles in future releases)

With the testing we’ve done, we’re satisfied that users will find this an experience that they understand and trust – but we will always have that as a development objective.   You can expect us to iterate frequently, but we will never assume trust – we will always work to earn it.  And if we do have and maintain that trust, we can create potentially the best digital advertising medium on the planet.

We believe that we can do this, and offer a better way to deliver and to receive adverts that users find useful and relevant.  And we also believe that this is a great opportunity for advertisers who share our vision, and who wish to reach their audience in a way that respects them and their trust.  If that’s you, we want to hear from you.  Feel free to reach out to

And a big thank you to our initial launch partners, CVS Health,, and Citizenfour  who see our vision and are supporting Mozilla to have greater impact in the world.

* that list in full:

Argentina, Australia, Austria, Belarus, Belgium, Brazil, Canada, Chile, Colombia, Ecuador, France, Germany, Hong Kong, Japan, Kazakhstan, Mexico, New Zealand, Peru, Russia, Saudi Arabia, Spain, Switzerland, United Kingdom, United States and Venezuela.

Categorieën: Mozilla-nl planet