mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Mozilla na oči - Budoucnost prohlížení internetu se ukrývá ve virtuální realitě - CDR.cz

Nieuws verzameld via Google - mo, 26/01/2015 - 08:13

Mozilla na oči - Budoucnost prohlížení internetu se ukrývá ve virtuální realitě
CDR.cz
Sedíte v pohodlí domova, otáčíte hlavou, ale co se ve skutečnosti děje kolem vás netušíte. Procházíte se totiž po tajemných zákoutích virtuálního světa. Mozilla se nyní rozhodla prohlížení webu posunout na novou úroveň. Budeme se jím doslova procházet!

Categorieën: Mozilla-nl planet

Mozilla brings virtual reality app support to Firefox's Nightly versions - Firstpost

Nieuws verzameld via Google - mo, 26/01/2015 - 07:03

Firstpost

Mozilla brings virtual reality app support to Firefox's Nightly versions
Firstpost
Last year Mozilla had released a limited version of Firefox which could support web-based virtual reality apps which could be experienced through the Oculus Rift. Mozilla is now bringing this experience on the web albeit only on the Nightly or ...

Categorieën: Mozilla-nl planet

Nick Desaulniers: Writing my first technical book chapter

Mozilla planet - mo, 26/01/2015 - 05:50

It’s a feeling of immense satisfaction when we complete a major achievement. Being able to say “it’s done” is such a great stress relief. Recently, I completed work on my first publication, a chapter about Emscripten for the upcoming book WebGL Insights to be published by CRC Press in time for SIGGRAPH 2015.

One of the life goals I’ve had for a while is writing a book. A romantic idea it seems to have your ideas transcribed to a medium that will outlast your bones. It’s enamoring to hold books from long dead authors, and see that their ideas are still valid and powerful. Being able to write a book, in my eyes, provides some form of life after death. Though, one could imagine ancestors reading blog posts from long dead relatives via utilities like the Internet Archive’s WayBack Machine.

Writing about highly technical content places an upper limit on the usefulness of the content, and shows as “dated” quickly. A book I recently ordered was Scott Meyers’ Effective Modern C++. This title strikes me, because what exactly do we consider modern or contemporary? Those adjectives only make sense in a time limited context. When C++ undergoes another revolution, Scott’s book may become irrelevant, at which point the adjective modern becomes incorrect. Not that I think Scott’s book or my own is time-limited in usefulness; more that technical books’ duration of usefulness is significantly less than philosophical works like 1984 or Brave New World. Almost like having a record in a sport is a feather in one’s cap, until the next best thing comes along and you’re forgotten to time.

Somewhat short of my goal of writing an entire book, I only wrote a single chapter for a book. It’s interesting to see that a lot of graphics programming books seem to follow the format of one author per chapter or at least multiple authors. Such book series as GPU Gems, Shader X, and GPU Pro follow this pattern, which is interesting. After seeing how much work goes into one chapter, I think I’m content with not writing an entire book, though I may revisit that decision later in life.

How did this all get started? I had followed Graham Sellers on Twitter and saw a tweet from him about a call to authors for WebGL Insights. Explicitly in the linked to page under the call for authors was interest in proposals about Emscripten and asm.js.

Want to contribute to a book? @pjcozzi is calling for authors for the new #WebGL Insights. Go here: http://t.co/n7wrXVb4Vl.

— Graham Sellers (@grahamsellers) August 28, 2014

At the time, I was headlong into a project helping Disney port Where’s My Water from C++ to JavaScript using Emscripten. I was intimately familiar with Emscripten, having been trained by one of its most prolific contributors, Jukka Jylänki. Also, Emscripten’s creator, Alon Zakai, sat on the other side of the office from me, so I was constantly pestering him about how to do different things with Emscripten. The #emscripten irc channel on irc.mozilla.org is very active, but there’s no substitute for being able to have a second pair of eyes look over your shoulder when something is going wrong.

Knowing Emscripten’s strengths and limitations, seeing interest in the subject I knew a bit about (but wouldn’t consider myself an expert in), and having the goal of writing something to be published in book form, this was my opportunity to seize.

I wrote up a quick proposal with a few figures about why Emscripten was important and how it worked, and sent it off with fingers crossed. Initially, I was overjoyed to learn when my proposal was accepted, but then there was a slow realization that I had a lot of work to do. The editor, Patrick Cozzi, set up a GitHub repo for our additional code and figures, a mailing list, and sent us a chapter template document detailing the process. We had 6 weeks to write the rough draft, then 6 weeks to work with reviewers to get the chapter done. The chapter was written as a Google Doc, so that we could have explicit control over who we shared the document with, and what kinds of editing power they had over the document. I think this approach worked well.

