mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Bobby Holley: MozPromise: A Better Tool for Asynchronous C++

Mozilla planet - ti, 18/08/2015 - 02:00

Last time, I argued that shared mutable state should be considered harmful. To avoid it, threads need to own their data and communicate asynchronously.

The traditional approach to asynchronous programming involves a lot of callbacks: every potentially-asynchronous operation needs to bundle continuation logic as a callback function which gets invoked when the operation completes. This is great in theory, but in practice has a lot of downsides:

  • The control flow is scattered across the callbacks, making the program logic harder to follow. Worse, this difficulty scales linearly with the number of asynchronous operations, creating a perpetual disincentive to make more things asynchronous.
  • The control flow can end mysteriously when an API forgets to invoke the callback. Debugging these cases is much more painful than debugging a synchronous hang, because there’s no backtrace.
  • There tends to be a lot of boilerplate to marshall control flow in and out of messages, and this boilerplate can be easy to get wrong.

These problems span languages and runtimes, but are particularly visible in the Web Platform, whose run-to-completion model forces most interesting APIs to be asynchronous. After a lot of experimentation with different ways to improve the situation, Web developers recently coalesced around Promises as the prevailing idiom for managing asynchronicity. And while Promises certainly have their detractors, most people in the JavaScript community seem to agree that they were a good idea. So why don’t we have something like that in C++?

The answer is complicated. Recent editions of the C++ standard library include a thing called a Promise, but it doesn’t look much like a JavaScript Promise, in large part because C++ itself has no concept of an Event Loop. Gecko has one though, so last November I started building some machinery to mimic the idioms of JavaScript promises in our C++ multimedia stack. This became MediaPromise, was later renamed to MozPromise, and finally moved from dom/media/ to xpcom/.

MozPromises work great, and I already forget how we lived without them. A number of other organizations and researchers have been barking up the same tree this year, which indicates that we’ll likely see a lot more of this kind of thing very soon. The MozPromise API was a quick-and-dirty job, and I expect the industry will iterate on these patterns and eventually produce something more elegant and general. That being said, the core ideas of MozPromise have proven themselves to be exceedingly useful in enabling asynchronicity and parallelism, and I think they’re worth sharing.

The Basics

A method whose result may be computed asynchronously returns a MozPromise. More specifically, it returns an nsRefPtr<MozPromise<ResolveType, RejectType>>, which is templated on the type of values that we want to propagate upon success or failure. Returning a smart pointer directly from a method is generally frowned upon, but we do it anyway. This enables us to compactly follow the MozPromise-returning method with a Then() call, similar to what we’d do in JavaScript:

mProducer->RequestFoo() ->Then(mThread, __func__, this, &ThisClass::OnFooResolved, &ThisClass::OnFooRejected);

Then() takes a strong reference to a callback object (this in the case above), and guarantees that either OnFooResolved(ResolveType) or OnFooRejected(RejectType) will eventually be invoked as an asynchronous event on mThread. We pass __func__ here and elsewhere so that the built-in logging can print out the entire history of control flow (this turns out to be quite useful).

The above already offers several useful advantages over traditional callback-based asynchronicity:

  • The exact callback method is selected by the caller at call time, and not exposed to the underlying API at all. This eliminates boilerplate interfaces, enums, and all the other junk that’s normally needed to hook up and invoke a callback across loosely-coupled modules.
  • The callback is guaranteed to be invoked asynchronously on the thread that the caller intended, without any additional work on the part of the callee. This eliminates common re-entrancy and thread-safety pitfalls.
  • Hangs are easy to diagnose, because we have an object (the MozPromise) which tracks the request we made. The logging facilities make it simple to locate the caller that allocated the MozPromise, even when it’s buried deeply in unfamiliar code.
  • Mandatory first-class error handling.

Even with those advantages, the above code still requires the reader to jump to a different line to follow the control flow. This is often fine, but gets cumbersome when OnFooResolved is one or two lines of code. Fortunately, C++ lambdas allow us to support an alternate overload of Then() with inline callbacks:

mProducer->RequestFoo() ->Then(mThread, __func__, [...] (ResolveType aVal) { ... }, [...] (RejectType aVal) { ... });

Note that the resolve/reject values are always optional, so they may be omitted from the callback signature when unnecessary.

MozPromises are also chainable, provided that the types match up:

mProducer->RequestFoo() ->Then(mThread, __func__, [...] (ResolveType aVal) { ... }, [...] (RejectType aVal) { ... }) ->CompletionPromise() ->Then(mOtherThread, __func__, [...] (ResolveType aVal) { ... }, [...] (RejectType aVal) { ... });

This works much like you’d expect from JavaScript: the first callback can itself return a MozPromise, to which the second Then() is indirectly applied. Unlike JavaScript though, callers must explicitly invoke CompletionPromise() to access the thenable. This allows us to optimize some things in the common case where it isn’t needed. More importantly, it permits us to do something more interesting with the direct return value of Then() - more on that in the section on disconnection below.

InvokeAsync

The core difficulty of owned-data multi-threading comes when logic on thread A needs to interact with data owned by thread B. This is where MozPromise really shines, with the aid of a small helper called InvokeAsync:

InvokeAsync(mOtherThread, [MozPromise-Returning Method])->Then(...)

InvokeAsync dispatches a runnable to an arbitrary thread B to invoke a method that returns a MozPromise. Next, it returns a separate MozPromise of the same type to its caller on thread A. When the target method executes, the returned MozPromise is chained to the one that was returned to the caller on thread A, such that resolution and rejection are propagated through.

This allows for safe and transparent cross-thread procedure calls: thread A can invoke a method on thread B and use the result directly, whether or not A == B. In other words, MozPromises hide the details of message-passing and offer uniform, programmer-friendly ergonomics for same-thread and cross-thread procedure calls. This dramatically reduces the cost of dividing program logic across multiple threads, and puts the fruits of parallelism much more within reach.

Disconnection

MozPromise callbacks are cancellable up until the moment they are invoked, which is very powerful when you want to interrupt the operation of a long, asynchronous pipeline.

Consider the case of seeking a media element in Gecko. The request originates from a user action (manipulating the video controls), which invokes a setter on HTMLMediaElement on the Main Thread. This forwards request to the Decoder State Machine Thread, which queues up work on the Media Decode Thread, which is usually delegated to an OS-specific Platform Decoder Thread.

This presents a serious problem when the user interrupts the action and tries to seek somewhere else before the original seek has completed. There’s a lot of inertia in the pipeline, and we have no way to stop it instantaneously. The first operation may have already completed, and the result might already be on its way back, so we risk getting confused if we initiate a second operation.

So we ended up writing code like this:

mQueuedSeekTarget = newSeekTarget; mReader->DispatchCancelSeekTask(); // Wait for the previous seek to succeed or be canceled. // When everything is finished, we'll check mQueuedSeekTarget // and start seeking again. return;

This is clearly suboptimal, and we can do better with MozPromises.

