mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Will Kahn-Greene: Input status: June 19th, 2015

Mozilla planet - fr, 19/06/2015 - 17:00
Development

High-level summary:

  • lots of library updates and changes to make way for Django 1.8
  • switch from nose to pytest
  • new suggests and redirector frameworks
  • upgraded from Elasticsearch 0.90.10 to 1.2.4
  • added editorconfig and pre-commit for easier development

That doesn't sound like a lot, but it was.

I'll write a more comprehensive blog post about the new suggests and redirector frameworks soon.

Thank you to contributors!:

  • L Guruprasad: 6
  • Michael Kelly: 1
  • Ricky Rosario: 17

Skipping the long list of commits and bugs. If you're interested, you can check the commit logs.

Current head: ac406e4

Rough schedule going forward
  1. Finish up upgrade to Django 1.8.
  2. Implement trigger-keyword provider.
  3. Redo the Elasticsearch infrastructure in Fjord.

That's it for this update!

Categorieën: Mozilla-nl planet

Robert O'Callahan: Bug In Newer Linux Kernels Affecting rr

Mozilla planet - fr, 19/06/2015 - 15:36

As of kernel 4.0.4 (and probably earlier), writing to /proc/.../mem at a page which is mapped PROT_NONE causes a kernel BUG at mm/memory.c, which kills the writing process. This breaks rr, although I have a workaround which I'm about to land; the workaround temporarily makes the PROT_NONE regions we're writing to PROT_WRITE.

Trevor reported this in the kernel bugzilla already, though I was able to come up with a nice small test program.

Categorieën: Mozilla-nl planet

Ted Clancy: The Canadian, Day 2

Mozilla planet - fr, 19/06/2015 - 13:02

This is what I saw when I woke up.

attachment1

(Taken with my Firefox OS phone.)

Update: Sudbury
So, it took us 8 hours to reach Sudbury. Sudbury is only about a 3 and half hour drive by car on the highway. You could call this a leisurely pace.

We are now on tracks that were originally owned by the Canadian Northern Railway (not to be confused with the Northern Railway of Canada, whose tracks we were on before). These tracks stretch across the country from Vancouver to Quebec City. Canadian Nothern Railway was the second railway to provide transcontinental service across Canada (the first being Canadian Pacific Railway, who still dominate Canada’s rail industry today).

Now these tracks are owned by CNR (Canadian National Railway).

Update: Hornepayne

If you look at a population map of Canada, you’ll see there’s a mostly unpopulated gap between Sault Ste Marie and Kenora, separating western Canada from eastern Canada. I’m currently in that gap.

I didn’t realize it would be so hard to get internet here. I haven’t managed to get an internet connection since leaving Sudbury, and I suspect I won’t be able to until we’re near Thunder Bay.

I’m supposed to be working today, but lack of internet is really hindering what I can do. I spent a while glued to my phone, hoping to glimpse a bar of service or two, but eventually gave up. It’s frustrating, because I’m trying to submit a patch for review, and I was hoping to get it approved before this weekend. I don’t like my chances of getting it reviewed next week when everyone’s busy at Whistler.

After a while, I went to the observation car and stared out the window, which I found relaxing. There seem to be countless beautiful lakes and rivers up here. We never seem to be far from a watercourse. I wonder if these rivers were a route used by fur traders in the early days of Nouvelle France.

The train stopped a couple times to drop off canoeists. I suspect we’re in a part of the country only accessible by rail.

I saw a beaver! You know, I’ve been in Canada all these years, and I think that’s the first time I’ve actually seen a beaver.

Most of the signs on this train are embossed with Braille. The signs use uncontracted Braille. I notice that the English is prefixed with dot-6 (⠠) while the French is prefixed with dot-46 (⠨). I wonder if that’s a standard convention.

Update: Sioux Lookout

We’re near Thunder Bay. For about 15 minutes we had cell phone and internet coverage, and everyone was staring to their phones.