I had most of the content written by week 2. This was surprising to me, because I’m a heavy procrastinator. The only issue was that the number of pages I wrote was double the allowed amount; way over page count. I was worried about the amount of content, but told myself to try not to be attached to the content, just as you shouldn’t stay attached with your code.

I took the additional 4 weeks I had left to finish the rough draft to invite some of my friends and coworkers to provide feedback. It’s useful to have a short list of people who have ever offered to help in this regard or owe you one. You’ll also want a diverse team of reviewers that are either close to the subject matter, or approaching it as new information. This allows you to stay technically correct, while not presuming your readers know everything that you do.

The strategy worked out well; some of the content I had initially written about how JavaScript VMs and JITs speculate types was straight up wrong. While it played nicely into the narrative I was weaving, someone more well versed in JavaScript virtual machines would be able to call BS on my work. The reviewers who weren’t as close to subject matter were able to point out when logical progressions did not follow.

Fear of being publicly corrected prevents a lot of people from blogging or contributing to open source. It’s important to not stay attached to your work, especially when you need to make cuts. When push came to shove, I did have difficulty removing sections.

Lets say you have three sequential sections: A, B, & C. If section A and section B both set up section C, and someone tells you section B has to go, it can be difficult to cut section B because as the author you may think it’s really important to include B for the lead into C. My recommendation is sum up the most important idea from section B and add it to the end of section A.

For the last six weeks, the editor, some invited third parties, and other authors reviewed my chapter. It was great that others even followed along and pointed out when I was making assumptions based on specific compiler or browser. Eric Haines even reviewed my chapter! That was definitely a highlight for me.

We used a Google Sheet to keep track of the state of reviews. Reviewers were able to comment on sections of the chapter. What was nice was that you were able to keep use the comment as a thread, being able to respond directly to a criticism. What didn’t work so well was then once you edited that line, the comment and thus the thread was lost.

Once everything was done, we zipped up the assets to be used as figures, submitted bios, and wrote a tips and tricks section. Now, it’s just a long waiting game until the book is published.

As far as dealing with the publisher, I didn’t have much interaction. Since the book was assembled by a dedicated editor, Patrick did most of the leg work. I only asked that what royalties I would receive be donated to Mozilla, which the publisher said would be too small (est $250) to be worth the paperwork. It would be against my advice if you were thinking of writing a technical book for the sole reason of monetary benefit. I’m excited to be receiving a hard cover copy of the book when it’s published. I’ll also have to see if I can find my way to SIGGRAPH this year; I’d love to meet my fellow authors in person and potential readers. Just seeing the list of authors was really a who’s-who of folks doing cool WebGL stuff.

If you’re interested in learning more about working with Emscripten, asm.js, and WebGL, I sugguest you pick up a copy of WebGL Insights in August when it’s published. A big thank you to my reviewers: Eric Haines, Havi Hoffman, Jukka Jylänki, Chris Mills, Traian Stanev, Luke Wagner, and Alon Zakai.

So that was a little bit about my first experience with authorship. I’d be happy to follow up with any further questions you might have for me. Let me know in the comments below, on Twitter, HN, or wherever and I’ll probably find it!

Categorieën: Mozilla-nl planet

Mozillaは、ブラウザーでVRをやりたがっている - TechCrunch

Nieuws verzameld via Google - snein, 25/01/2015 - 21:34

Mozillaは、ブラウザーでVRをやりたがっている
TechCrunch
昨年夏、MozillaはFirefoxの非常に実験的なバージョンを公開し、Oculus Riftを使ったウェブベースのバーチャルリアリティーアプリ(WebVR)をサポートした。今週、FirefoxのNighlyデベロッパー版でもWebVRがサポートされた。 ではなぜMozillaは、同社のミッションが「ウェブの ...

Categorieën: Mozilla-nl planet

Mozilla Stuffs Virtual Reality into Main Firefox Builds - PC Magazine

Nieuws verzameld via Google - snein, 25/01/2015 - 21:06

Ghacks Technology News