I mentioned earlier that Then() does not return another MozPromise. This is because it returns a MozPromise::Request, which is a handle to the callback invocation scheduled by Then(). Callers that care can store this value, and invoke Disconnect() if they no longer wish to receive the callback. This allows us to handle interrupt seeks much more elegantly:

mSeekRequest.DisconnectIfExists(); mReader->DispatchCancelSeekTask(); // Move on with life \o/ mSeekRequest.Begin( InvokeAsync(mReader, &Reader::Seek) ->Then(...) );

We use disconnection heavily in Gecko’s media stack, and it is exceedingly useful in handling interruptions, error conditions, and shutdown.

Conclusion

MozPromises solved a lot of tricky problems for the Media Playback Team, and I’d encourage other Gecko hackers to give them a spin. I also welcome thoughts and feedback from the wider community of developers and theorists - I’m sure there are heaps of improvements to be made, and I would be especially interested in concrete suggestions that are practical to implement.

The latest version of the code can be found here, and a snapshot of the code at the time this piece was written can be found here. Patches welcome!

Categorieën: Mozilla-nl planet

A Stable Version Of Mozilla Webmaker For Android Is Now Available In The Play ... - Android Police

Nieuws verzameld via Google - mo, 17/08/2015 - 22:43

Android Police

A Stable Version Of Mozilla Webmaker For Android Is Now Available In The Play ...
Android Police
Webmaker is Mozilla's effort to make it easy for new smartphone users to make content for the web. Instead of creating something using WordPress or Blogger, people can throw materials together using a more simplistic interface. Webmaker has been ...

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla Introduces A New Version Of 'Webmaker' Aimed At Empowering Global ... - Tech Times

Nieuws verzameld via Google - mo, 17/08/2015 - 21:53

Tech Times

Mozilla Introduces A New Version Of 'Webmaker' Aimed At Empowering Global ...
Tech Times
The announcement comes as a follow up on the initial Mozilla Webmaker that launched over three years ago, with the goal of hand-tailoring an intuitive and organic web-creating space that would help people "learn and play using the open building blocks ...
Mozilla offers app to create Web pages on smartphonesITworld
Mozilla's Android Webmaker app launches out of beta to help anyone create ...VentureBeat

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

Air Mozilla: Mozilla Weekly Project Meeting

Mozilla planet - mo, 17/08/2015 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting

Mozilla planet - mo, 17/08/2015 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Mozilla Webmaker, Meet the World

Mozilla Blog - mo, 17/08/2015 - 14:34

Mozilla is excited to announce that Webmaker for Android emerges from beta today. You can download the new version of our free, open source app from Google Play at mzl.la/webmaker.

Mozilla built Webmaker to empower first-time smartphone users and mobile-first Web users as active participants on the Web. Too often, individuals around the world experience a “read-only” mobile Web, passively consuming content and unable to actively contribute. But when consumers become creators, they’re introduced to social and economic opportunity. And when everyone can contribute equally, the Web becomes a better place.

Webmaker

Webmaker is Mozilla’s way of addressing the lack of local content in mobile-first markets. Initially available in four languages (Bengali, Brazilian Portuguese, English and Indonesian) and with more coming soon, the app allows individuals across the globe to create original content in their language and relevant to their community. We built Webmaker after extensive research around the world, and it’s informed by hundreds of volunteers. Webmaker belongs as much to these communities as it does Mozilla.

Webmaker’s hallmark is simplicity: there’s no know-how required, no steep learning curve, and no complex toolbars. Users can create a range of content in minutes — from scrapbooks and art portfolios to games and memes. The intuitive design lets users iterate on the Web’s basic building blocks: text, images and links. With these three fundamentals, our community has already built wonderful creations: how-to manuals, photo albums, digital sketchbooks and wardrobes, exercise handbooks and more. Users are also free to remix and tinker with each other’s Webmaker projects in order to start slowly and steadily expand their creative potential.

Teenagers in Bangladesh using Webmaker

Teenagers in Bangladesh using Webmaker

How is this version different from the Webmaker beta we released in June? In addition to better performance and a more optimal user experience, shared projects can now be viewed on any platform (mobile or desktop), and users with poor connectivity will experience better performance while offline. Also, content discovery is now location-based — you can see what others in your community are creating and remixing.

Ready to discover, create and share local content, and learn the basics of the Web along the way? Download Webmaker today at mzl.la/webmaker. You can find ideas for your first project here.

We’re looking forward to seeing what you make! You can reach us anytime @Webmaker or at help-webmaker@mozilla.com.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Mozilla Webmaker, Meet the World

Mozilla planet - mo, 17/08/2015 - 14:34

Mozilla is excited to announce that Webmaker for Android emerges from beta today. You can download the new version of our free, open source app from Google Play at mzl.la/webmaker.

Mozilla built Webmaker to empower first-time smartphone users and mobile-first Web users as active participants on the Web. Too often, individuals around the world experience a “read-only” mobile Web, passively consuming content and unable to actively contribute. But when consumers become creators, they’re introduced to social and economic opportunity. And when everyone can contribute equally, the Web becomes a better place.

Webmaker

Webmaker is Mozilla’s way of addressing the lack of local content in mobile-first markets. Initially available in four languages (Bengali, Brazilian Portuguese, English and Indonesian) and with more coming soon, the app allows individuals across the globe to create original content in their language and relevant to their community. We built Webmaker after extensive research around the world, and it’s informed by hundreds of volunteers. Webmaker belongs as much to these communities as it does Mozilla.

Webmaker’s hallmark is simplicity: there’s no know-how required, no steep learning curve, and no complex toolbars. Users can create a range of content in minutes — from scrapbooks and art portfolios to games and memes. The intuitive design lets users iterate on the Web’s basic building blocks: text, images and links. With these three fundamentals, our community has already built wonderful creations: how-to manuals, photo albums, digital sketchbooks and wardrobes, exercise handbooks and more. Users are also free to remix and tinker with each other’s Webmaker projects in order to start slowly and steadily expand their creative potential.

Teenagers in Bangladesh using Webmaker

Teenagers in Bangladesh using Webmaker

How is this version different from the Webmaker beta we released in June? In addition to better performance and a more optimal user experience, shared projects can now be viewed on any platform (mobile or desktop), and users with poor connectivity will experience better performance while offline. Also, content discovery is now location-based — you can see what others in your community are creating and remixing.

Ready to discover, create and share local content, and learn the basics of the Web along the way? Download Webmaker today at mzl.la/webmaker. You can find ideas for your first project here.

We’re looking forward to seeing what you make! You can reach us anytime @Webmaker or at help-webmaker@mozilla.com.

Categorieën: Mozilla-nl planet

Christian Heilmann: How about we make ES6 the new baseline?

Mozilla planet - mo, 17/08/2015 - 09:58

Bass strings

During the recording of the web platform’s “Are Web Components ready?” podcast one of the comments stuck with me:

With web components we’re trying to bring ES6-aera technology into an ES5 world. That makes no sense.