We’re now on tracks that were part of the National Transcontinental Railway, built in 1885. This route spanned from Winnipeg to Moncton. The section from Winnipeg to Quebec City is almost a straight line stretching across northern Ontario and northern Quebec. The idea was that it would provide the quickest route from the Prairies to the Maritimes by bypassing cities like Toronto, Ottawa, Montreal. The railway was never successful.

Most of the railway is now abandoned and owned by no one. Parts of it are owned by CNR, and we’re currently on one of those parts.

Many francophone towns in Northern Ontario, like Kapuskasing and Hearst, lie along the abandoned portion of this railway. Those towns are now serviced by Highway 17.

But there are no highways along this section. There’s barely a road in sight.

Musical Interlude II


Categorieën: Mozilla-nl planet

Mozilla Reps Community: Reps Weekly Call – June 18th 2015

Mozilla planet - fr, 19/06/2015 - 12:39

Last Thursday we had our 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.

cropped-Untitled.png

Summary
  • Reps improvement: What are the things you would like to improve?
  • Reps in the future: How do you see the program in the next year? What a Rep role should be?
  • Road to Whistler: What would you like Council/Peers to do during the Work Week?
AirMozilla video

Detailed notes

Shout outs to all the Indonesian Reps and Mozillians who attend and work very hard productively on Webmaker App Launch Meeting last Sunday.

Program Brainstorming

This call was about brainstorming about the Reps program.

There were three questions to be answered:

  • What are the things you would like to improve?
  • How do you see the program in the next year? What a Rep role should be?
  • Road to Whistler – What would you like Council/Peers to do during the Work Week?

Since not everyone could participate in the Call, we have created a Discourse topic to discuss this further. You can find it here.

For the answers please see the above mentioned discourse thread or the raw notes.

Raw etherpad notes.

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

Categorieën: Mozilla-nl planet

Apple, Google, Microsoft en Mozilla werken aan native websites | One More Thing - One More Thing

Nieuws verzameld via Google - fr, 19/06/2015 - 11:31

Personal Computer Magazine

Apple, Google, Microsoft en Mozilla werken aan native websites | One More Thing
One More Thing
Het web is anno 2015 van iedereen, dus bij het ontwikkelen van een nieuwe standaard is samenwerking belangrijk. Dat is wat Apple, Google en andere internet-grootmachten gaan doen. Er wordt samen gesleuteld aan een nieuwe, snelle webstandaard.
Techbedrijven werken aan snellere browser-programmeertaal WebAssembly ...Personal Computer Magazine

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

Binary Format WebAssembly Binds Google, Microsoft, Mozilla and others Together - Mobile Magazine

Nieuws verzameld via Google - fr, 19/06/2015 - 09:16

onmanorama

Binary Format WebAssembly Binds Google, Microsoft, Mozilla and others Together
Mobile Magazine
Lately, Google along with Microsoft, Mozilla, and other influential firms has announced to work together for launching the new binary format, WebAssembly. The idea of introducing this latest binary format is to revolutionize the concept of compiling ...
Microsoft, Google, Mozilla team to build a faster Web - News - PC AdvisorPC Advisor
Google, Apple, Microsoft and Mozilla team uponmanorama
WebAssembly: Google, Mozilla, Microsoft and others team up to launch new ...Pulse Nigeria
Computerworld India -CNET -Techworld.com
alle 42 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Nick Fitzgerald: Source Maps Are An Insufficient Debugging Format For The Web

Mozilla planet - fr, 19/06/2015 - 09:00

I want exceptional debugging support for programs compiled to JavaScript (or wasm) on the web. I want first class developer tools support for these programs. Unfortunately, this isn't the case right now because source maps are currently insufficient.

When boiled down to their essence, stepping debuggers enable users to do two things:

  1. set breakpoints and incrementally step through their program's execution, and
  2. inspect the values of variables and function parameters as they step through their program's execution.