Mozilla Stuffs Virtual Reality into Main Firefox Builds
PC Magazine
If you're a big virtual reality buff—and we're talking specifically about the Oculus Rift headset, in this case—then you might want to make Firefox your default Web browser as well. Mozilla just unlocked support for WebVR in the company's Nightly and ...
Mozilla Wants To Bring Virtual Reality To The BrowserTechCrunch
Mozilla adds NPAPI plug-in sandbox to FirefoxGhacks Technology News
Mozilla is bringing Virtual Reality to the Web browserThe Tech Portal

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

Mehr Kontrolle über Referrer: Mozilla implement Referrer-Metatag in Firefox - soeren-hentzschel.at

Nieuws verzameld via Google - snein, 25/01/2015 - 16:13

Mehr Kontrolle über Referrer: Mozilla implement Referrer-Metatag in Firefox
soeren-hentzschel.at
Mozilla unterstützt ab Firefox 36 das Referrer-Metatag, um Webseitenbetreibern mehr Kontrolle über den Referrer zu geben und damit die Privatsphäre der Nutzer besser zu schützen. Der Referrer ist eine wichtige Information für Webseitenbetreiber, da ...

Categorieën: Mozilla-nl planet

Mozilla sanal gerçekliği tarayıcı ortamına taşımaya kararlı - DonanimHaber

Nieuws verzameld via Google - snein, 25/01/2015 - 14:58

Mozilla sanal gerçekliği tarayıcı ortamına taşımaya kararlı
DonanimHaber
Mozilla daha önce Firefox'un Oculus VR ile internette sanal gerçekliği destekleyen bir sürümünü deneme aşamasında çıkarmıştı.Şimdi ise Mozilla durumu bir adım da ileri götürerek WebVR özelliklerini "nightly" ve geliştirici sürümlerine ekledi.

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla拟在浏览器中增基于网页的虚拟现实功能 - 搜狐

Nieuws verzameld via Google - snein, 25/01/2015 - 03:19

Mozilla拟在浏览器中增基于网页的虚拟现实功能
搜狐
1月25日,据外国媒体报道,去年夏季,Mozilla推出了一款试验性的Firefox,能够支持基于网页的虚拟现实应用,这样的应用原本需要通过Oculus Rift来体验。但在本周初,支持网页版虚拟现实的应用也终于着陆Firefox ...

en meer »Google Nieuws
Categorieën: Mozilla-nl planet

Gregory Szorc: Automatic Python Static Analysis on MozReview

Mozilla planet - snein, 25/01/2015 - 00:30

A bunch of us were in Toronto last week hacking on MozReview.

One of the cool things we did was deploy a bot for performing Python static analysis. If you submit some .py files to MozReview, the bot should leave a review. If it finds violations (it uses flake8 internally), it will open an issue for each violation. It also leaves a comment that should hopefully give enough detail on how to fix the problem.

While we haven't done much in the way of performance optimizations, the bot typically submits results less than 10 seconds after the review is posted! So, a human should never be reviewing Python that the bot hasn't seen. This means you can stop thinking about style nits and start thinking about what the code does.

This bot should be considered an alpha feature. The code for the bot isn't even checked in yet. We're running the bot against production to get a feel for how it behaves. If things don't go well, we'll turn it off until the problems are fixed.

We'd like to eventually deploy C++, JavaScript, etc bots. Python won out because it was the easiest to integrate (it has sane and efficient tooling that is compatible with Mozilla's code bases - most existing JavaScript tools won't work with Gecko-flavored JavaScript, sadly).

I'd also like to eventually make it easier to locally run the same static analysis we run in MozReview. Addressing problems locally before pushing is a no-brainer since it avoids needless context switching from other people and is thus better for productivity. This will come in time.

Report issues in #mozreview or in the Developer Services :: MozReview Bugzilla component.

Categorieën: Mozilla-nl planet

Gregory Szorc: End to End Testing with Docker

Mozilla planet - snein, 25/01/2015 - 00:10

I've written an extensive testing framework for Mozilla's version control tools. Despite it being a little rough around the edges, I'm a bit proud of it.

When you run tests for MozReview, Mozilla's heavily modified Review Board code review tool, the following things happen:

  • A MySQL server is started in a Docker container.
  • A Bugzilla server (running the same code as bugzilla.mozilla.org) is started on an Apache httpd server with mod_perl inside a Docker container.
  • A RabbitMQ server mimicking pulse.mozilla.org is started in a Docker container.
  • A Review Board Django development server is started.
  • A Mercurial HTTP server is started

