A coworker contacted me today about the Unbias Me extension. It’s a set of simple userscripts that hide profile pictures and names in sites like LinkedIn and GitHub, where unconscious bias can affect your behavior toward women and other groups. She wanted to know if we could have an add-on like this for Firefox.

I gave the add-on a quick look and realized it would be trivial to port it to WebExtensions. WebExtensions already support browser_action and content_scripts, which is what the add-on uses. So, ultimately all I needed to do was add a little bit of metadata:

  "applications": {
    "gecko": {
      "id": "unbias-me@fureigh",
        "strict_min_version": "45.0"
    }
  },

That’s it! You just zip the files together and use the .xpi file extension, and you’re good to go. Here’s the unsigned XPI if you want to give it a try. I sent a PR to the developer, so I hope they can integrate this code and get the add-on listed on our site.

This may seem like an unfair example since content scripts are the simplest form of add-on. However, keep in mind that they’re also the most common form of add-on. Having support for this API means that there are probably thousands of Chrome extensions that can be very easily ported right now to work with release versions of Firefox and to be listed on AMO. If there’s a Chrome extension you would like to see ported to Firefox, you should give this little experiment a try.

http://xulforge.com/blog/2016/03/porting-a-chrome-extension-to-webextensions-in-half-a-step/

I’m often asked to explain the threading model of the DOM. From the perspective of JavaScript (today), execution is essentially single threaded. But beneath the hood things are a bit more complicated. Some of this discussion is applicable across browsers, but a fair bit is Gecko specific. I made a picture but can’t seem to embed it usefully in my blog :P

The first thread of interest is the “main thread”. This is the thread that JS embedded in documents runs on. In Gecko, it’s also the thread that does most of the layout work, processes native UI events from the operating system, does bookkeeping for a lot of the networking code, and much more. Tying up this thread for long periods of time starves these other tasks and makes the browser “jank”, or not respond promptly to input. And compounding this problem, JS uses a “run to completion” scheduling mechanism where execution is not preempted to do other work.

For web pages that want to do long running background processing without yielding we created Web Workers, an abstraction for threads that communicate solely through asynchronous message passing. Workers have access to some APIs such as XMLHttpRequest and IndexedDB but not others, such as Nodes or DOMParser. This allows limited forms of background processing but little UI interaction (although that is changing a bit!).

The main thread and worker threads are the only threads within the browser that run JS. But there are many more threads involved in the implementation of the DOM and related APIs.

---

All of our network I/O (opening, closing, and polling sockets) has long happened on a pool of network threads. For similar reasons, database and storage operations such as those for localStorage or IndexedDB also happen on a pool of background threads. The UI (main) thread needs to remain responsive no matter how slow your network connection or disk is! We’ve also sought to move long running tasks with little interaction with the rest of the browser off the main thread. The HTML parser usually runs on its own thread. And for some types of loads (such as normal page loads), the networking threads talk directly to the parser thread, while for other types (such as XHR or Fetch) the networking threads talk to the main thread.

There’s also a single IPC thread dedicated to passing IPDL messages between threads and processes via pipes. This thread connects both the main thread and worker threads to PBackground-based protocols, and connects the main thread to PContent-based protocols. The simplified picture linked at the beginning of this article diagrams how all these threads link together.

There are also some other threads that I didn’t include in the diagram. Inside the JS engine Spidermonkey also does threaded script parsing and garbage collection. And HTML media elements connect to machinery for audio and video playback that involves off-main-thread decoding and rendering pipelines. These are generally outside the scope of the “DOM team” at Mozilla, because those subsystems are maintained by other teams (the JS team and the Media Playback team respectively) and have little effect on most of the DOM.

While the threading model visible to JS is pretty simple, inside Gecko there’s a lot more complexity. This is why we do things like document which thread code is expected to run on, assert that objects are refcounted on the correct thread even in opt builds, and generally structure threaded code to use message passing and event loops (via nsIRunnable) rather than using complex systems of shared memory and locks. Relatively modern threaded code, such as our Web Worker or IndexedDB implementations demonstrate many of these best practices. And of course, I and other experienced engineers are always happy to answer questions.

http://blog.kylehuey.com/post/141859564272

Decision-Making is hard at Mozilla.  We often face inertia and ambiguity regarding who owns a decision.  It can feel as if many people can say “no” and it’s hard to figure out who can and will say “yes.”  Our focus on individuals as empowered leaders can make it hard to understand how to make a […]

http://blog.lizardwrangler.com/2016/03/28/pilot-working-group-on-decision-making/

The Monday Project Meeting