A debugging format encodes information about a program that is lost at compile time, enabling source-level debugging of the compiled program. Source maps — the sole debugging format for compilers targeting JavaScript — can reconstruct source-level location information (filename, line, and column) which enables (1). However, that is the only data source maps encode, and the source map format does not attempt to solve (2). The result is that debugging programs compiled to JavaScript is positively maddening.

The good news is that we can overcome this limitation and extend the source map format to support reconstructing source-level scopes, bindings, and values. Before we do that, we should understand how mature debugging formats encode this information and how it is in turn consumed by debuggers. The prevailing debugging data format for *nix-based systems today is DWARF. It supersedes earlier ad-hoc formats, such as stabs. DWARF's designers worked with earlier formats for years, and used that experience as the foundation upon which DWARF was built. What follows is an exploration of how DWARF encodes scope and binding debugging information while keeping an eye out for lessons we can learn and apply when extending source maps.

Compact Binary Format

DWARF uses a compact binary record format to store structured information, conceptually similar to Cap'n Proto or Message Pack serialization formats. These Debugging Information Entries, or DIEs, are made up of a type tag, a set of attribute type and attribute value pairs, and an optional set of child DIEs. With these children, DIEs form a tree structure.

<DIE tag 1> <attribute name and type 1> <attribute value 1> <attribute name and type 2> <attribute value 2> <attribute name and type 3> <attribute value 3> <DIE tag 1> <attribute name and type 1> <attribute value 1> <attribute name and type 2> <attribute value 2> <attribute name and type 3> <attribute value 3> <DIE tag 1> <attribute name and type 1> <attribute value 1> <attribute name and type 2> <attribute value 2> <attribute name and type 3> <attribute value 3> . . .

Furthermore, the metadata describing common attribute shapes can be factored out and de-duplicated with abbreviations. By using abbreviations, that previous series of DIEs can be compressed into this:

<abbreviation definition 1> <attribute name and type 1> <attribute name and type 2> <attribute name and type 3> <DIE abbreviation tag 1> <attribute value 1> <attribute value 2> <attribute value 3> <DIE abbreviation tag 1> <attribute value 1> <attribute value 2> <attribute value 3> <DIE abbreviation tag 1> <attribute value 1> <attribute value 2> <attribute value 3> . . .

With abbreviations, none of the attribute name and type metadata is repeated. This helps keep the debugging data compact. Debugging data can be huge in practice. Source maps can already be many megabytes in size, and the format already strives for as much de-duplication of data it can and only encodes limited debugging information as it is. This issue is exacerbated for source maps, because they are sent over the network and downloaded by debuggers. We must go to great lengths to keep debugging formats compact.

Additionally, because the set of attributes a DIE contains is not fixed, the format is future extensible. New attributes can be added to provide new debugging information that wasn't previously encoded. If a debugger does not know how to interpret a given attribute, it can skip and ignore it. This is a huge deal for the web, where we tend to take many baby steps rather than a few giant leaps at a time. Any extension to the source map format must strive to remain future extensible.

Lexical Scopes and Bindings

DWARF encodes data about the program's source-level scopes, bindings, and values in a DIE tree.

Consider this example program, fact.c:

#include "stdio.h" static const int FACT_N = 6; int main(int argc, char **argv) { int i = FACT_N; int result = 1; while (i > 0) { result *= i; int decrement = 1; i -= decrement; } printf("%d\n", result); return 0; }

Within this source, there are three scopes we are interested in: the top level, the main function, and the block within the while loop. These scopes nest to form a tree (it would be a more interesting tree with a more complicated example program). DWARF encodes this tree directly with DIEs: scopes have their variables as child DIEs, and nested scopes are also child DIEs of their parent scope's DIE. Different kinds of bindings, such as formal parameters vs. local variables vs. constants, are declared with separate DIE type tags.