In the future, we'll likely also need to add support for various other services to support MozReview and other components of version control tools:

  • The Autoland HTTP service will be started in a Docker container, along with any other requirements it may have.
  • An IRC server will be started in a Docker container.
  • Zookeeper and Kafka will be started on multiple Docker containers

The entire setup is pretty cool. You have actual services running on your local machine. Mike Conley and Steven MacLeod even did some pair coding of MozReview while on a plane last week. I think it's pretty cool this is even possible.

There is very little mocking in the tests. If we need an external service, we try to spin up an instance inside a local container. This way, we can't have unexpected test successes or failures due to bugs in mocking. We have very high confidence that if something works against local containers, it will work in production.

I currently have each test file owning its own set of Docker containers and processes. This way, we get full test isolation and can run tests concurrently without race conditions. This drastically reduces overall test execution time and makes individual tests easier to reason about.

As cool as the test setup is, there's a bunch I wish were better.

Spinning up and shutting down all those containers and processes takes a lot of time. We're currently sitting around 8s startup time and 2s shutdown time. 10s overhead per test is unacceptable. When I make a one line change, I want the tests to be instantenous. 10s is too long for me to sit idly by. Unfortunately, I've already gone to great pains to make test overhead as short as possible. Fig wasn't good enough for me for various reasons. I've reimplemented my own orchestration directly on top of the docker-py package to achieve some significant performance wins. Using concurrent.futures to perform operations against multiple containers concurrently was a big win. Bootstrapping containers (running their first-run entrypoint scripts and committing the result to be used later by tests) was a bigger win (first run of Bugzilla is 20-25 seconds).

I'm at the point of optimizing startup where the longest pole is the initialization of the services inside Docker containers themselves. MySQL takes a few seconds to start accepting connections. Apache + Bugzilla has a semi-involved initialization process. RabbitMQ takes about 4 seconds to initialize. There are some cascading dependencies in there, so the majority of startup time is waiting for processes to finish their startup routine.

Another concern with running all these containers is memory usage. When you start running 6+ instances of MySQL + Apache, RabbitMQ, + ..., it becomes really easy to exhaust system memory, incur swapping, and have performance fall off a cliff. I've spent a non-trivial amount of time figuring out the minimal amount of memory I can make services consume while still not sacrificing too much performance.

It is quite an experience having the problem of trying to minimize resource usage and startup time for various applications. Searching the internet will happily give you recommended settings for applications. You can find out how to make a service start in 10s instead of 60s or consume 100 MB of RSS instead of 1 GB. But what the internet won't tell you is how to make the service start in 2s instead of 3s or consume as little memory as possible. I reckon I'm past the point of diminishing returns where most people don't care about any further performance wins. But, because of how I'm using containers for end-to-end testing and I have a surplus of short-lived containers, it is clearly I problem I need to solve.

I might be able to squeeze out a few more seconds of reduction by further optimizing startup and shutdown. But, I doubt I'll reduce things below 5s. If you ask me, that's still not good enough. I want no more than 2s overhead per test. And I don't think I'm going to get that unless I start utilizing containers across multiple tests. And I really don't want to do that because it sacrifices test purity. Engineering is full of trade-offs.

Another takeaway from implementing this test harness is that the pre-built Docker images available from the Docker Registry almost always become useless. I eventually make a customization that can't be shoehorned into the readily-available image and I find myself having to reinvent the wheel. I'm not a fan of the download and run a binary model, especially given Docker's less-than-stellar history on the security and cryptography fronts (I'll trust Linux distributions to get package distribution right, but I'm not going to be trusting the Docker Registry quite yet), so it's not a huge loss. I'm at the point where I've lost faith in Docker Registry images and my default position is to implement my own builder. Containers are supposed to do one thing, so it usually isn't that difficult to roll my own images.

There's a lot to love about Docker and containerized test execution. But I feel like I'm foraging into new territory and solving problems like startup time minimization that I shouldn't really have to be solving. I think I can justify it given the increased accuracy from the tests and the increased confidence that brings. I just wish the cost weren't so high. Hopefully as others start leaning on containers and Docker more for test execution, people start figuring out how to make some of these problems disappear.

Categorieën: Mozilla-nl planet

Karl Dubost: Working With Transparency Habits. Something To Learn.

Mozilla planet - sn, 24/01/2015 - 23:45

I posted this following text as a comment 3 days ago on Mark Surman's blog on Transparency habits, but it is still in the moderation queue. So instead of taking the chance to lose it. I'm reposting that comment here. This might need to be develop by a followup post.