There is a lot of interesting logic in that one. Right now, we’re in a bad place with the web. There is a big discussion what we should consider the “modern web” and how to innovate it. And the two sides of the it are at loggerheads:

  • Purists of the web frown upon JavaScript dependency and expect no new feature to break the web. Instead it should build upon what we already have. These are developers wearing battle scars of the browser wars. I count myself amongst them for long time now – I just like things that work and got disappointed by browsers once too often.
  • The more “pragmatic engineering” crowd sees the web as a software platform that needs evolving like every other one does. And one that is falling woefully behind. Native platforms on mobile for example do not worry about breaking existing experiences. It is OK to request the user to have a certain version of an OS to run. The same – in their view – should be OK on the web.

Both are correct, and both are wrong. And I am sick of it. Instead of trying to fix the situation, we bicker over ideas and methodologies. We christen new development approaches with grandiose names. Then we argue for days on end what these mean. We talk about “real world use” without looking at numbers not skewed in favor of certain solutions. And while all that happens, we’re losing the web.

I’m not buying the tales of woe that all users prefer native to the web now. That’s a short-sighted view backed up by sales numbers in affluent countries and our own circles.There is a massive audience out there with no smartphones.

I also don’t buy the argument that native is a fad and the web will prevail in the long run. We need to get better with the web and its technologies. And we won’t do that by pretending what we did twenty years ago is still great.

There is an argument for leaving old browsers without new functionality. The funny thing is that this is also what I, as a person who doesn’t want to break the web, believe in.

Should we stop pushing the web forward?

A few weeks ago Peter-Paul Koch kicked the hornets’ nest when proposing a one year innovation hiatus of browsers in his “Stop pushing the web forward” post.

He pointed out that there is a problem.

  • We have many standards and proposed solutions to the shortcomings of the web. But all are still far away from implementation across browsers.
  • He also pointed out a problem with adoption speed. None of the proposed standards managed to get any traction within a year.

Web Components is the biggest culprit there. This also was one of the findings of the Web Components/Modules panel of EdgeConf this year. It seems that without libraries, Web Components are more or less unusable right now. This is partly because there is a lot of consensus yet to be found as to what they should achieve.

It is hard to write a standard. It is hard to get consensus and buy-in from various browser vendors and their partners. And it is hard to make sure we don’t put a standard in our browsers that turns out to be less than optimal once we have it in there. We had enough of those already.

This is where JavaScript comes in. It has always been the means of adding upcoming functionality to the browsers of now and the ones of the past.

JavaScript is powerful

The great thing about JavaScript is, that it spans all the layers of web development. You can create both HTML and CSS with it (using the DOM and CSSOM or writing out styles inline). You can do so after you tested for capabilities of the browser and – to a degree – the end user. You can even create images, sounds, 3D environments, well – you name it.

JavaScript also successfully moved away from the client side and powers servers, fat-client applications and APIs. In these environments you control JavaScript engine. Originally this was only V8, but now also Chakra is available as an alternative. This sort of control is great for developers who know what they are doing. It also gives us the wrong impression that we could have the same on the web.

The bad thing about JavaScript is that this gives a lot of power to people too busy to use it in a thorough fashion.

  • User agent sniffing is rampant and woefully wrong.
  • A lot of solutions test for touch support and then assume a smartphone, leaving touch-screen devices with the wrong interface.
  • Many users of libraries trust them to fix all issues without verifying.
  • A lot of user agent sniffing checks for a name of a browser instead of the buggy version, thus making fixing those bugs a futile exercise for this product – it will always stay patched.

There is no doubt, that the use case for JavaScript has changed in the last few years and that – for good or worse – our solutions rely on it. This is OK, if we ensure that only those who can get this functionality. We can not make developer convenience result in empty pages.

Empty pages are empty pages

XHTML was killed off because it was too unforgiving. Any encoding problem in our files would have meant our users got an XML error message instead of our products. That’s why we replaced it with HTML5, which uses a much more forgiving parser.

The same problem applies with JavaScript. It is not fault tolerant. Any error that can happen is fatal to the execution of the program. To make matters worse, even the delivery of JavaScript to our end users is riddled with obstacles, bear traps and moats to cross. If you can’t rely on the delivery of your helper library you can easily end up with an empty page instead of the 60fps goodness we work so hard to deliver.

It is time to fix JavaScript

And we need to change JavaScript. It is virtually possible to do everything in JavaScript and you learn about new things and quirks of the language almost every week. Whilst this is fun, it also holds us back. Our success as developers used to be defined by knowing how browsers mess up. Now that we kind of fixed that our job should not be to know the quirks and oddities of a language – it should be to build maintainable, scalable and performant software products.

Our current attempts to improve JavaScript as a language has a few issues. Older browsers getting an EcmaScript 6 script taking advantage of all the good syntax changes see them as a syntax error and break.

That brings us to an impasse: we want to innovate and extend the language, but we have to deal with the issue of legacy environments. Our current solution is the one we always took in case of confusion: we abstract.

Abstraction languages and transpiling

On first glance, this seems like a great idea: we let computers do what they do best, crunching numbers and converting one thing into another. Using a language like TypeScript or a transpiler like Traceur or Babel we gain a lot of benefits:

  • End users don’t get broken experiences. The transpiler converts ES6 to understandable ES5. They may get a lot more code than they would in an ES6 capable environment, but that’d mean they’d need to change their environment – something people only do for very good reasons. Our products are not reason enough – sorry.
  • Developers can use the terser, cleaner syntax of ES6 right now without worrying about breakage in older browsers
  • We can embrace the more structured approach of classes in JavaScript instead of having to get into the “JavaScript mindset”. This means more developers can build for the web.
  • We control the conversion step – turning ES6 into code that runs across browsers happens in the transpiler; a resource we control. That way we can convert only what is necessary to legacy code and use supported features when they happen.

Alas, the last part doesn’t happen right now. Transpiling as it stands now is slow to work in the browser which is why we do it on the server side. There we can not do any capability testing, which means we convert all the ES6 features to the lowest common denominator. That way any of the native support for ES6 in browsers never gets any traction.

In essence, we added ES6 to browsers for internal use only. Developers write ES6, but always run ES5 in the browser.

This also means that we have the problem for developers that we don’t write the code that runs in the browser, but one level up from that. That makes debugging harder and we need to use sourcemaps to connect errors with the line in our source code that caused it. We might also run into the issue where the code generated by the transpiler is faulty and we can’t do anything about it.

The beauty of the web was its immediate connection between creation and consumption. You wrote the code that ran in the browser. Developer tools in the last years became amazingly sophisticated giving us insights into how our code behaves. With abstractions, we forfeit these beautiful options.

We already missed the boat once when DOM became a thing

Let’s turn back the clock a bit. Those of us who’ve been around when the DOM wasn’t standardised and DHTML was a thing remember clearly how terrible that was.

We rejoiced when we got DOM support and we had one API to write against. We even coined a term called “DOM scripting” to make a clear distinction between the DHTML of old and the “modern” code we write now. All of this was based on the simple principle of progressive enhancement using capability testing.