Below is a trimmed down subset of the information clang -g fact.c provides to debuggers via DWARF. It depicts the outline of the scope tree and the various bindings within those scopes. You can use the dwarfdump command line tool to view the text representation of the binary DIEs.

0x00000026: TAG_variable [2] AT_name( "FACT_N" ) 0x0000003e: TAG_subprogram [5] * AT_name( "main" ) 0x0000005e: TAG_formal_parameter [6] AT_name( "argc" ) 0x0000006c: TAG_formal_parameter [6] AT_name( "argv" ) 0x0000007a: TAG_variable [7] AT_name( "i" ) 0x00000088: TAG_variable [7] AT_name( "result" ) 0x00000096: TAG_lexical_block [8] * 0x000000a7: TAG_variable [7] AT_name( "decrement" ) 0x000000b5: NULL 0x000000b6: NULL 0x000000c8: NULL

Additionally, the start and end target location bounds of these scopes are embedded as well. These bounds are denoted with the AT_low_pc and AT_high_pc DIE attributes. When the debuggee pauses at a given target location, the debugger finds the innermost scope containing the current target location, and can walk up the DIE tree to find every binding that is in scope.

Here is the DWARF data describing the bounds for the main function, and the while loop's block:

0x0000003e: TAG_subprogram [5] * AT_name( "main" ) AT_low_pc( 0x0000000100000f00 ) AT_high_pc( 0x0000000100000f75 ) 0x00000096: TAG_lexical_block [8] * AT_low_pc( 0x0000000100000f31 ) AT_high_pc( 0x0000000100000f54 ) Locating a Binding's Value

It is not enough to list the names of bindings that are in scope when paused during the program's execution. A debugger must also provide the current values of those bindings so that the user may inspect them for irregularities.

Often, a binding's value is simply at some constant offset from the frame pointer. Other times it is in a specific register. Other times, the situation is a more complicated combination of these cases: for the first n instructions of this function, the parameter's value is located in this register, for the rest it is at that constant offset from the frame pointer. Even other times, a value is not located in one contiguous location! An optimizing compiler is free to explode a struct's members and store one member in a register, another member at this offset from the stack pointer, and to avoid even instantiating a value for the last member because that member is never used by the program.

To handle all of these cases, DWARF employs "location descriptions". These descriptions are expressed in stack-based operations that form a Turing-complete language.

JavaScript does not have frame pointers or registers. It has local, global, lexical, and dynamic (via this) bindings. It has objects and arrays with properties and indices. Because of that mismatch, it doesn't make sense for the source map format to adopt DWARF's location descriptions. Luckily, JavaScript engines already implement a sandboxed language for accessing and manipulating JavaScript values: JavaScript. We can embed snippets of JavaScript within the debugging data to locate a binding's value.

Conclusions

We can extend the source map format to encode the source-level lexical environment, its scopes and bindings, and a way to locate those binding's values. This enables users compiling their programs to JavaScript to do the other half of their debugging: inspecting variables and values as they step through their programs instead of stepping blindly.

However, we must ensure that source maps remain compact for quick downloads and parse times. The format should also be future extensible so we can add additional features down the line and don't need to reach consensus on everything all at once.

Finally, we should follow DWARF's lead and encode the scopes as a tree and embed within each scope its set of bindings, their symbol names, the scope's location boundaries, types, etc. We can reuse JavaScript as our language for describing the location of a binding's value.

If you are interested in being a part of these discussions, please join in at the Source Map RFC Repository.

Thanks to Tom Tromey and Dave Herman for reading drafts.

References
Categorieën: Mozilla-nl planet

Ted Clancy: Musical Interlude

Mozilla planet - fr, 19/06/2015 - 06:51

Categorieën: Mozilla-nl planet

Ted Clancy: ???

Mozilla planet - fr, 19/06/2015 - 06:00

I have no idea where I am. It is completely dark outside and I can’t see a thing.


Categorieën: Mozilla-nl planet

Ted Clancy: Richmond Hill