Mark says:

I encourage everyone at Mozilla to ask themselves: how can we all build up our transparency habits in 2015? If you already have good habits, how can you help others? If, like me, you’re a bit rusty, what small things can you do to make your work more open?

The mistake we often do with transparency is that we think it is obvious for most people. But working in a transparent way requires a lot of education and mentoring. It’s one thing we should try to improve at Mozilla when onboarding new employees. Teaching what it means to be transparent. I’m not even sure everyone has the same notion of what transparency means already.

For example, too many times, I receive emails in private. That’s unfortunate because it creates information silos and it becomes a lot harder to open up a conversation which started in private. Because I was kind of tired of this, I created a set of slides and explanation for learning how to work with emails. Available in French and English.

Some people are afraid of working in the open for many reasons. They may come from a company where secrecy was very strong, or they had a bad experience by being too open. It takes then time to re-learn the benefits of working in the open.

So because you asked an open question :) Some items.

  • Each time you sent an email, it probably belongs to a project. Send the email to the person (To: field) and always add in copy the relevant mailing list (Cc: field). You’ll get an archive, URL pointer for the future, etc.
  • Each time you are explaining something (such as a process, an howto, etc) to someone, make it a blog post, then send this URL to this someone. It will benefit more people on the long term.
  • Each time, you’re having a meeting, choose one scribe and scribe down this meeting and publish the minutes of the meetings. There are many techniques associated to these. See for example the record of Web Compat team meeting on January 13, 2015 and the index of all meetings (I could explain how we manage that in a blog post).
  • Each time you have a F2F meeting with someone or a group, take notes and publish these notes online to a stable URI. It will help other people to participate.

Let's learn together how to work in a transparent way or in the open.

Otsukare.

Categorieën: Mozilla-nl planet

Mozilla Wants To Bring Virtual Reality To The Browser - TechCrunch

Nieuws verzameld via Google - sn, 24/01/2015 - 22:32

Ghacks Technology News

Mozilla Wants To Bring Virtual Reality To The Browser
TechCrunch
Last summer, Mozilla launched a very experimental version of Firefox with support for web-based virtual reality apps that could be experienced through the Oculus Rift. Earlier this week, support for WebVR also landed in Firefox's Nightly and Developer ...
Mozilla adds NPAPI plug-in sandbox to FirefoxGhacks Technology News

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

Stormy Peters: Working in the open is hard

Mozilla planet - sn, 24/01/2015 - 18:59

A recent conversation on a Mozilla mailing list about whether IRC channels should be archived or not shows what a commitment it is to remain open. It’s hard work and not always comfortable to work completely in the open.

Most of us in open source are used to “working in the open”. Everything we send to a mailing list is not only public, but archived and searchable via Google or Yahoo! forever. Five years later, you can go back and see how I did my job as Executive Director of GNOME. Not only did I blog about it, but many of the conversations I had were on open mailing lists and irc channels.

There are many benefits to being open.

Being open means that anybody can participate, so you get much more help and diversity.

Being open means that you are transparent and accountable.

Being open means you have history. You can also go back and see exactly why a decision was made, what the pros and cons were and see if any of the circumstances have changed.

But it’s not easy.

Being open means that when you have a disagreement, the world can follow along. We warn teenagers about not putting too much on social media, but can you imagine every disagreement you’ve ever had at work being visible to all your future employers. (And spouses!)

But those of us working in open source have made a commitment to be open and we try hard.

Many of us get used to working in the open, and we think it feels comfortable and we think we’re good at it. And then something will remind us that it is a lot of work and it’s not always comfortable. Like a conversation about whether irc conversations should be archived or not. IRC conversations are public but not always archived. So people treat them as a place where anyone can drop in but the conversation is bounded in time and limited to the people you can see in the room. The fact that these informal conversations might be archived and read by anyone and everyone later means that you now have to think a lot more about what you are saying. It’s less of a chat and more of a weighed conversation.

The fact that people steeped in open source are having a heated debate about whether Mozilla IRC channels should be archived or not shows that it’s not easy being open. It takes a lot of work and a lot of commitment.

 

Related posts:

  1. Open source feedback (done wrong): “Look, you have food stuck in your teeth!”
  2. 12 tips to getting things done in open source
  3. Open source enables companies to collaborate

Categorieën: Mozilla-nl planet

Doug Belshaw: Weeknote 04/2015

Mozilla planet - sn, 24/01/2015 - 18:30

