All Hands On Deck – How you can use your skills to contribute to Firefox 57 success

Firefox 57 in making

If you’ve been following Firefox development over the last year, you probably know that we’re hard at work on a major refactor of the browser, codenamed Quantum.

It’s been a very exciting and challenging time with hundreds of engineers bringing to life new concepts and incorporating them into our engineGecko. Those refactors, which will culminate in the release of Firefox 57, touch the very foundation of our engine and require massive changes to it.

We’ve moved the whole engine from a single to multi-process model which is perhaps the hardest possible refactor a major piece of software can go through. We’ve added a whole new systems level programming language, and we’re replacing major components of the engine such as styling and rendering systems. There are substantial changes to our networking layer and security layers as well as completely new components like a new extension ecosystem, virtual reality stack and APZ. We’ve added another new programming language as part of our JS engine and significantly remodeled our build process and infrastructure allowing for quick feature testing, telemetry analysis to understand how our changes impact users and many, many more things.

The changes are massive. This is the largest refactor to Gecko and Firefox in my 17 years of contributing to the project. But we’re not done yet…

Continue reading “All Hands On Deck – How you can use your skills to contribute to Firefox 57 success”

Localization framework changes in Firefox OS 2.0 and plans for 2.1

On Monday we branched Firefox OS 2.0 which is the first branch to contain a new localization library that has been developed by my team.

What landed for 2.0

Library landing and reactions

The library itself landed exactly two months ago. In order to avoid any potential regressions, we’ve put a lot of work to ensure that it matches the behavior of the old code that it replaced. I believe we can now claim a success, because with two months of baking on master we didn’t get any serious regressions that would require us to change anything in our code.

The new library comes with a lot of unit tests and is stricter than the old code, so we had to fix a couple of small bugs where code has been passing an object instead of a string to our API and one related to one test failing on old machine with too little memory. That’s been simple to catch and fix.

We also got a few requests to improve the console log output and error output that the library produces in order to simplify developers work.

New features


The major new thing that Stas completed in this cycle is the support for pseudo-locales. While this could be done with the old code, it was significantly easier with the new code thanks to some architectural decisions like separation of buildtime and runtime code.

Pseudo-locales allow developers to evaluate their UI’s localizability against an artificially generated english-like locale to catch any hardcoded strings. It also generates right-to-left locale for testing purposes. Before that, we’ve been relying on often outdated localizations that we kept with our source code. Now we can always test against fully generated pseudo localization.

mozL10n.once wrapper

Another new feature is the introduction of mozL10n.once wrapper. We identified that a lot of Gaia apps are waiting for localization to be ready before they initialize themselves. That makes sense since a lot of those apps want to work with UI and localized strings, but the challenge in asynchronous world is that you never know if your code has been fired after or before mozL10n is ready.

Because of that, simply setting an event listener and waiting for window.onlocalized event is not enough (what if it already has fired before your code was launched?). Developers were using mozL10n.ready wrapper, but the problem with that is that is has been designed to re-fire on reach retranslation which meant that your init code has been fired every time user changed language. That’s not an intended behavior, but admittedly a rare one. What’s worse is that we retained all the init code in memory.

Now, with mozL10n.once we can safely initialize code when l10n resources are available and free the memory right after that.

Uses of l10n API

On top of adding new features, we’ve been mostly busy investigating and improving how the default Firefox OS apps interact with localization API. That led to multiple design decisions including introduction of the described above mozL10n.once.

Once we got the new wrapper, we started analyzing bootstrapping code of each and every Gaia app and updating it to use the proper L10n API. Twenty two fixed bugs later, we’re done!

It’s incredible how much we were able to accomplish in just two short months. We feel much better right now about the bootstrap process and we have a clear picture on what we want to do next.

Use new navigator.languages API

Thank’s to Mounir’s work on navigator.languages API and implementation we were able to remove the only Mozilla specific API in mozL10n. That means that mozL10n should work in any modern browser now!

What we’re working on for 2.1

2.1 will be as ambitious for us as 2.0 was. The hashtag of the work is still #cleanup, but now it’s much more about modifying our API so that it’s more transparent to developers and requires less manual code in their apps.

entity.attributes become node attributes

First thing we were able to land is the transition away from assigning l10n entity attributes as node properties. We cleaned up the hacks that have been used and switched to entity attributes as node attributes.