Mozilla planet - fr, 19/06/2015 - 05:35

We just passed Richmond Hill Centre. I recognize it from the giant Cineplex.

This is an emerging transit hub for York Region. Langstaff GO station is here, and two VIVA lines meet here. There are plans to extend the TTC’s Yonge subway line all the way to here, but they’re held up by the fact that the Yonge Line is already at capacity with regards to ridership.

I remember when there was a proposal to build a casino here, but that didn’t happen. Occasionally you hear people complain that Richmond Hill (and nearby Markham) is too dominated by Chinese people. That’s obviously bullshit. If this place was dominated by Chinese people, there would have been a casino here years ago.


Categorieën: Mozilla-nl planet

Ted Clancy: York Region

Mozilla planet - fr, 19/06/2015 - 05:05

The train is currently stationary, and I figure we’re in York Region, north of Toronto. We passed a sign saying “Parc Downsview Park” about 10 minutes ago, so that must mean we’re on Metrolinx’s Barrie Line (formerly the CNR Newmarket Sub).

According to Wikipedia, this is the oldest trackage in Ontario, dating back to 1835. This track was laid by the Northern Railway of Canada, which was acquired by Grand Trunk Railway in 1888, which was in turn absorbed into CNR in 1923. CNR sold this trackage to Metrolinx in 2009.

I guess we’re waiting for a freight train to pass. (They said that would happen a bit.)

Oh, we’re moving again.


Categorieën: Mozilla-nl planet

Yunier José Sosa Vázquez: Problemas con el cuentaFox [solucionado]

Mozilla planet - fr, 19/06/2015 - 04:16

Hace poco cuentaFox estaba presentado problemas al conectarse con el servicio web para obtener los datos de las cuotas y hoy les traemos una actualización que solventa este problema.

Desde Mozilla han informado que el Addon SDK (CFX) no será utilizado más desarrollar complementos y en su lugar recomiendan JPM, una nueva herramienta para compilar complementos que brinda muchas más ventajas a los desarrolladores.

Por esta razón, desde ahora habrán dos versiones de cuentaFox:

  • una compilada con CFX que no recibirá nuevas funcionalidades y  mantendrá 3.0.X para la versión
  • otra empaquetada con JPM (recomendada) que recibirá nuevas características, estará alojada en GitLab y es necesario utilizar Firefox 38 o superior para que funcione.

¿Qué hay de nuevo en cuentaFox 3.1?
  • Uso de JPM para compilar el complemento.
  • Cambio del servicio web a utilizar.
  • Ahora el ícono de la barra de herramientas muestra emoticons que representan el estado de la cuota.
  • Adicionado el botón Actualizar.
  • Cambiado algunos botones de la interfaz.

A continuación se muestran algunas capturas de esta:

v3.1-emoticons

Cara feliz que representa el estado de la cuota

v3.1-interfaz

Interfaz de la versión 3.1 mostrando una cara alarmada porque la cuota ha sido consumida más del 85%

Si deseas colaborar en el proyecto pues hacerlo desde GitLab. Si tienes alguna nueva funcionalidad en mente, por favor háznosla saber dejando un issue.

Instalar cuentaFox 3.1 (es necesario tener Firefox 38 o superior)

Instalar cuentaFox 3.0.1

Esperamos que les guste es nueva versión, cualquier duda o sugerencia, por favor déjenla en los comentarios.

Categorieën: Mozilla-nl planet

Ted Clancy: The Canadian

Mozilla planet - fr, 19/06/2015 - 04:00

I’m currently sitting aboard Via Rail’s The Canadian, waiting for the train to depart from Toronto’s Union Station. I’m on my way to a company-wide Mozilla event in Whistler.

This isn’t the first time I’ve travelled on Via Rail, but this is the first time I’ll be travelling all the way to Vancouver.

I’m thinking I might live blog it.

Update: Vaughan