This week I’ve been:

I wasn’t at BETT this week. It’s a great place to meet people I haven’t seen for a while and last year I even gave a couple of presentations and a masterclass. However, this time around, my son’s birthday and party gave me a convenient excuse to miss it.

Next week I’m working from home as usual. In fact, I don’t think I’m away again until our family holiday to Dubai in February half-term!

Image CC BY Dave Fayram

Categorieën: Mozilla-nl planet

Mozilla adds NPAPI plug-in sandbox to Firefox - Ghacks Technology News

Nieuws verzameld via Google - sn, 24/01/2015 - 15:37

Ghacks Technology News

Mozilla adds NPAPI plug-in sandbox to Firefox
Ghacks Technology News
Sandboxing finally comes to the Firefox web browser. After enabling a (currently) non-restrictive content sandbox in Firefox Nightly last month, the organization enabled the upcoming NPAPI plug-in sandbox in Aurora and Nightly versions of the browser ...

en meer »
Categorieën: Mozilla-nl planet

Mike Hommey: Explicit rename/copy tracking vs. detection after the fact

Mozilla planet - sn, 24/01/2015 - 12:48

One of the main differences in how mercurial and git track files is that mercurial does rename and copy tracking and git doesn’t. So in the case of mercurial, users are expected to explicitly rename or copy the files through the mercurial command line so that mercurial knows what happened. Git simply doesn’t care, and will try to detect after the fact when you ask it to.

The consequence is that my git-remote-hg, being currently a limited prototype, doesn’t make the effort to inform mercurial of renames or copies.

This week, Ehsan, as a user of that tool, pushed some file moves, and subsequently opened an issue, because some people didn’t like it.

It was a conscious choice on my part to make git-remote-hg public without rename/copies detection, because file renames/copies are not happening often, and can just as much not be registered by mercurial users.

In fact, they haven’t all been registered for as long as Mozilla has been using mercurial (see below, I didn’t actually know I was so spot on when I wrote this sentence), and people haven’t been pointed at for using broken tools (and I’ll skip the actual language that was used when talking about Ehsan’s push).

And since I’d rather not make unsubstantiated claims, I dug in all of mozilla-central and related repositories (inbound, b2g-inbound, fx-team, aurora, beta, release, esr*) and here is what I found, only accounting files that have been copied or renamed without being further modified (so, using git diff-tree -r -C100%, and eliminating empty files), and correlating with the mercurial rename/copy metadata:

  • There have been 45069 file renames or copies in 1546 changesets.
  • Mercurial doesn’t know 5482 (12.1%) of them, from 419 (27.1%) changesets.
  • 72 of those changesets were backouts.
  • 19 of those backouts were of changesets that didn’t have rename/copy information, so 53 of those backouts didn’t actually undo what mercurial knew of those backed out changesets.
  • Those 419 changesets were from 144 distinct authors (assuming I didn’t miss some duplicates from people who changed email).
  • Fun fact, the person with colorful language, and that doesn’t like git-remote-hg, is part of them. I am too, and that was with mercurial.
  • The most recent occurrence of renames/copies unknown to mercurial is already not Ehsan’s anymore.
  • The oldest occurrence is in the 19th (!) mercurial changeset.

And that’s not counting all the copies and renames with additional modifications.

Fun fact, this is what I found in the Mercurial mercurial repository:

  • There have been 255 file renames or copies in 41 changesets.
  • Mercurial doesn’t know about 38 (14.9%) of them, from 4 (9.7%) changesets.
  • One of those changesets was from Matt Mackall himself (creator and lead developer of mercurial).

There are 1061 files in mercurial, versus 115845 in mozilla-central, so there is less occasion for renames/copies there, still, even they forget to use “hg move” and break their history as a result.

I think this shows how requiring explicit user input simply doesn’t pan out.

Meanwhile, I have prototype copy/rename detection for git-remote-hg working, but I need to tweak it a little bit more before publishing.

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox 36 beta2 to beta3

Mozilla planet - sn, 24/01/2015 - 11:18

In this beta, as in beta 2, we have a bug fixes for MSE. We have also a few bugs found with the release of Firefox 35. As usual, beta 3 is a desktop only version.

  • 43 changesets
  • 118 files changed
  • 1261 insertions
  • 476 deletions

ExtensionOccurrences cpp17 js13 h7 ini6 html6 jsm3 xml1 webidl1 txt1 svg1 sjs1 py1 mpd1 list1