All you did was wrapping your code in a statement that checked if the “modern” DOM was supported:

if (document.getElementById) { // … your code }

And then you used all the crazy new stuff that made our life so much easier: createElement, appendChild, getElementsByTagName. These were great (until we found innerHTML).

Browsers that didn’t make the cut, didn’t get any JavaScript. This has a few benefits:

  • You move forward, without breaking things – browsers that can not run your code, don’t get it. There is a beautiful simplicity in that.
  • You have a clear cut-off point – you know what you support and what you don’t. This cuts down immensely on testing time of your solutions. As you know an IE6 never gets any JavaScript, there is no need to test on it – if you enhanced progressively.
  • You have a reason to write sensible HTML and plain CSS – you know this is your safety blanket that gets delivered to all browsers. And in most cases, having HTML that works without scripting is a great baseline for your more sophisticated solution that happens once JS does its magic.

It was a great idea, and it got some traction. But then it got replaced by something else: abstraction libraries like jQuery, prototype, mootools, YUI and hundreds of others, most of which forgotten. But sadly enough not removed from old implementations.

It’s a kind of magic: here come the libraries

Abstraction libraries promised (and in some cases still promise) us a lot of things:

  • They sanitised across browsers – under the hood, they do a lot of bug workarounds and forking for different browsers to make things work. This is a lot of effort which resulted in browser bugs never getting fixed.
  • They allow to write less and achieve more – which sounds like a very pragmatic way of working. It also means we create more code than is needed. It doesn’t look much to use a few plugins and write 10 lines of abstraction code to create a product. Under the hood, we made ourselves dependent on a lot of magic. We also have a responsibility to keep our helper libraries up-to-date and test in the browsers we now promise to support. We doubled our responsibilities for the sake of not having to be responsible for working around browser issues.
  • They protected us from having to learn about the DOM – we didn’t need to type in those long names or the convoluted way to add a new element using insertBefore().

There is no doubt that the DOM in hindsight is a terrible API and its implementations are buggy. But there is also no doubt that we allowed it to stay that way by abstracting our issues away. Libraries bred a whole generation of developers who see the browser as something to convert code into, not something to write code for. It also slowed down the demands of fixing problems in browsers.

Nowadays, abstraction libraries of the DOM scripting days are landfill of the web. Many don’t get updated and quite a few new features can not be implemented in a straight-forward fashion in browsers as they would break web products relying on library abstractions with the same names.

Cutting the mustard

The idea of DOM scripting was to test for capabilities and use them instead of simulating them with convoluted replacements that work in older browsers. It removed a lot of the hackiness of the web and unspeakable things like writing out content with document.write() inside inline script elements.

The problem with capability testing is that it can backfire:

  • Support for one feature doesn’t mean others are supported – a lot of times browsers support them in waves, depending on demand and complexity.
  • Browsers lie to you – often there was rudimentary support for an object, but browsers lacked the methods it should have come with
  • You never know what you’ll want to support – and testing for each and every feature is tedious

This is why we started defining other cut-off points. The developers in the BBC called this “cutting the mustard” and – after looking at support charts of browsers and testing the real support – defined the following test as a good one to weed out old browsers:

if('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) { // bootstrap the javascript application }

Jake Archibald defined an even more drastic one for mobile products, filtering out both old versions of Internet Explorer and older WebKit on mobiles:

if (!('visibilityState' in document)) return;

You can then layer on more functionality in tests:

if ('visibilityState' in document) { // Modern browser. Let's load JavaScript if ('serviceWorker' in navigator) { // Let's add offline support navigator.serviceWorker.register('sw.js', { scope: './' }); } }

This is great. So here is my proposal. Features of ES6 can be detected – even those that are completely new syntax. Kyle Simpson’s featuretests.io is a pretty comprehensive library full of tests that does exactly that.

How about we make support for a few ES6 features our new “cutting the mustard”?

This results in some good opportunities:

  • We will get real use of ES6 features in browsers – this allows us to improve its performance and find browser issues to fix.
  • We get promises – which not only make async work much easier, but also are the baseline of almost every new API the web really needs (see ServiceWorkers, for example)
  • We are one step closer to real modules in Javascript
  • We will get fetch – a much saner way to load dynamic content than Ajax
  • We have in-built templating

The biggest win: iOS and Safari

Safari has lately become the problem child of the browser space. Many an innovation agreed by other players will fail to get traction if iOS is not on board. It is the stock browser of iOS and no other browser engine is allowed. No matter how much service and interface layer you see in Chrome or Opera for iOS, under the hood ticks the same engine.

And iOS is the golden child of the mobile world: it has the most beautiful devices, the most affluent users not shy about spending money and it doesn’t suffer from the fragmentation issues Android has. Android has larger numbers, but much less revenue per person.

That means what doesn’t run in Safari iOS is not ready to reach the audience the people who pay us deem the most important. Safari is the one and only browser engine on iOS, its roadmap is much foggier than the one of other browsers and its spokespeople are fashionably absent at every public discussion.

This sounds familiar and brings back terrible memories of an Internet Explorer monoculture as explained by Nolan Lawson in Safari is the new IE.

This is not going away any time soon. And many of the standards proposals implemented in Chrome and Firefox are red boxes on caniuse.com in the mobile Safari column.

However, the ES6 support of Mobile Safari is much better.

Can ES6 features make a sensible cut off point?

This is a bold idea. But I think a great one.

  • We have a chance with ES6 to innovate the web much more quickly than we could with other standard proposals that need browser maker agreement.
  • Legacy browsers will never get new APIs, and patching for them with polyfills and libraries results in a mess – better to let them have HTML and CSS
  • This goes hand-in-hand with the extensible web manifesto
  • Using ES6 features in production is the only way to make them perform well in browsers. You can’t optimise what isn’t used.

What do you think? Let’s take a look at support, and define a new “cutting the mustard”, extending this idea from API support to also include syntax changes.

Photo Credit: frankieleon

Categorieën: Mozilla-nl planet

Emily Dunham: RustCamp videos are available

Mozilla planet - mo, 17/08/2015 - 09:00
RustCamp videos are available

The videos from RustCamp are available here.

I asked Gankro what was up with the milkshake thing in his talk, and learned about this meme.

Categorieën: Mozilla-nl planet

Emily Dunham: Folklore and fallacy

Mozilla planet - mo, 17/08/2015 - 09:00
Folklore and fallacy

I was a student employee at the OSU Open Source Lab, on and off between internships and other jobs, for 4 years. Being part of the lab helped shape my life and career, in almost overwhelmingly positive ways. However, the farther I get from the lab the more clearly I notice how being part of it changed the way I form expectations about my own technical skills.

To show you the fallacy that I noticed myself falling into, I’d like to tell you a completely made-up story about some alphabetically named kangaroos. Below the fold, there’ll be pictures!

Read more...

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 92

Mozilla planet - mo, 17/08/2015 - 06:00

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.

From the Blogosphere New Releases & Project Updates New Contributors
  • Alex Ozdemir
  • Chris Krycho
  • Dylan McKay
  • Elaine "See More" Nemo
  • Jonas Schievink
  • llogiq
  • Nathan Kleyn
  • Nicholas Seckar
  • Niranjan Padmanabhan
  • Tim Neumann
  • w00ns
  • Without Boats
Subteam reports

Every week The Rust Team release a report on what is going on in their corner of the project. Here are the highlights from this week's report.

Compiler team

Full report.

Perhaps the most exciting thing going on right now is @huonw's PR implementing the groundwork for SIMD. We've also decided to merge the MIR RFC.

Lang team

Full report.

The following RFCs were promoted to final comment period:

  • RFC #1229, which specifies that when the compiler is doing constant evaluation as a form of optimization, it should not report compilation errors for overflows or other problems that are encountered (warnings are ok). Otherwise, improvements in the constant evaluator can become breaking changes.
  • RFC #1234, which modifies the DST coercion rules to permit PhantomData. The discussion has primarily focused on whether we can indeed make the rules even more accepting than that; conclusion was to leave this for future work.

Full list of T-lang RFCs in FCP.

Some fine fellow (ahem) also started a scintillating discussion on the interaction of type parameter fallback with integral fallback started on internals, which would benefit from more eyeballs:

Last week, we had a number of RFCs enter FCP. Unfortunately, we did not reach final decisions on very many of them, due to Felix Klock being out for some well-earned R&R. However, we did merge a few noncontroversial items:

  • RFC #1209 updates the follow set for types in macros to include ;.
  • RFC #1189 fixes some typos.

We also decided to close several RFCs for prioritization reasons, even if the ideas espoused had merit:

  • RFC 886, allowing "must use" on functions (by @huonw).
  • RFC 890, custom preludes (by @aturon).
  • RFC 1216, promote ! to a type (by @canndrew).
Libs team

Full report.

Starting with the current release cycle (for 1.4), we are making some changes to the stabilization process:

  • All unstable APIs now map to tracking issues. The APIs will be tagged with the issue tracking them, so when you get an error that you need a feature gate, the compiler can also tell you which issue to subscribe to for stabilization. We'll use these issues as a centralized place for discussing questions/concerns about APIs before they are stabilized.

  • Stabilization will be tied to our 6 week release cycles: at the beginning of the cycle, the team will announce a number of unstable features undergoing "final comment period" (heading either toward stabilization or deprecation). The comment period will last for the entire release cycle. One week before the release is cut, the team will make final decisions and land a PR accordingly.

This new process such give much more visibility into the feature pipeline and make the stabilization process easier to follow.

With that in mind, here are the features undergoing FCP for this cycle:

In addition, this week we made the following decisions:

  • FCP PR #1195: ordered query API
  • Close, with the hope that we can find a way to achieve these goals with a smaller API surface
  • FCP PR #1192: RFC for inclusive ranges with ...
  • Merge, with the extra field for Iterator being kept unstable for the time being.

Finally, the following RFC is entering FCP this week:

  • FCP PR #1198: pretty print Debug of tuples, tuple structs and enum variants in a single line
Tool team

Full report.

These past two weeks saw a number of exciting events!

  • Rust 1.2 was released, thanks to @brson for doing the release process!
  • The main site is now hosted over https thanks to @edunham's move from GitHub pages to Cloudfront!
  • make check is now running for 64-bit MSVC. This means that all changes to the compiler must pass all tests on MSVC to land! Note that this is enabled by turning on unwinding for 64-bit MSVC which is in turn enabled by @vadimcn's awesome work on unwinding.
  • The cargo install RFC has been merged.
  • @brson has released a tool for testing whether publishing your crate would cause a regression on reverse dependencies.
  • multirust has gained a which command to locate where binaries are, thanks to @shaleh!
Upcoming Events

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

No jobs listed for this week. Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

"Any sufficiently advanced macro is indistinguishable from magic."barosl at reddit.

Thanks to nasa42 for the tip. Submit your quotes for next week!.

Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Ep. 11): Cleaning up the View Source Patch

Thunderbird - sn, 25/04/2015 - 23:22

For this episode, Richard Milewski and I figured out the syncing issue I’d been having in Episode 9, so I had my head floating in the bottom right corner while I hacked. Now you can see what I do with my face while hacking, if that’s a thing you had been interested in.

I’ve also started mirroring the episodes to YouTube, if YouTube is your choice platform for video consumption.

So, like last week, I was under a bit of time pressure because of a meeting scheduled for 2:30PM (actually the meeting I was supposed to have the week before – it just got postponed), so that gave me 1.5 hours to move forward with the View Source work we’d started back in Episode 8.

I started the episode by explaining that the cache key stuff we’d figured out in Episode 9 was really important, and that a bug had been filed by the Necko team to get the issue fixed. At the time of the video, there was a patch up for review in that bug, and when we applied it, we were able to retrieve source code out of the network cache after POST requests! Success!

Now that we had verified that our technique was going to work, I spent the rest of the episode cleaning up the patches we’d written. I started by doing a brief self-code-review to smoke out any glaring problems, and then started to fix those problems.

We got a good chunk of the way before I had to cut off the camera.

I know back when I started working on this particular bug, I had said that I wanted to take you through right to the end on camera – but the truth of the matter is, the priority of the bug went up, and I was moving too slowly on it, since I was restricting myself to a few hours on Wednesdays. So unfortunately, after my meeting, I went back to hacking on the bug off-camera, and yesterday I put up a patch for review. Here’s the review request, if you’re interested in seeing where I got to!

I felt good about the continuity experiment, and I think I’ll try it again for the next few episodes – but I think I’ll choose a lower-priority bug; that way, I think it’s more likely that I can keep the work contained within the episodes.

How did you feel about the continuity between episodes? Did it help to engage you, or did it not matter? I’d love to hear your comments!

Episode Agenda

References

Bug 1025146 – [e10s] Never load the source off of the network when viewing sourceNotes

Categorieën: Mozilla-nl planet

Meeting Notes: Thunderbird: 2015-04-21

Thunderbird - wo, 22/04/2015 - 05:00

Thunderbird meeting notes 2015-04-21. NOON PT (Pacific). Check https://wiki.mozilla.org/Thunderbird/StatusMeetings for meeting time conversion, previous meeting notes and call-in details

Attendees

ATTENDEES – put your nick 1. below 2. in comments unless explicit under round table 3. top right of etherpad next to your color

mkmelin, rolandt, pegasus, makemyday jorgk, rkent, gneandr, aceman, merike, Paenglab, wsmwk

Action items from last meetings
  • (rkent, Fallen) AMO addon compat: TheOne said that this late it is probably not worth doing at all. WIth so many other things for me to do, that sounds like a plan.
Friends of the tree
  • glandium, for fixing the various packager bugs that will help package Lightning (nominated by Fallen, who won’t be at the meeting)
Critical Issues

Critical bugs. Leave these here until they’re confirmed fixed. If confirmed, then remove.

  • (rkent) I am enormously frustrated by the inability to get two critical features landed in tb 38: OAuth and Lightning integration. Can we please give this very high priority?
    • OAuth integration: partial landing for beta 2, really REALLY critical that we get this finished.
  • In general, the tracking-tb38 flag shows what are critical issues. In the next week or so, that list will be culled to only include true blockers for the Thunderbird 38 release. There will still be many.
  • I don’t think we have a reasonable chance of shipping a quality release on May 12. More realistic is June 2.
  • We need to decide on how to do release branching. I am uncertain whether Lightning integration requires this or not.
  • Auto-complete improvements – some could go into esr31 (bug 1042561 included in TB38)
  • Lightning integration (below) really REALLY critical that we get this finished.
  • maildir UI: nothing more to do for UI, still want to land a patch for letting IMAP set this.
  • gloda IM search regressions: mostly fixed, some db cleanup necessary for users of TB33+ that nhnt11 will hopefully have ready to land soon.
    • aleth landed a fix to stop duplicated entries from appearing, nhnt11 will take care of the cleaning up the databases of Aurora/Beta/Daily users this weekend and keep us updated
  • bug 1140884, might need late-l10n

removing from critical list/fixed:

  • ldap crash bug 1063829: a patch in beta 37, beta results are unclear – not seen in 38
  • bug 1064230 crashes during LDAP search made worse by Search All Addressbooks bug 170270, needs tracking 38+ and review?rkent/jcranmer – not seen in 38
  • everyone should probably skim http://mzl.la/1DaLo0t version 31-38 regressions for items they can help fix or direct to the right people
Releases
  • Past
    • 31.6.0 shipped
    • 38.0b1 shipped 2015-04-03
    • 38.0b2 shipped 2015-04-20
  • Upcoming
    • 38.0b3 (when?)
Lightning to Thunderbird Integration

See https://calendar.etherpad.mozilla.org/thunderbird-integration

  • As underpass has pointed out repeatedly (thanks for your patience!) , we need to rewrite / heavily modify the lightning articles on support.mozilla.org. let me know irc: rolandtanglao on #tb-support-crew or rtanglao AT mozilla.com OR simply start editing the articles

Unfortunately not much progress because I was away. I hope to have the packaging bits done until the weekend. Glandium did a great job on the packager.py changes, hence I nominated him for Friends of the Tree. (fallen)

MakeMyDay should comment on the opt-out dialog, I think we should get it landed asap. bug 1130852 – Opt-Out dialog had some discussion on prefs

Round Table wsmwk
  • managed shipping of 31.6.0, 38.0b1, 38.0b2
Jorg K rkent
  • We have the beginnings of a business development group (rkent, wsmwk, magnus) that after signing NDAs will be given access to Thunderbird business documentation.
mkmelin
  • bug 1134986 autocomplete bug investigated and landed on trunk +++
aceman Question Time

— PLEASE INCLUDE YOUR NICK with your bullet item —

  • What happened to the Avocet branding? (Jorg K)
    • won’t be persued
  • Info about the meeting with Mitchell Baker on 20th March 2015, funding issues (Jorg K)
  • http://mzl.la/1O9khi4 can we get hiro’s bugs reassigned so the patches contained can get landed, and not lost? (wsmwk)
  • It would be great if some jetpack add-on support were available in thunderbird to share functionality with firefox and fennec. See also bug 1100644. No useful jetpack add-ons seem to exist for thunderbird (earlybird would be fine to use jpm over cfx). Are there any jetpack add-ons available to prove me wrong?

(pegasus) Is it worth looking at going to a 6-week release schedule to avoid the conundrum with getting not-quite-ready features in vs delaying?

Support team
  • Reminder: Roland is leaving Thunderbird May 12, 2015 after the release of Thunderbird 38: working on Thunderbird 38 plan and finally kickstarting Thunderbird User Success Council
    • looking for 3 people: English KB Article Editor, L10N Coordinator and Forum Lead. Is that you we’re looking for? If so email rtanglao AT mozilla.com or ping  :rolandtanglao in #sumo or #tb-support-crew
Other
  • PLEASE PUT THE NEXT MEETINGS IN YOUR (LIGHTNING) CALENDAR :)
  • Note – meeting notes must be copied from etherpad to wiki before 5AM CET next day so that they will go public in the meeting notes blog.
Action Items
  • wsmwk to pat glandium
  • wsmwk to email hiro’s bug list to tb-planning
  • rkent to review tracking list
Retrieved from “https://wiki.mozilla.org/index.php?title=Thunderbird/StatusMeetings/2015-04-21&oldid=1069635

Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2015-04-20 Calendar builds

Thunderbird - wo, 22/04/2015 - 04:17

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

  • Fixed: 1003196 – Add icons to more imip bar buttons
  • Fixed: 1137673 – extra divider in the options menu of new task dialog
  • Fixed: 1146500 – Wrong first occurrence for monthly recurrence with BYDAY and BYMONTHDAY
  • Fixed: 1150707 – Make use of tags for running only icaljs/libcal tests
  • Fixed: 1150882 – Lightning incorrectly unified after bug 1143163
  • Fixed: 1151404 – Nightly Windows x64 lightning hits 404 when updating

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: 2015-04-20 Thunderbird comm-central builds

Thunderbird - wo, 22/04/2015 - 04:16

Thunderbird-specific: (27)

  • Fixed: 768480 – Mac OSX TB 13 crashes in nsMsgDBFolder::CreateFileForDB when going online. Caused by folder subscribed on server that no longer exists?
  • Fixed: 849540 – Log in to Gmail (IMAP/SMTP) using OAuth in backend
  • Fixed: 939462 – Feature to count and show number of unread e-mails in subfolders should be optional. (because enumeration is slow)
  • Fixed: 1054308 – Investigate switching Thunderbird comm-central MozMill tests to mozharness
  • Fixed: 1118263 – C-C TB: JavaScript 1.6’s for-each-in loops are deprecated in accountprovisioner and about-support
  • Fixed: 1130852 – Add opt-out notification for calendar integration
  • Fixed: 1134234 – resource://app/modules/gloda/mimemsg.js should be resource:///modules/gloda/mimemsg.js in /mail/test/mozmill/shared-modules/test-message-helpers.js
  • Fixed: 1134986 – Address autocomplete sorting wrong – appears to ignore recent use (popularityindex) information in 31.4.0+
  • Fixed: 1138478 – ‘Write’ toolbar button disabled/greyed out after opening the menus in the Saved Files tab
  • Fixed: 1139524 – Font indicator doesn’t update when cursor is placed in text with this font
  • Fixed: 1140720 – Error reading font prefs in the Slovenian locale
  • Fixed: 1145970 – Port Bug 1005105 to TB [Remove noise from tab textures]
  • Fixed: 1145974 – Move more styles to shared addressbook.css
  • Fixed: 1147006 – TB shows instructions with [File] – [Offline] – [Synchronize] instead of [Download/Sync Now]
  • Fixed: 1147526 – Port Bug 1147311: migrateUI() should migrate font.language.group to a supported value
  • Fixed: 1148369 – “invalid ‘in’ operand colState” when switching folders
  • Fixed: 1148503 – TEST-UNEXPECTED-FAIL | toolkit/components/telemetry/tests/unit/test_TelemetryPing.js | xpcshell return code: 0
  • Fixed: 1149275 – Ensure newly opened conversations get focused
  • Fixed: 1150051 – C-C TB: EXCEPTION: formatted size is not numeric: ‘Read’
  • Fixed: 1150073 – C-C TB: Exception: Found visible column ‘correspondentCol’ but was expecting ‘recipientCol’!
  • Fixed: 1151223 – Reorder mail’s package-manifest.in to minimize differences to browser’s version
  • Fixed: 1152045 – Email address missing from “From” field on emails sent through Thunderbird 38 if the identityName pref was set
  • Fixed: 1152852 – Notification sound for highlights in chats not played if chat tab is selected, even when Thunderbird is not the currently active/focused application (in background)
  • Fixed: 1153511 – TEST-UNEXPECTED_FAIL | check-sync-dirs.py | build file copies are not in sync: differing file: ./win32/mozconfig.vs2013-win64
  • Fixed: 1153551 – Priority button : description missing
  • Fixed: 1154799 – “this._browser.messageManager is undefined” error just by starting Thunderbird
  • Fixed: 1156049 – Port ‘Bug 1155476 – Update sccache to 155c926′ to fix check-sync-dirs.py failure.

MailNews Core-specific: (30)

  • Fixed: 306035 – mail server appended to usernames with “@” (Password dialog for IMAP says <alias>@<domain>@<mailserver> instead of <alias>@<domain> on(at/…) <mailserver>)
  • Fixed: 662907 – web site from RSS feed not rendered correctly (due to noscript tags)
  • Fixed: 810495 – Make the classes which use the XPCOM nsISupports implementation macros final, to avoid the warning about deleting using a pointer to a base class with virtual functions and no virtual dtor
  • Fixed: 1123124 – Remove use of expression closures in mailnews/
  • Fixed: 1126607 – Kill the LDAP build system
  • Fixed: 1132218 – Update comm-central for PLDHashTable changes in bug 1131901
  • Fixed: 1139167 – Some birthdays are off by one day in Thunderbird’s addressbook
  • Fixed: 1139965 – Implement function to export addressbook in vCard format
  • Fixed: 1140652 – deduplicate some JS code writing out a simple string to a file in profile
  • Fixed: 1140884 – An error occurred while sending mail garbled
  • Fixed: 1141735 – unaligned labels in the LDAP server Advanced properties tab
  • Fixed: 1144621 – mimemsg.cpp might leak memory in some instances
  • Fixed: 1144719 – Allow the user to decide whether or not to use libnotify for new-mail alerts on Linux
  • Fixed: 1148887 – Message string for SMTP server connection error is incorrect. File: composeMsgs.properties, key: smtpSendRefused
  • Fixed: 1148888 – Message string for SMTP server connection error is incorrect. File: composeMsgs.properties, key: smtpAuthNotSupported
  • Fixed: 1148957 – Port bug 1148463 by backing out bug 1144128: temporarily disable new performance tools for Aurora uplift
  • Fixed: 1149247 – remove deprecated for-each-in loops in the account manager and account wizard
  • Fixed: 1150176 – Remove nsMemory::Alloc/Free/Realloc from c-c following their removal in bug 1134920
  • Fixed: 1150967 – Port Bug 1147839 to comm-central – Fix building installer on mingw by only including helper.exe if mknsisu is used
  • Fixed: 1150981 – Port Bug 674779 to comm-central – Add per-compartment CPU accounting
  • Fixed: 1151002 – Port Bug 1120308 to comm-central – [Presentation WebAPI] control protocol establishment and offer-answer exchange
  • Fixed: 1151181 – uninitialized error string in mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp
  • Fixed: 1152287 – TEST-UNEXPECTED-FAIL | crypto | Failed to find the appropraite data_path
  • Fixed: 1153187 – Build process is broken while reticulating splines “Variable SHARED_LIBRARY_LIBS” involved.
  • Fixed: 1153543 – when adding a new identity, the smtp server menulist is collapsed with no default item selected
  • Fixed: 1153557 – do away with preprocessing in am-identity-edit.js due to identity.autocompleteToMyDomain
  • Fixed: 1154468 – unused function getServerIdAndPageIdFromTree in am-identity-edit.xul
  • Fixed: 1155951 – Fix a non-array delete for scalars
  • Fixed: 1155953 – Remove Structurally dead code in nsNNTPProtocol.cpp
  • Fixed: 1155955 – remove a self assignment in nsImapUtils.cpp

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

Mike Conley: Things I’ve Learned This Week (April 13 – April 17, 2015)

Thunderbird - snein, 19/04/2015 - 00:33
When you send a sync message from a frame script to the parent, the return value is always an array

Example:

// Some contrived code in the browser let browser = gBrowser.selectedBrowser; browser.messageManager.addMessageListener("GIMMEFUE,GIMMEFAI", function onMessage(message) { return "GIMMEDABAJABAZA"; }); // Frame script that runs in the browser let result = sendSendMessage("GIMMEFUE,GIMMEFAI"); console.log(result[0]); // Writes to the console: GIMMEDABAJABAZA

From the documentation:

Because a single message can be received by more than one listener, the return value of sendSyncMessage() is an array of all the values returned from every listener, even if it only contains a single value.

I don’t use sync messages from frame scripts a lot, so this was news to me.

You can use [cocoaEvent hasPreciciseScrollingDeltas] to differentiate between scrollWheel events from a mouse and a trackpad

scrollWheel events can come from a standard mouse or a trackpad1. According to this Stack Overflow post, one potential way of differentiating between the scrollWheel events coming from a mouse, and the scrollWheel events coming from a trackpad is by calling:

bool isTrackpad = [theEvent hasPreciseScrollingDeltas];

since mouse scrollWheel is usually line-scroll, whereas trackpads (and Magic Mouse) are pixel scroll.

The srcdoc attribute for iframes lets you easily load content into an iframe via a string

It’s been a while since I’ve done web development, so I hadn’t heard of srcdoc before. It was introduced as part of the HTML5 standard, and is defined as:

The content of the page that the embedded context is to contain. This attribute is expected to be used together with the sandbox and seamless attributes. If a browser supports the srcdoc attribute, it will override the content specified in the src attribute (if present). If a browser does NOT support the srcdoc attribute, it will show the file specified in the src attribute instead (if present).

So that’s an easy way to inject some string-ified HTML content into an iframe.

Primitives on IPDL structs are not initialized automatically

I believe this is true for structs in C and C++ (and probably some other languages) in general, but primitives on IPDL structs do not get initialized automatically when the struct is instantiated. That means that things like booleans carry random memory values in them until they’re set. Having spent most of my time in JavaScript, I found that a bit surprising, but I’ve gotten used to it. I’m slowly getting more comfortable working lower-level.

This was the ultimate cause of this crasher bug that dbaron was running into while exercising the e10s printing code on a debug Nightly build on Linux.

This bug was opened to investigate initializing the primitives on IPDL structs automatically.

Networking is ultimately done in the parent process in multi-process Firefox

All network requests are proxied to the parent, which serializes the results back down to the child. Here’s the IPDL protocol for the proxy.

On bi-directional text and RTL

gw280 and I noticed that in single-process Firefox, a <select> dropdown set with dir=”rtl”, containing an <option> with the value “A)” would render the option as “(A”.

If the value was “A) Something else”, the string would come out unchanged.