The train is currently stationary, and I figure we’re probably in Vaughan, north of Toronto. We passed a sign saying “Parc Downsview Park” about 10 minutes ago, so that must mean we’re on Metrolinx’s Barrie Line (formerly the CNR Newmarket Sub).

According to Wikipedia, this is the oldest trackage in Ontario, dating back to 1835. This track was laid by the Northern Railway of Canada, which was acquired by Grand Trunk Railway in 1888, which was in turn absorbed into CNR in 1923. CNR sold this trackage to Metrolinx in 2009.

I guess we’re waiting for a freight train to pass. (They said that would happen a bit.)

Oh, we’re moving again.

Update: Richmond Hill

We just passed Richmond Hill Centre. I recognize it from the giant Cineplex.

I remember when there was a proposal to build a casino here. But that didn’t happen.

Occasionally you hear people complain that Richmond Hill (and nearby Markham) is too dominated by Chinese people. That’s obviously bullshit. If this place was dominated by Chinese people, there would have been a casino here years ago.

Update: ???

I have no idea where I am. It is completely dark outside and I can’t see a thing.

Update: Musical interlude


Categorieën: Mozilla-nl planet

Marcia Knous: Upcoming joint QA-l10n events

Mozilla planet - fr, 19/06/2015 - 00:40
Jeff Beatty and I have teamed up to work on some interesting "fusion" events in the upcoming quarters. The l10n team has already been planning a bunch of Hackathon style events, so Jeff and I decided it might be interesting to join forces and do some QA presentations at these events.   The first event will be held in July in Lima, Peru, and will be led by Juan and Gabriela of the QA team. The content focus will primarily be on the Firefox Desktop. We also hope to be able to provide the
Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Add-on Compatibility for Firefox 40

Mozilla planet - fr, 19/06/2015 - 00:32

Firefox 40 will be released on August 11th. Here’s the list of changes that went into this version that can affect add-on compatibility. There is more information available in Firefox 40 for Developers, so you should also give it a look.

Extension signing
  • This is the first version of Firefox that will enforce our new signing requirements. All AMO add-ons have already been signed and we’re in the process of reviewing non-AMO add-ons. In this version, there’s a preference to disable the signing requirement (xpinstall.signatures.required), which will be removed in 41.
General XPCOM Themes

Please let me know in the comments if there’s anything missing or incorrect on these lists. If your add-on breaks on Firefox 40, I’d like to know.

The automatic compatibility validation and upgrade for add-ons on AMO will happen in the coming weeks, so keep an eye on your email if you have an add-on listed on our site with its compatibility set to Firefox 39.

Categorieën: Mozilla-nl planet

Air Mozilla: German speaking community bi-weekly meeting

Mozilla planet - to, 18/06/2015 - 21:00

German speaking community bi-weekly meeting Zweiwöchentliches Meeting der deutschsprachigen Community. ==== German speaking community bi-weekly meeting.

Categorieën: Mozilla-nl planet

Mike Conley: On unsafe CPOW usage, and “why is my Nightly so sluggish with e10s enabled?”

Thunderbird - ti, 17/02/2015 - 17:47

If you’ve opened the Browser Console lately while running Nightly with e10s enabled, you might have noticed a warning message – “unsafe CPOW usage” – showing up periodically.

I wanted to talk a little bit about what that means, and what’s being done about it. Brad Lassey already wrote a bit about this, but I wanted to expand upon it (especially since one of my goals this quarter is to get a handle on unsafe CPOW usage in core browser code).

I also wanted to talk about sluggishness that some of our brave Nightly testers with e10s enabled have been experiencing, and where that sluggishness is coming from, and what can be done about it.

What is a CPOW?

“CPOW” stands for “Cross-process Object Wrapper”1, and is part of the glue that has allowed e10s to be enabled on Nightly without requiring a full re-write of the front-end code. It’s also part of the magic that’s allowing a good number of our most popular add-ons to continue working (albeit slowly).