ModuleOccurrences dom20 browser18 toolkit6 dom4 dom4 testing3 gfx3 netwerk2 layout2 mobile1 media1 docshell1 build1

List of changesets:

Steven MichaudBug 1118615 - Flash hangs in HiDPI mode on OS X running peopleroulette app. r=mstange a=sledru - 430bff48811d Mark GoodwinBug 1096197 - Ensure SSL Error reports work when there is no failed certificate chain. r=keeler, a=sledru - a7f164f7c32d Seth FowlerBug 1121802 - Only add #-moz-resolution to favicon URIs that end in ".ico". r=Unfocused, a=sledru - d00b4a85897c David MajorBug 1122367 - Null check the result of D2DFactory(). r=Bas, a=sledru - 57cb206153af Michael ComellaBug 1116910 - Add new share icons in the action bar for tablet. r=capella, a=sledru - f6b2623900f1 Jonathan WattBug 1122578 - Part 1: Make DrawTargetCG::StrokeRect stroke from the same corner and in the same direction as older OS X and other Moz2D backends. r=Bas, a=sledru - d3c92eebdf3e Jonathan WattBug 1122578 - Part 2: Test start point and direction of dashed stroking on SVG rect. r=longsonr, a=sledru - 7850d99485e6 Mats PalmgrenBug 1091709 - Make Transform() do calculations using gfxFloat (double) to avoid losing precision. r=mattwoodrow, a=sledru - 0b22d12d0736 Hiroyuki IkezoeBug 1118749 - Need promiseAsyncUpdates() before frecencyForUrl. r=mak, a=test-only - 4501fcac9e0b Jordan LundBug 1121599 - remove android-api-9-constrained and android-api-10 mozconfigs from all trees, r=rnewman a=npotb DONTBUILD - 787968dadb44 Tooru FujisawaBug 1115616 - Commit composition string forcibly when search suggestion list is clicked. r=gavin,adw a=sylvestre - 2d629038c57b Ryan VanderMeulenBug 1075573 - Disable test_videocontrols_standalone.html on Android 2.3 due to frequent failures. a=test-only - a666c5c8d0ba Ryan VanderMeulenBug 1078267 - Skip netwerk/test/mochitests/ on Android due to frequent failures. a=test-only - 0c36034999bb Christoph KerschbaumerBug 1121857 - CSP: document.baseURI should not get blocked if baseURI is null. r=sstamm, a=sledru - a9b183f77f8d Christoph KerschbaumerBug 1122445 - CSP: don't normalize path for CSP checks. r=sstamm, a=sledru - 7f32601dd394 Christoph KerschbaumerBug 1122445 - CSP: don't normalize path for CSP checks - test updates. r=sstamm, a=sledru - a41c84bee024 Karl TomlinsonBug 1085247 enable remaining mediasource-duration subtests a=sledru - d918f7ea93fe Sotaro IkedaBug 1121658 - Remove DestroyDecodedStream() from MediaDecoder::SetDormantIfNecessary() r=roc a=sledru - 731843c58e0d Jean-Yves AvenardBug 1123189: Use sourceended instead of loadeddata to check durationchanged count r=karlt a=sledru - 09df37258699 Karl TomlinsonBug 1123189 Queue "durationchange" instead of dispatching synchronously r=cpearce a=sledru - 677c75e4d519 Jean-Yves AvenardBug 1123269: Better fix for Bug 1121876 r=cpearce a=sledru - 56b7a3953db2 Jean-Yves AvenardBug 1123054: Don't check VDA reference count. r=rillian a=sledru - a48f8c55a98c Andreas PehrsonBug 1106963 - Resync media stream clock before destroying decoded stream. r=roc, a=sledru - cdffc642c9b9 Ben TurnerBug 1113340 - Make sure blob urls can load same-prcess PBackground blobs. r=khuey, a=sledru - c16ed656a43b Paul AdenotBug 1113925 - Don't return null in AudioContext.decodeAudioData. r=bz, a=sledru - 46ece3ef808e Masatoshi KimuraBug 1112399 - Treat NS_ERROR_NET_INTERRUPT and NS_ERROR_NET_RESET as SSL errors on https URLs. r=bz, a=sledru - ba67c22c1427 Hector ZhaoBug 1035400 - 'restart to update' button not working. r=rstrong, a=sledru - 8a2a86c11f7c Ryan VanderMeulenBacked out the code changes from changeset c16ed656a43b (Bug 1113340) since Bug 701634 didn't land on Gecko 36. - e8effa80da5b Ben TurnerBug 1120336 - Land the test-only changes on beta. r=khuey, a=test-only - a6e5dedbd0c0 Sami JaktholmBug 1001821 - Wait for eyedropper to be destroyed before ending tests and checking for leaks. r=pbrosset, a=test-only - 4036f72a0b10 Mark HammondBug 1117979 - Fix orange by not relying on DNS lookup failure in the 'error' test. r=gavin, a=test-only - e7d732bf6091 Honza BambasBug 1123732 - Null-check uri before trying to use it. r=mcmanus, a=sledru - 3096b7b44265 Florian QuèzeBug 1103692 - ReferenceError: bundle is not defined in webrtcUI.jsm. r=felipe, a=sledru - 9b565733c680 Bobby HolleyBug 1120266 - Factor some machinery out of test_BufferingWait into mediasource.js and make it Promise-friendly. r=jya, a=sledru - ff1b74ec9f19 Jean-Yves AvenardBug 1120266 - Add fragmented mp4 sample videos. r=cajbir, a=sledru - 53f55825252a Paul AdenotBug 698079 - When using the WASAPI backend, always output audio to the default audio device. r=kinetik, a=sledru - 20f7d44346da Paul AdenotBug 698079 - Synthetize the clock when using WASAPI to prevent A/V desynchronization issues when switching the default audio output device. r=kinetik, a=sledru - 0411d20465b4 Matthew NoorenbergheBug 1079554 - Ignore most UITour messages from pages that aren't visible. r=Unfocused, a=sledru - e35e98044772 Markus StangeBug 1106906 - Always return false from nsFocusManager::IsParentActivated in the parent process. r=smaug, a=sledru - 0d51214654ad Bobby HolleyBug 1121148 - Move constants that we should not be using directly into a namespace. r=cpearce, a=sledru - 1237ddff18be Bobby HolleyBug 1121148 - Make QUICK_BUFFERING_LOW_DATA_USECS a member variable and adjust it appropriately. r=cpearce, a=sledru - 62f7b8ea571f Chris AtLeeBug 1113606 - Use app-specific API keys. r=mshal, r=nalexander, a=gavin - b3836e49ae7f Ryan VanderMeulenBug 1121148 - Add missing detail:: to fix bustage. a=bustage - b3792d13df24