We were curious to know why this flipping around was happening. It turned out that this is called “BiDi”, and some documentation for it is here.

If you want to see an interesting demonstration of BiDi, click this link, and then resize the browser window to reflow the text. Interesting to see where the period on that last line goes, no?

It might look strange to someone coming from a LTR language, but apparently it makes sense if you’re used to RTL.

I had not known that.

Some terminal spew Some terminal spew

Now what’s all this?

My friend and colleague Mike Hoye showed me the above screenshot upon coming into work earlier this week. He had apparently launched Nightly from the terminal, and at some point, all that stuff just showed up.

“What is all of that?”, he had asked me.

I hadn’t the foggiest idea – but a quick DXR showed basic_code_modules.cc inside Breakpad, the tool used to generate crash reports when things go wrong.

I referred him to bsmedberg, since that fellow knows tons about crash reporting.

Later that day, mhoye got back to me, and told me that apparently this was output spew from Firefox’s plugin hang detection code. Mystery solved!

So if you’re running Firefox from the terminal, and suddenly see some basic_code_modules.cc stuff show up… a plugin you’re running probably locked up, and Firefox shanked it.

  1. And probably a bunch of other peripherals as well 

Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Ep. 10): The Mystery of the Cache Key

Thunderbird - sn, 18/04/2015 - 23:40