DOM overlays

Next, we have one leftover from the previous change and that is an infamous innerHTML. We currently don’t have any clear way to inject localizable DOMFragment in Gaia. Fortunately, we have one that fits perfectly in L20n. It’s called DOM Overlays, and we’re working on getting them into mozL10n. That will allow us to further secure L10n API and remove any innerHTML calls.

Mutation Observers

Majority of localizability code in Gaia apps is related to localization of DOM nodes. With Mutation Observers we will be able to significantly reduce the amount of manual calls to mozL10n API and make majority of calls be just about settings data-l10n-id attribute with Mutation Observers doing the rest.

Not only will it reduce the use cases of mozL10n.translate and mozL10n.localize, but I expect to be able to cut by over 50% the number of manual mozL10n.get calls and manual operations that are currently used to set the result of that call into the node.

Mutation Observers will simplify Gaia code, reduce the amount of bugs related to language switching and get us closer to runtime l10n API that we want to offer for Gecko.


There are still some interesting edge cases around how code boostrapping relies on particular pieces of environment. Does your code need DOM to be interactive? Does it need l10n resources to be loaded? Or maybe you need DOM to be localized? All those events happen asynchronously and we currently do not have a clean way to guard against any combination of those that your init code may require.

We’re working on a bootstrapping wrapper that will allow app developers to simply define which pieces of environment should their initialization be blocked by.

That will further secure the app boostrapping process and limit the risk of condition races.


One part of the bootstrap puzzle is how we fire event when certain bootstrap things happen. Right now we fire window.onlocalized event that means that mozL10n resources have been loaded, but doesn’t tell us anything about if document’s DOM has been localized (and is ready to be displayed).

With the work on the new event, we’ll be able to remove the global one, and settle on triggering on event on document and one on mozL10n object. Did I tell you that we’re still cleaning up? 馃檪

Move mozL10n to document

We originally placed mozL10n object as a property on navigator object. Because our API is transitioning to be per-document, it becomes an inconsistency and an obstacle to keep mozL10n API on navigator object. It hardly fits the world with iframes, ShadowDOM and HTML Templates. We’re going to move it to document.mozL10n.

Remove inline l10n

One of the built time optimizations that we have in Gaia is called inline l10n. We store some portion of the l10n resources within each HTML file in order to localize the UI before it is displayed. It’s not very scalable, costs us memory and performance, but historically helped us prevent flashes of untranslated content. We hope to be able to remove this optimization in this cycle which will significantly simplify our internal code and give us some small memory and performance wins.

Is this L20n yet?

While we introduce L20n concepts into mozL10n, we’re still pretty far from being able to say that we support L20n API in Gaia. There’s a lot of work to do and it’s going to be a challenging work as we port L20n concepts to Gaia, and merge lessons we learned while working on Gaia into L20n spec and implementation. What we hope to end up with is a single codebase used in Gaia and offered to web developers.

It’s an exciting journey and I’m so happy to make Firefox OS’s localizability the most modern among all OSes!

Thunderbird to become the default in Ubuntu!

Great news from Budapest where Ubuntu project is holding their version of our All Hands 馃槈

According to Michael Larabel Thunderbird will become the default choice for Ubuntu’s mail/newsgroup client! That’s a strong prove of progress that Thunderbird has made, and trust me, Ubuntu does not swap the defaults that easily.

Well, it now seems that we’ll have two of our products used as pretty important defaults in this most popular Linux distribution – Firefox and Thunderbird! (although we do have a strong competition for the browser slot).

Congratulations to the team working on Thunderbird!

Mini kampania z okazji wydania Firefoksa 4

Wraz z nadchodz膮cym wydaniem Firefoksa 4 Mozilla planuje ma艂膮 kampani臋 promuj膮c膮 HTML5&Friends. szuka os贸b ch臋tnych do pomocy w t艂umaczeniu tej strony. Oferujemy dost臋p do serwera testowego, niewielk膮 ilo艣膰 string贸w do przet艂umaczenia i spor膮 dawk臋 zas艂u偶onego poczucia dobrze wykonanej roboty.

Zainteresowanych zapraszam do mailowania do mnie (zbraniecki at aviary dot pl) lub od razu do wej艣cia na Verbatim –聽 – zak艂adasz konto i dodajesz sugestie.