Categorieën: Mozilla-nl planet

Mozilla's Lightbeam for Firefox add-on gets Tracking Protection feature - Ghacks Technology News

Nieuws verzameld via Google - sn, 24/01/2015 - 10:22

Mozilla's Lightbeam for Firefox add-on gets Tracking Protection feature
Ghacks Technology News
You find information about the Tracking Protection feature which Mozilla added recently to Firefox with a click on the link. Unlike full blockers, it is only blocking known tracking domains by default. Blocking those domains should not affect browsing ...

Categorieën: Mozilla-nl planet

Pascal Finette: Weekend Link Pack (Jan 24)

Mozilla planet - sn, 24/01/2015 - 09:00

What I was reading this week:

Categorieën: Mozilla-nl planet

Benjamin Kerensa: Get a free U2F Yubikey to test on Firefox Nightly

Mozilla planet - sn, 24/01/2015 - 01:20

U2F, Yubikey, Universal 2nd FactorPasswords are always going to be vulnerable to being cracked. Fortunately, there are solutions out there that are making it safer for users to interact with services on the web. The new standard in protecting users is Universal 2nd Factor (U2F) authentication which is already available in browsers like Google Chrome.

Mozilla currently has a bug open to start the work necessary to delivering U2F support to people around the globe and bring Firefox into parity with Chrome by offering this excellent new feature to users.

I recently reached out to the folks at Yubico who are very eager to see Universal 2nd Factor (U2F) support in Firefox. So much so that they have offered me the ability to give out up to two hundred Yubikeys with U2F support to testers and will ship them directly to Mozillians regardless of what country you live in so you can follow along with the bug we have open and begin testing U2F in Firefox the minute it becomes available in Firefox Nightly.

If you are a Firefox Nightly user and are interested in testing U2F, please use this form and apply for a code to receive one of these Yubikeys for testing. (This is only available to Mozillians who use Nightly and are willing to help report bugs and test the patch when it lands)

Thanks again to the folks at Yubico for supporting U2F in Firefox!

Categorieën: Mozilla-nl planet

Pages