https://air.mozilla.org/mozilla-weekly-project-meeting-20160328/

I feel a strong need for more conversations with people who care about the Open Internet, Mozilla and Mozilla’s mission.  I’ve noticed that my blog has become pretty “official.”  By this I mean most of the posts are more one way and don’t invite conversation the way I’d like. I’m going to try returning to […]

http://blog.lizardwrangler.com/2016/03/28/inviting-conversation/

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us an email! Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

This week's edition was edited by: Vikrant and llogiq.

Updates from Rust Community

News & Blog Posts

• OneSignal now sends iOS push notifications 100x faster. Using Rust of course!
• String types in Rust. Andrew explains the difference between String, str, OsStr, OsString, CStr, and CString.
• Installing Rust on Windows.
• Async hyper. Asynchronous IO is coming in hyper.
• Exploring Rust from a C# developer's perspective.
• Linear Algebra written entirely in Rust.
• Rust mutation testing.
• This week in Servo 56.
• These weeks in Amethyst 8.

Notable New Crates & Project Updates

• Erick Tryzelaar joins the core team!
• Jonathan Turner joins Mozilla’s Rust team!
• GFX now supports D3D11 (DX11) as a backend.
• Parity (an Ethereum client in Rust) has released v1.0.
• BitSparrow. Binary serializer to exchange data between Rust and JavaScript.
• Emit. An experimental structured event emitter for Rust.
• Gracer. A Rust code completion plugin for gedit.
• untry. Convert try!() into ?s.
• cargo-deadlinks. Cargo subcommand for checking your documentation for broken links.
• screenprints. Screenprints acts as a buffer for terminal display continuously printing output at a configured interval.

Crate of the Week

This week's Crate of the Week is gfx, a crate to show stuff on a screen on most available platforms that have one. Thanks to Dzmitry Malyshau for the suggestion!

Submit your suggestions for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• [medium] buildengine5: Test net::test::client_server_send fails.
• [less easy] Vulkano: Add a memory pool.
• [easy] Servo: Implement HTMLScriptElement.type and similar attributes.
• [easy] Servo: Stop re-exporting webrender_traits WebGL types from canvas_traits.
• [less easy] Servo: Using viewport percentage lengths (e.g. vh, vw) causes unnecessary style recalc on resize.
• [easy] Servo: Enable CCACHE for AppVeyor Windows builds.
• [easy] cargo add: Target specifications.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

103 pull requests were merged in the last week.

Notable changes

• += for std::time types
• Fix byte order for IPv6 addresses
• Scopes in MIR
• Naked functions
• try!(_) -> _? in the code
• Range*::contains(_)
• Poisoning for Once
• UNIX sockets in std
• Symbol name improvements
• Lang items must be unique
• removed warnings is now a lint
• encode_utf{8,16}(_) return iterators
• Consts in match must be Eq
• MIR can analyze moves
• Un-hack name resolution for primitive types
• typeck: O(n) -> O(1) for equal types
• Most core types are now Debug
• Forbid out-of-scope trait's methods

New Contributors

• Alejandro Wainzinger
• Andrew Horton
• Cyryl Plotnicki-Chudyk
• David Henningsson
• ituxbag
• Kevin Brothaler
• nicholasf
• Novotnik, Petr

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• RFC 1201: Add support for naked functions.
• RFC 1422: Expand the current pub/non-pub categorization of items with the ability to say "make this item visible solely to a (named) module tree".

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

• Add a contains method to VecDeque and LinkedList.
• Add libutil to scope of libc crate on Linux.
• Stabilize implementing panics as aborts.
• Add a standard allocator interface and support for user-defined allocators.
• Remove some kinds of doc comments.
• Unsafe expressions.
• Prevent unstable items from causing name resolution conflicts with downstream code.
• Amend RFC 1228 with operator fixity and precedence.

New RFCs

• Allow coercing non-capturing closures to function pointers.

Upcoming Events

• 3/31. Tokyo Rust Meetup #4.
• 4/6. OpenTechSchool Berlin: Rust Hack and Learn.
• 4/6. Germany/Cologne - Hack and Learn.
• 4/6. Rust S~ao Paulo Meetup.
• 4/11. Seattle Rust Meetup.
• 4/15. Frankfurt/Main Rust Lint Workshop

If you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.

fn work(on: RustProject) -> Money

• PhD and postdoc positions at MPI-SWS.
• Rust developer at The Blackbird.

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

No quote was selected for QotW.

Submit your quotes for next week!

https://this-week-in-rust.org/blog/2016/03/28/this-week-in-rust-124/