Uwaga, wysoka jako艣膰 t艂umaczenia mo偶e skutkowa膰 niemoralnymi ofertami dalszej wsp贸艂pracy ze strony 馃槈

Hard Blockers Counter 1.0

A little bit more of coding, a few bug reports later, HBC is ready for its prime time. Version 1.0 fixes the nasty toolbar height problem, it gives a user an indication of the interval covered by his plot and is just overall better.

It can be downloaded from an listing, and the source code is available at 馃檪

A few of the lessons learned and thoughts:

  • builder is awesome, but it needs more real life users. A lot of bugs are only reproduced after you write your extension for some time, hundreds of revisions etc.
  • AddonSDK is excellent for this kind of extensions. It has everything you may want and makes the whole code extremely clean and simple to write and maintain. Just look at it – about 50 lines of core code – your cat could read that.
  • AddonSDK needs more real life users. Like with the builder, bugs show up only when you really use the extension you created.
  • AMO is an excellent developer friendly platform – it gives me a lot of satisfcators in a form of stats, and ability to manage my extension release process.
  • AMO-builder bindings need more real life users. I felt like I’m the first to try to push builder based extension to AMO – many trivial bugs that can be only revealed if you try to go through the whole thing.
  • AMO’s review/release process is excellent for the extension of the Old Days. It gives us a pool of high quality, verified extensions, that are easy to find and safe to use. It does not work with agile development. Builder and AddonSDK makes creating ad-hoc extensions super simple and quick (literally, 2 hours and you’re done with the first version, every new version is about 15 minutes of work). When you then push it to AMO it feels like Matrix slow motion then – you suddenly wait days for a preliminary review, not to mention almost two weeks you have to wait for a full review. My last revised version is super old comparing to what I claim to be the “stable” one now 馃檨

This issue requires a little bit of description. I do not try to say here, that what AMO reviewers are doing is wrong – quite the opposite, I believe the whole process is excellent and anything that is exposed to the millions of users should get some time to season and be tested and be reviewed. It’s just that AddonSDK/Builder gives you a totally different setup that fits different needs. I believe AMO will need a workflow for extensions that are created in 10 minutes, distributed in 20 minutes, updated 5 times during 4 hours and are becoming useless after one or two days.

Think of a conference where schedule is updated often and people have hard time to track it. Using AddonSDK/Builder you can create an extension for it in literally 20 minutes (xhr, panel, widget). AMO is excellent for distributing it, updating your users etc., but it requires very different approach than say, AdBlock or Firebug. Then, you add a feature (ability to mark the talk you want to attend and get a notification when its room/time changes) and upload a new version 15 minutes later. You want to switch all your users to the new one now. Then you fix a small bug affecting linux users, and update users once again.

It’s amazing that Firefox is becoming a platform where it is possible, and I can’t wait for such application for AMO 馃檪

  • AddonSDK requires a lot of users with their use cases. Myk’s approach is to iterate often which means to get version 1 ASAP and then add new features for version 2 instead of trying to build an ultimate solution without a release. I love this approach and it serves AddonSDK well, but now we need version 2 of many of the packages there – it can only be done if people start using the packages for a real life extensions and report what they miss. Like – Widget content cannot be easily themed. Or, you cannot control Panel’s scrollbar appearance. Jetpack team cannot plan for those use cases, they have to come from jetpack users. So be brave! Try things, report everything you need! 馃檪
  • There is a group of at least 500 people who deeply care about our release process. They’re ready to increase the amount of items on their screen to have a continuous updates on our progress toward Firefox 4. And it’s been just two days. It can motivate people to help, make them feel the sense of progress, help them understand the challenges better. It sucks outsiders closer to the inner circle. I believe we can do much more and the nightly users, mozilla planet readers and the audience of my extension deserve the chance to get more info which can help them start contributing! 馃檪

Hard Blockers Counter 0.8 (0.9) – with a plot!