In sum, a CPOW is a way for one process to synchronously access and manipulate something in another process, as if they were running in the same process. Anything that can be considered a JavaScript Object can be represented as a CPOW.

Let me give you an example.

In single-process Firefox, easy and synchronous access to the DOM of web content was more or less assumed. For example, in browser code, one could do this from the scope of a browser window:

let doc = gBrowser.selectedBrowser.contentDocument; let contentBody = doc.body;

Here contentBody corresponds to the <body> element of the document in the currently selected browser. In single-process Firefox, querying for and manipulating web content like this is quick and easy.

In multi-process Firefox, where content is processed and rendered in a completely separate process, how does something like this work? This is where CPOWs come in2.

With a CPOW, one can synchronously access and manipulate these items, just as if they were in the same process. We expose a CPOW for the content document in a remote browser with contentDocumentAsCPOW, so the above could be rewritten as:

let doc = gBrowser.selectedBrowser.contentDocumentAsCPOW; let contentBody = doc.body;

I should point out that contentDocumentAsCPOW and contentWindowAsCPOW are exposed on <xul:browser> objects, and that we don’t make every accessor of a CPOW have the “AsCPOW” suffix. This is just our way of making sure that consumers of the contentWindow and contentDocument on the main process side know that they’re probably working with CPOWs3. contentBody.firstChild would also be a CPOW, since CPOWs can only beget more CPOWs.

So for the most part, with CPOWs, we can continue to query and manipulate the <body> of the document loaded in the current browser just like we used to. It’s like an invisible compatibility layer that hops us right over that process barrier.

Great, right?

Well, not really.

CPOWs are really a crutch to help add-ons and browser code exist in this multi-process world, but they’ve got some drawbacks. Most noticeably, there are performance drawbacks.

Why is my Nightly so sluggish with e10s enabled?

Have you been noticing sluggish performance on Nightly with e10s? Chances are this is caused by an add-on making use of CPOWs (either knowingly or unknowingly). Because CPOWs are used for synchronous reading and manipulation of objects in other processes, they send messages to other processes to do that work, and block the main process while they wait for a response. We call this “CPOW traffic”, and if you’re experiencing a sluggish Nightly, this is probably where the sluggishness if coming from.

Instead of using CPOWs, add-ons and browser code should be updated to use frame scripts sent over the message manager. Frame scripts cannot block the main process, and can be optimized to send only the bare minimum of information required to perform an action in content and return a result.

Add-ons built with the Add-on SDK should already be using “content scripts” to manipulate content, and therefore should inherit a bunch of fixes from the SDK as e10s gets closer to shipping. These add-ons should not require too many changes. Old-style add-ons, however, will need to be updated to use frame scripts unless they want to be super-sluggish and bog the browser down with CPOW traffic.

And what constitutes “unsafe CPOW usage”?

“unsafe” might be too strong a word. “unexpected” might be a better term. Brad Lassey laid this out in his blog post already, but I’ll quickly rehash it.

There are two main cases to consider when working with CPOWs:

  1. The content process is already blocked sending up a synchronous message to the parent process
  2. The content process is not blocked

The first case is what we consider “the good case”. The content process is in a known good state, and its primed to receive IPC traffic (since it’s otherwise just idling). The only bad part about this is the IPC traffic.

The second case is what we consider the bad case. This is when the parent is sending down CPOW messages to the child (by reading or manipulating objects in the content process) when the child process might be off processing other things. This case is far more likely than the first case to cause noticeable performance problems, as the main thread of the content process might be bogged down doing other things before it can handle the CPOW traffic – and the parent will be blocked waiting for the messages to be responded to!

There’s also a more speculative fear that the parent might send down CPOW traffic at a time when it’s “unsafe” to communicate with the content process. There are potentially times when it’s not safe to run JS code in the content process, but CPOWs traffic requires both processes to execute JS. This is a concern that was expressed to me by someone over IRC, and I don’t exactly understand what the implications are – but if somebody wants to comment and let me know, I’ll happily update this post.