In the last week, we landed 108 PRs in the Servo organization’s repositories.

We are pleased to announce that Bobby Holley (bholley), a long-time Gecko hacker, has become a reviewer! He will primarily be reviewing patches in the style system, especially those related to Gecko integration.

Notable Additions

• uk992 fixed a PATH-related issue that was vexing many Windows Servo users
• mbrubeck repaired the regression around failing to repaint when image loads completed
• larsberg updated Cargo, moved Servo off of hack scripts to instead use RUSTFLAGS and turned on hardfloat on ARM Android
• ajeffrey added a chaos mode to our pipelines, in order to test constellation resilience against randomly failing iframes
• sagar et al. implemented the initial pieces of form validation
• edunham started the work to make AArch64 not use the gold linker
• aneesh dramatically refactored the Android Salt builder rules
• manish added support for navigation keys
• pcwalton sped up display list transfer
• shinglyu implemented XMLHttpRequest.responseURL
• nox updated the Firefox developer tools integration to accommodate recent Firefox changes
• DDEFISHER et al. implemented the backend for an HTTP authentication cache
• ConnorGBrewstew corrected an issue with rendering after scrolling via named anchors
• pkondzior improved the memory reporting coverage of layout threads
• stspyder made the Blob constructor compatible with the File API specification
• schuster implemented missing parts of the HTMLAnchorElement interface

New Contributors

• Awal Garg
• Connor Brewster
• Jussi R"as"anen
• Matthias Kr"uger
• Liam
• Per Lundberg
• Stjepan Glavina
• Emily Dunham
• Anthony

Get Involved

Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors!

Screenshot

None this week.

Meetings

Last week, we discussed temporarily dropping GLES 2.0 support in WebRender, using Webrender as the default, and automating failure/intermittent reporting.

http://blog.servo.org/2016/03/28/twis-57/

In an effort to ease data access at Mozilla we started providing SQL access to our Parquet datasets through Presto. The benefit of SQL is that it’s a commonly understood language among engineers and non-engineers alike and is generally easy to pick up.

Even though we use Redshift for some of our data,  there are datasets that store complex hierarchical data which would require unnatural transformations to fit in a typical SQL store that doesn’t support the flexibility of a nested data model (think of structs, arrays & maps) such as the one provided by Parquet. Furthermore, we were looking to use a single store for our data, i.e. Parquet files on S3, which both Spark and a SQL engine could access directly.

Presto provides the best of both worlds: SQL over Parquet. Presto is an open-source distributed SQL query engine for running interactive analytic queries against various data sources. It allows querying different sources such as Hive and Cassandra, relational databases or even proprietary data stores and a single query can combine data from multiple sources.

Apache Drill offers similar features without requiring up-front schema knowledge, which is a big advantage over Presto given how painful a schema migration can be at times. Overall Drill feels less mature than Presto though and is not supported yet by Amazon EMR unlike Presto, which makes deployment & maintance more involved. For those reasons we picked Presto as our SQL engine.

Presto supports a rich set of data types which map to Parquet ones:

Arrays
The [] operator is used to access an element of an array:

SELECT my_array[1] AS first_element

Maps
The [] operator is used to retrieve the value corresponding to a given key from a map:

SELECT name_to_age_map['Bob'] AS bob_age

Structs
Fields within a structure are accessed with the field reference operator .:

SELECT my_column.my_field

Unnesting maps and structs
The UNNEST clause is used to expand an array or a map into a relation. Arrays are expanded into a single column, and maps are expanded into two columns (key, value). UNNEST can also be used with multiple arguments, in which case they are expanded into multiple columns, with as many rows as the highest cardinality argument:

SELECT numbers, animals, n, a
FROM (
  VALUES
    (ARRAY[2, 5], ARRAY['dog', 'cat', 'bird']),
    (ARRAY[7, 8, 9], ARRAY['cow', 'pig'])
) AS x (numbers, animals)
CROSS JOIN UNNEST(numbers, animals) AS t (n, a);

which yields:

  numbers  |     animals      |  n   |  a
-----------+------------------+------+------
 [2, 5]    | [dog, cat, bird] |    2 | dog
 [2, 5]    | [dog, cat, bird] |    5 | cat
 [2, 5]    | [dog, cat, bird] | NULL | bird
 [7, 8, 9] | [cow, pig]       |    7 | cow
 [7, 8, 9] | [cow, pig]       |    8 | pig
 [7, 8, 9] | [cow, pig]       |    9 | NULL

The longitudinal view is currently accessible through Presto.  As a concrete example, this is how one could count the number of Telemetry fragments over a time range:

SELECT d, count(*)
FROM (
  SELECT substr(ssd, 1, 11) AS d
  FROM longitudinal
  CROSS JOIN UNNEST(subsession_start_date) AS s(ssd)
)
WHERE d >= '2015-11-15' AND d < '2016-03-15'
GROUP BY d
ORDER BY d ASC

Re:dash
Re:dash allows to query Presto directly from Firefox. After a query is run a table is displayed with the result. Queries can be saved and optionally scheduled to run periodically at a given time.

Query editor

Different kinds of plots (e.g. bar charts, line charts, boxplots, …) can be built over a table which are updated every time the query is re-run.

Number of Telemetry fragments over time

Custom dashboards can be built that link to tables and plots. Users can visualize the dashboards and optionally access the SQL code that powers them and fork it.

A simple dashboard

Mozilla’s re:dash instance can be accessed at sql.telemetry.mozilla.org.

http://robertovitillo.com/2016/03/27/telemetry-meets-sql/

http://danielpocock.com/facebook-everybody-can-be-judas

In Firefox we use a custom allocator, mozjemalloc, based on a rather ancient version of jemalloc. The motivation for using a custom allocator is that it potentially gives us both performance and memory wins. I don’t know the full history, so I’ll let someone else write that up. What I do know is that we use it and it behaves a bit differently than system malloc implementations in a rather significant way: minimum alignment.

Why does this matter? Well it turns out C runtime implementations and/or compilers make some assumptions based on what the minimum allocation size and alignment is. For example in bug 1181142 we’re looking at a crash on Windows that happens in strcmp. The CRT decided to walk off the end of a page because it was comparing 4 bytes at a time.

Crossing the page boundary.

Why was it doing that? Because the minimum allocation size is at least 4-bytes, so why not? If you head over to MSDN it’s spelled out somewhat clearly (although older versions of that page lack the specific byte sizes):

A fundamental alignment is an alignment that’s less than or equal to the largest alignment that’s supported by the implementation without an alignment specification. (In Visual C++, this is the alignment that’s required for a double, or 8 bytes. In code that targets 64-bit platforms, it’s 16 bytes.)

We’ve had similar issues on Linux (and maybe OS X), see bug 691003 for more historical details.

As it turns out we’re still not exactly in compliance in Linux which seems to stipulate 8-byte alignment on 32-bit and 16-byte alignment on 64-bit:

The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems).

We haven’t seen a compelling reason to go up to a 8-byte alignment on 32-bit platforms (in the form of crashes) but perhaps that’s due to Linux being such a small percentage of our users.

And lets not forget about OS X, which as far as I can tell has always had a 16-byte alignment minimum. I can’t find where that’s spelled out in bytes, but go bang on malloc and you’ll always get a 16-byte aligned thing. My guess is this is a leftover from the PPC days and altivec. From the malloc man page for OS X:

The allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types.

Again we haven’t seen crashes pointing to the lack of 16-byte alignment, again perhaps that’s because OS X is also a small percentage of our users. On the other hand maybe this is just an optimization but not an outright requirement.

So what happens when we do the right thing? Odds are less crashes which is good. Maybe more memory usage (you ask for a 1-byte thing on 64-bit Windows you’re going to get a 16-byte thing back), although early testing hasn’t shown a huge impact. Perf-wise there might be a win, with guaranteed minimum sizes we can compare things a bit quicker (4, 8, 16 bytes at a time).

http://www.erahm.org/2016/03/24/minimum-alignment-of-allocation-across-platforms/

The Internet of Things multiplies the privacy challenges for companies and consumers alike. Will traditional ways of explaining privacy choices work in this space? What...

https://air.mozilla.org/privacy-lab-march-2016-privacy-and-the-internet-of-things/

Product management done well helps make companies and products much better. But when done badly, it can significantly hurt a company and team. Our March...

https://air.mozilla.org/the-role-of-a-product-manager-everything-and-nothing/

http://hearsum.ca/blog/a-flurry-of-balrog-activity.html

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

https://air.mozilla.org/reps-weekly-20160324/

This is our weekly gathering of Mozilla'a Web QA team filled with discussion on our current and future projects, ideas, demos, and fun facts.

https://air.mozilla.org/web-qa-weekly-meeting-20160324/

Belgium’s heartbreaking terror attacks lie heavily on my heart today, as I’m sure they do for many others. In these moments, it can be easy to lose hope for a more peaceful and multicultural future. And yet, reminders of local peacebuilding efforts in neighbourhoods around the world continue to emerge when we look for them. Here’s a small example.