Tremendous success of the Hard Blockers Counter extension (it got over 300 daily users and 4 positive reviews – yet they were lost in the transition :() motivated me to spend another too-early-morning on adding a history plot for the counter.

It was a real pleasure and a good lesson to go through – simpleStorage, timer, panel, and contentScript communication stuff. I reported some bugs in the toolkit, in the builder and in the builder->amo release process. It’s all been fixed 馃榾
The only real unresolved issues is that the widget affects the height of the toolbar. Reported as bug 626728.

So, 0.8 is ready and waiting, enjoy and fight that bug number down! 馃檪

Source code as always available.

[update] Actually, Builder provided me an old version of my jetpack and I submitted it to AMO as 0.8. So now I added 0.9, but it has to wait to get a review – so if you want colorful plot, download it directly from here.

Wywiad O Fx4 i nie tylko

A偶 trudno uwierzy膰, 偶e nie pisa艂em tu od 2 miesi臋cy… Zagrzeba艂em si臋 w projekt L20n tak g艂臋boko, 偶e nie znajdywa艂em w sobie motywacji do blogowania. :/ Obieca艂em sobie w tym roku to zmienia膰, bo wierz臋, 偶e komunikowanie tego co si臋 robi pomaga ca艂ej spo艂eczno艣ci – zatem spodziewajcie si臋 wi臋cej i krzycie jak b臋d臋 lagowa艂 馃槈

Na pocz膮tek roku podrzucam wywiad kt贸ry ukaza艂 si臋 na – mi艂ej lektury i czekam na opinie 馃檪

We have an important story to tell!

Hey @flod (and Giacomo!)! You touched interesting topics in your latest post, and when I started crafting my comment it got so lengthy, I decided to use my platform to deliver it. Blog-to-blog discussion style! 馃檪

I’ll try to respond, but please, bare in mind, that that’s my personal opinion, nothing official.

You started by pointing out a set of efforts that you either find of questionable value or not “leader” style. Things like Fx UI direction, multiprocessing, Jetpack or Personas.

In particular, you focused on two dimensions:

  1. Are those efforts unique? Innovative? Or do we chase others?
  2. Are those efforts valuable elements that fit into Mozilla Manifesto vision

You question both, and I believe you have all the rights on Earth to do so. We may disagree, but we should talk about this, and I find the fact that you express your concerns in public a good sign of the health of our ecosystem.

So, down to some points you raised. I humbly disagree with your notion of “cloning Chrome”. I believe it is a cognitive impairment that we so easily (we – I mean, most Mozillians I know) buy – this concept of “fresh Chrome”. Chrome is great! But it is not “innovative” in a sense many people talk about it. We just so easily take for granted a lot of inventions we brought to the world, and Chrome, yes, they just looked at Firefox and learned from us. That is just awesome, but that’s what they did!

Once again, Google is looking at an open source project and learns from them how to build a web browser. No, wait! Google, Microsoft and Apple are doing it. Now, how awesome it is? Think of all those things that Firefox brought to the browser landscape since its 1.0 version and notice how many of those innovations are now in IE8, Safari and Chrome.

They also have brilliant developers and *just* bringing all the values of Firefox would be a waste of time, so they, among other things, got a free ride of fixing things we struggled with. And now it is our time to fix those, and there’s nothing unhealthy in this. What would be, in my opinion, unhealthy, is to pretend we don’t see them, and defending our approach as “the right one” (remember Bill Gates first comments on Firefox 1.0?).

Ability to go multi-process is important. Majority of perceived performance improvements that Chrome has (and Fx 3.5/3.6 brought) come from two things: tricking user’s eyes – show him UI 200 ms before its usable – and putting expensive elements off the main thread. (I’m sure that performance team will be able to explain that better). The fact that you have to restart your browser when you install extension is a UX bug. No user expects it or wants it. It does not bring any value and the only reason we have it is a technical limitation.

For years we raised the bar of how the web browser should work. We set the standards in many areas. Opera set some, Safari set some, IE set some as well. Now Chrome set some standards and we just have to match them, possibly using extelligence of our brilliant dev team to push it further and innovate (Jetpack team is far from just fixing issues, they aim for bringing extensions to a new level, and they should be aiming for nothing less than that!). No reason to be worried, we make a great web browser better and it would be unwise to ask our users to trade those nice features for ability to use browser with Mozilla values. Why not give them the best of both?

Personas is an interesting project. I remember my initial feelings when I encountered Personas were much of “eee, nothing interesting”. I considered it to be a minor feature. I recognized that I’m not a target audience (neither you are, I think). But on the day of Fx 3.6 launch I got my lesson when I received amazing amount of feedback from my non-geek friends precisely about Personas and how this project resonated with them. It was amazing for me how emotional people got about “missing Real Madrid Persona, but you have Barcelona one!” or “the pink one is soooo cute” or “my browser is so much more personal now, when my you-name-it favorite actor/actress or symbol of my subculture is here”. Look at the amount of Personas created by people in such a short time! It is an amazing project and only now I see how it fits into Mozilla mission and vibe.

UI on the other hand is a much more complex thing, cause it is related to personal taste and fashion (and fashion itself is, from sociologist point of view a bizarre phenomena of human culture). But imo it all boils down to a simple aspect of cyclical changes. Windows 7 brought new UI, IE8 followed. Chrome followed IE8, Opera followed IE8 or Chrome or both, we’re following W7 or IE8 or Chrome or Opera – you call it. People expect browser to match the visual style of their operating system and Windows 7 is going to be the OS of choice for the vast majority of the world which, in result, will set the UI standard for the OS and apps for quite a some time. We can like it or hate it, but that’s going to happen, and Firefox on Windows should imo fit the OS style. What we will do beyond that is the major issue, and I believe our UI team is trying to come out with the value on top of that. Basing on past experience, I’m sure they’ll do a great job and we’ll see others learning from us. That’s how it works here. Would you prefer vendors to ignore each others accomplishments or deny them?

I disagree with you on your perspective of mobile world. I, for one, wait for Fennec on Android and I know a lot of people who do. I’m excited to think of how we can fit Firefox experience into Windows Mobile 7 and I’m sure it’ll be an exciting journey. Mozilla Messaging is going to generate projects related to forms of communication and I find this topic to be extremely important, so I have no worry about sustainability of it. Our embedding story is nothing to be proud of, but maybe it was a trade-off we had to do in order to achieve what we aimed for. I share your concerns here, and I see many of the platform team people discuss what we can do in order to make it better.

I see Mozilla pretty much self-aware of many of the issues you raised and diversified internally enough to have people raising concerns internally and open enough to have a ground to talk about them – your post is a part of it.

Bottom line

But ultimately I believe your concerns would be all valid if that would be all that is happening in the Mozilla project. If the whole community would work on either Personas, or marketing or UI. But is it? Do you really feel that those elements you describe represent, as you wrote “Mozilla project as a whole“?

I see Mozilla as a meta-project that’s involved in a huge number of projects that touch amazing variety of issues, and it is very hard to nail it down to one or two and call that “representative” for the community.

No matter what you think of Personas, I don’t think you can say that this effort matches what Mozilla is doing with Drumbeat, Bespin, Raindrop or Weave. No matter if you find Jetpack valuable, I hope you did not get lured by press foretelling the end of extensions as we know them. Can you name an example of a project that generated tons of thousands of dependencies and was irresponsibly killed by Mozilla? Have we ever done something like that? Then, do you really think we will do this?

We generate amazing amount of projects of very different kinds. Globally, our community is very diversified and in different points of their journey. Some communities need more marketing, UK, Korea, Sweden? Some, like Italy, Poland, Germany, may have enough internal marketing to consider Mozilla global marketing effort focused on promoting Firefox useless for them or even “too much”. We, Mozillians who live in those countries should act as a membrane which adjusts the signal, and gives feedback to our fellow Mozillians worldwide about what we need, and what we don’t. Poland has 52% of market share, and we need things like developers community or foundation-like efforts to use the potential are trust we generated over years as a platform to bring Mozilla values further, so we work with Mitchell, Mozilla Foundation and from time to time I try to get Paul Rouget’s attention 馃槈 At the same time, PR and marketing wise, we work with Polish PR agency, Barbara and others to balance the amount of press we generate to avoid wasting time to convince the convinced ones. That’s just adjusting. I believe that we should do that much more often in many countries which just are ready for different aspects of Mozilla project to stimulate and energize Mozillians.

Example? Here you are. You think we focus too much on marketing sites? Well, then you focus on other aspects! I believe that the concept of “we have to localize all websites to all languages” is not sustainable anymore. We will generate more websites/webapps, and our local communities will decide which ones to promote locally. We don’t have to have everything localize everywhere and that’s a great power you have to adjust the signal to your locale. Mozilla should make sure all websites/webapps/apps are localizable and let community decide which ones to localize. Focus on the ones that are most important for you!

We have so many projects to pick from! Of different kinds, using different techniques to address different aspects of the common value set expressed in Mozilla Manifesto. They’re also diverse in a way you think about them.

Some of them are truly unique and experimental, and massive – think of our JIT approach (it took a ride from MtV to SF airport for Taras to explain to my what is so different in our JIT approach but now I’m proud of what we’re aiming for), think of L20n, think of Ubiquity,聽 Bespin, Raindrop or Drumbeat.

Some of them, are application of Mozilla-way onto existing concepts. Weave is not innovative because it allows sharing data. But it brought privacy to the picture. SUMO is not the very first support platform ever, but the way we approach the concept of support is innovative and “Mozillian”. Our Metrics team is not the only metrics team in the world, but they do hell a lot of innovation on making their work public and open to contribution which is pretty unique. We may not be the first project ever to have marketing team, but we approach marketing and PR in a unique and innovative way.

Some of them are just a catch-up game and that’s also not bad. We have 350 million users, if someone brought a good idea to the world of web browsers and we can just make sure that 350 million Internet users may use Internet safer, easier and better then I find it pretty important thing to do and I definitely expect such actions from other vendors. (think: partial upgrades)

Ultimately, many of them are a mix of the ones above and as long as we are able to generate new projects that resonate with what people find important on the Internet, I think Mozilla makes an impact and has a bright future that we, including you and me, have to shape.

Mozilla, wolno艣膰 i h.264

Uwaga: poni偶szy tekst, to moja prywatna opinia, jako cz艂onka projektu Mozilla.

W tym tygodniu nast膮pi艂 wa偶ny moment w historii rozwoju WWW. Youtube i Vimeo og艂osi艂y plany odej艣cia od technologii Flash na rzecz standardu HTML5.

Kawa艂ek historii

Blisko rok temu, Mozilla og艂osi艂a wprowadzenie tagu <video/> i rozpocz臋艂a promowanie go, jako alternatywy dla zamkni臋tych wtyczek.

Wiele os贸b wtedy krytykowa艂o t臋 decyzj臋. Zwracano uwag臋, 偶e nikt inny tego nie wprowadza, 偶e HTML5 to jeszcze nie jest standard, 偶e Ogg/Theora, kodek, kt贸rego u偶ywamy, nie jest wystarczaj膮co szybki oraz, 偶e jest za p贸藕no, nikt nie zrezygnuje z zamkni臋tych wtyczek dla otwartego standardu. Ta krytyka nie by艂a bezpodstawna. Wszystkie powy偶sze punkty by艂y prawdziwe.

To, 偶e dzi艣 rozmawiamy o tym z tak odmiennego punktu widzenia pokazuje tylko jak szybko nast臋puj膮 dzi艣 zmiany w 艣wiecie standard贸w w por贸wnaniu do, np. czasu jaki zaj臋艂o wprowadzanie standardu CSS2. To ogromny sukces ca艂ej spo艂eczno艣ci skupionej wok贸艂 WWW i wierz臋, 偶e Mozilla mia艂a w tym decyduj膮c膮 rol臋.

Wracaj膮c do tematu, dzi艣 mamy trzy wa偶ne silniki obs艂uguj膮ce <video/> – Presto (Opera), Webkit (Safari, Chrome) i Gecko (Firefox, Camino, Seamonkey, Flock). Mamy rosn膮c膮 liczb臋 stron, kt贸re korzystaj膮 z tego standardu i rosn膮c膮 liczb臋 u偶ytkownik贸w, kt贸rzy korzystaj膮 z przegl膮darki kt贸ra je obs艂uguje. (W Polsce oko艂o 50% u偶ytkownik贸w Internetu).

Niestety, Chrome i Safari zdecydowa艂y si臋 wspiera膰 wideo obs艂uguj膮c jedynie kodek o nazwie h.264, kt贸ry jest zamkni臋ty i trzeba za niego zap艂aci膰. Mozilla uwa偶a, 偶e taki krok jest szkodliwy dla rozwoju Internetu i stoi w sprzeczno艣ci z Manifestem Mozilli i w efekcie nowe platformy Vimeo i Youtube nie mog膮 by膰 wykorzystywane przez Firefoksa.

Wierzymy, 偶e znajdziemy porozumienie, ale na razie sytuacja jest trudna. W tym po艣cie postaram si臋 wyt艂umaczy膰, dlaczego Mozilla uznaje H.264 za z艂y kodek dla Internetu.

Continue reading “Mozilla, wolno艣膰 i h.264”