So, anyhow, to sum – unsafe CPOW usage is when CPOW traffic is initiated on the parent process side while the content process is not blocked. When this unsafe CPOW usage occurs, we log an “unsafe CPOW usage” message to the Browser Console, along with the script and line number where the CPOW traffic was initiated from.

Measuring

We need to measure and understand CPOW usage in Firefox, as well as add-ons running in Firefox, and over time we need to reduce this CPOW usage. The priority should be on reducing the “unsafe CPOW usage” CPOWs in core browser code.

If there’s anything that working on the Australis project taught me, it’s that in order to change something, you need to know how to measure it first. That way, you can make sure your efforts are having an effect.

We now have a way of measuring the amount of time that Firefox code and add-ons spend processing CPOW messages. You can look at it yourself – just go to about:compartments.

It’s not the prettiest interface, but it’s a start. The second column is the time processing CPOW traffic, and the higher the number, the longer it’s been doing it. Naturally, we’ll be working to bring those numbers down over time.

A possibly quick-fix for a slow Nightly with e10s

As I mentioned, we also list add-ons in about:compartments, so if you’re experiencing a slow Nightly, check out about:compartments and see if there’s an add-on with a high number in the second column. Then, try disabling that add-on to see if your performance problem is reduced.

If so, great! Please file a bug on Bugzilla in this component for the add-on, mention the name of the add-on4, describe the performance problem, and mark it blocking e10s-addons if you can.

We’re hoping to automate this process by exposing some UI that informs the user when an add-on is causing too much CPOW traffic. This will be landing in Nightly near you very soon.

PKE Meter, a CPOW Geiger Counter

Logging “unsafe CPOW usage” is all fine and dandy if you’re constantly looking at the Browser Console… but who is constantly looking at the Browser Console? Certainly not me.

Instead, I whipped up a quick and dirty add-on that plays a click, like a Geiger Counter, anytime “unsafe CPOW usage” is put into the Browser Console. This has already highlighted some places where we can reduce unsafe CPOW usage in core Firefox code – particularly:

  1. The Page Info dialog. This is probably the worse offender I’ve found so far – humongous unsafe CPOW traffic just by opening the dialog, and it’s really sluggish.
  2. Closing tabs. SessionStore synchronously communicates with the content process in order to read the tab state before the tab is closed.
  3. Back / forward gestures, at least on my MacBook
  4. Typing into an editable HTML element after the Findbar has been opened.

If you’re interested in helping me find more, install this add-on5, and listen for clicks. At this point, I’m only interested in unsafe CPOW usage caused by core Firefox code, so you might want to disable any other add-ons that might try to synchronously communicate with content.

If you find an “unsafe CPOW usage” that’s not already blocking this bug, please file a new one! And cc me on it! I’m mconley at mozilla dot com.

  1. I pronounce CPOW as “kah-POW”, although I’ve also heard people use “SEE-pow”. To each his or her own. 

  2. For further reading, Bill McCloskey discusses CPOWs in greater detail in this blog post. There’s also this handy documentation

  3. I say probably, because in the single-process case, they’re not working with CPOWs – they’re accessing the objects directly as they used to. 

  4. And say where to get it from, especially if it’s not on AMO. 

  5. Source code is here 

Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Episode 1)

Thunderbird - mo, 16/02/2015 - 20:29

Here’s the first episode! I streamed it last Wednesday, and it was mostly concerned with bug 1090439, which is about making the print dialog and progress calls from the child process asynchronous.

Here are the notes for that bug. I still haven’t closed it yet, so perhaps I’ll keep pressing on this next Wednesday when I stream Episode 2. We’ll see!

A note that I did struggle with some resolution issues in this episode. I’m working with Richard Milewski from the Air Mozilla team to make this better for the next episode. Sorry about that!

Categorieën: Mozilla-nl planet

Pages