In this episode, I kept my camera off, since I was having some audio-sync issues1.

I was also under some time-pressure, because I had a meeting scheduled for 2:30 ET2, giving me exactly 1.5 hours to do what I needed to do.

And what did I need to do?

I needed to figure out why an nsISHEntry, when passed to nsIWebPageDescriptor’s loadPage, was not enough to get the document out from the HTTP cache in some cases. 1.5 hours to figure it out – the pressure was on!

I don’t recall writing a single line of code. Instead, I spent most of my time inside XCode, walking through various scenarios in the debugger, trying to figure out what was going on. And I eventually figured it out! Read this footnote for the TL;DR:3

Episode Agenda

References

Bug 1025146 – [e10s] Never load the source off of the network when viewing sourceNotes

  1. I should have those resolved for Episode 11! 

  2. And when the stream finished, I found out the meeting had been postponed to next week, meaning that next week will also be a short episode. :( 

  3. Basically, the nsIChannel used to retrieve data over the network is implemented by HttpChannelChild in the content process. HttpChannelChild is really just a proxy to a proper nsIChannel on the parent-side. On the child side, HttpChannelChild does not implement nsICachingChannel, which means we cannot get a cache key from it when creating a session history entry. With no cache key, comes no ability to retrieve the document from the network cache via nsIWebDescriptor’s loadPage. 

Categorieën: Mozilla-nl planet

Mike Conley: Things I’ve Learned This Week (April 6 – April 10, 2015)

Thunderbird - snein, 12/04/2015 - 16:50
It’s possible to synthesize native Cocoa events and dispatch them to your own app

For example, here is where we synthesize native mouse events for OS X. I think this is mostly used for testing when we want to simulate mouse activity.

Note that if you attempt to replay a queue of synthesized (or cached) native Cocoa events to trackSwipeEventWithOptions, those events might get coalesced and not behave the way you want. mstange and I ran into this while working on this bug to get some basic gesture support working with Nightly+e10s (Specifically, the history swiping gesture on OS X).

We were able to determine that OS X was coalescing the events because we grabbed the section of code that implements trackSwipeEventWithOptions, and used the Hopper Disassembler to decompile the assembly into some pseudocode. After reading it through, we found some logging messages in there referring to coalescing. We noticed that those log messages were only sent when NSDebugSwipeTrackingLogic was set to true, we executed this:

defaults write org.mozilla.nightlydebug NSDebugSwipeTrackingLogic -bool YES

In the console, and then re-ran our swiping test in a debug build of Nightly to see what messages came out. Sure enough, this is what we saw:

2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 coalescing scrollevents 2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 cumulativeDelta:-2.000 progress:-0.002 2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 cumulativeDelta:-2.000 progress:-0.002 adjusted:-0.002 2015-04-09 15:11:55.396 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 call trackingHandler(NSEventPhaseChanged, gestureAmount:-0.002)

This coalescing means that trackSwipeEventWithOptions is only getting a subset of the events that we’re sending, which is not what we had intended. It’s still not clear what triggers the coalescing – I suspect it might have to do with how rapidly we flush our native event queue, but mstange suspects it might be more sophisticated than that. Unfortunately, the pseudocode doesn’t make it too clear.

String templates and toSource might run the risk of higher memory use?

I’m not sure I “learned” this so much, but I saw it in passing this week in this bug. Apparently, there was some section of the Marionette testing framework that was doing request / response logging with toSource and some string templates, and this caused a 20MB regression on AWSY. Doing away with those in favour of old-school string concatenation and JSON.stringify seems to have addressed the issue.

When you change the remote attribute on a <xul:browser> you need to re-add the <xul:browser> to the DOM tree

I think I knew this a while back, but I’d forgotten it. I actually re-figured it out during the last episode of The Joy of Coding. When you change the remoteness of a <xul:browser>, you can’t just flip the remote attribute and call it a day. You actually have to remove it from the DOM and re-add it in order for the change to manifest properly.

You also have to re-add any frame scripts you had specially loaded into the previous incarnation of the browser before you flipped the remoteness attribute.1

Using Mercurial, and want to re-land a patch that got backed out? hg graft is your friend!

Suppose you got backed out, and want to reland your patch(es) with some small changes. Try this:

hg update -r tip hg graft --force BASEREV:ENDREV

This will re-land your changes on top of tip. Note that you need –force, otherwise Mercurial will skip over changes it notices have already landed in the commit ancestry.

These re-landed changes are in the draft stage, so you can update to them, and assuming you are using the evolve extension2, and commit –amend them before pushing. Voila!

Here’s the documentation for hg graft.

  1. We sidestep this with browser tabs by putting those browsers into “groups”, and having any new browsers, remote or otherwise, immediately load a particular set of framescripts. 

  2. And if you’re using Mercurial, you probably should be. 

Categorieën: Mozilla-nl planet

Pages