Last week, I was invited to the city of Belfast in Northern Ireland (known largely to foreigners as the site of a series of equally sad conflicts from its past) to speak about my research into critical making and fabrication futures for the Maker Assembly NI gathering, organized by the inspiring Pip Shea and Irish hackspace Farset Labs.

For our panel on speculative making, curator Nora O'Murchu and I were asked to discuss the supports needed to maintain a critical forecast of makerspaces as the idea of digital making becomes more accessible. Nora provided some of her thoughts on making practice as informed by her work with the University of Limerick (and the wonderful Cat++ programming language). Other inspiring makers like Hanna Stewart from the RCA Future Makerspaces Project and Javier Buron from FabLab Limerick discussed sustainability and governance of maker networks.

Meanwhile, I shared two different potential futures of making (presentation here), based on initial research for my PhD into makerspace cultures around the world. The first future (of many possible) that I see being built is a top-down one, dictated by corporate entrepreneurs and Silicon Valley futurecasters, where makerspaces are framed around Western leisure and profit, not critical perspectives. The second future, however, moves from the bottom-up, where diverse, autonomous spaces around the world are fostered, building local making and fabrication practices that are sustainable, critical and in collaboration with communities.

What I was most impressed by, though, was the high level of consciousness amongst local participants regarding the complex sociopolitical and economic circumstances of their region – and the various projects they have launched to strengthen peacekeeping efforts through local fabrication at spaces for making across the city, led by Irish communities themselves.

“Violence has stopped here,” Adam Wallace and Eamon Durey from the new FabLab NI told us, “but there are still undercurrents of extremism”. The Troubles are over, but Belfast remains highly divided between Catholic and Protestant neighbourhood territories – so the idea of shared space remains challenging.

And that’s exactly why locals believe spaces like fab labs are important in building non-contested public community centres for everyone. From workshops that give local youth qualifications to create their own local technology enterprises in marginalized areas to programmes on hyrdoponics and plant processing to the use of open source practices and machines, many local organizers believe these spaces can help build new kinds of community - and manufacturing - that revitalize as well as educate. “It’s not a classroom, it’s not a college, and it’s not a community centre. It’s something that we’ve never had here before,” they told us.

The discussions that emerged were equally interesting. Would efforts like these build a truly egalitarian future for the region, audience members wondered, or another form of New Labour-era, Claire Bishop-esque social control? A local trade union representative mentioned similar initiatives like the inspiring Lukas Plan technology community hubs that were opened across in London in the 1970s and then closed down due to Thatcher-era cuts to social programs. How could Northern Ireland’s initiatives be more sustainable, longer-lasting and provide jobs at the end where services and goods are created for the community, by the community?

In such circumstances, where the worlds we discuss remain so new, their machines so shiny, there are often more questions than there are answers - but it was a good sign to see people asking them so thoughtfully last week. I now look forward to seeing how the powerful local mandate of shared machine shops to “bring manufacturing and technology back into our communities, this time with co-ops” will help build peaceful and empowering futures across Northern Ireland.

http://blog.codekat.net/post/141604183944

Hello Mozillians,

We are happy to announce that Friday, April 1st, we are organizing Firefox 46 Beta 7 Testday. We will be focusing our testing on APZ (Async Scrolling) feature and Image Support. Check out the detailed instructions via this etherpad.

No previous testing experience is required, so feel free to join us on #qa IRC channel where our moderators will offer you guidance and answer your questions.

Join us and help us make Firefox better! See you on Friday!

https://quality.mozilla.org/2016/03/firefox-46-beta-7-testday-april-1st/

Could Rust have a left-pad incident?

The short answer: No.

http://edunham.net/2016/03/24/could_rust_have_a_left_pad_incident.html

I’ve written before about using Firefox Hello, the video chat feature that is now built into Firefox. Firefox Hello is built on top of WebRTC, which is now part of HTML. This means that video chat can also be implemented in ordinary webpages.

I’ve been using Talky recently for lots of 1-on-1 meetings and even some groups meetings. It has some really nice features.

• You can choose a room name, which becomes part of the URL — e.g. https://talky.io/myroom.
• There’s an optional tab-sharing feature.
• The UI is simple and provides a symmetric experience for all participants.

Great stuff!

https://blog.mozilla.org/nnethercote/2016/03/24/talky-is-a-nice-webrtc-client/

Join the core team to discuss the on-going development of the Bugzilla product. Anyone interested in contributing to Bugzilla, in planning, development, testing, documentation, or...

https://air.mozilla.org/bugzilla-development-meeting-20160323/