Mozilla DevCenter
oreilly.comSafari Books Online.Conferences.

Sponsored Developer Resources

Atom 1.0 Feed RSS 1.0 Feed RSS 2.0 Feed

Related O'Reilly Books

What Is Firefox What Is Firefox
Brian King provides a brief look at Firefox's origins and evolution, and then dives into its support for web standards like CSS and XML, its debugging and extension capabilities, and some cool new features in the upcoming 1.5 release. If you're considering a switch to Firefox, this article may help make the decision for you.

Mozilla as a Development Platform: An Interview with Axel Hecht  Axel Hecht is a member of Mozilla Europe's board of directors, and a major contributor to the Mozilla project. At O'Reilly's European Open Source Convention (October 17-20), Dr. Hecht will be talking about Mozilla as a development platform. O'Reilly Network interviewed Dr. Hecht to find out if the long-held dream of Mozilla as a development platform was about to come true.   [O'Reilly Network]

A Firefox Glossary  Brian King, with some help from Nigel McFarlane, covers everything from about:config to "zool" in this fun, fact-filled Firefox glossary. It's by no means exhaustive, but you'll find references to specific chapters or hacks throughout the glossary to Nigel's book, Firefox Hacks. When you're ready to dig deeper, check out his book.   [O'Reilly Network]

Important Notice for Mozilla DevCenter Readers About O'Reilly RSS and Atom Feeds  O'Reilly Media, Inc. is rolling out a new syndication mechanism that provides greater control over the content we publish online. Here's information to help you update your existing RSS and Atom feeds to O'Reilly content.  [Mozilla DevCenter]

Hacking Firefox  This excerpt from Firefox Hacks shows you how to use overlays (essentially hunks of UI data) to make something you want to appear in the Firefox default application, perhaps to carry out a particular function of your extension. For example, you might want to add a menu item to the Tools menu to launch your extension. Overlays allow existing Firefox GUIs to be enhanced.   [O'Reilly Network]

Mozile: What You See is What You Edit  Most modern browsers don't allow you to hit "edit" and manipulate content as easily as you view it, WYSIWYG-style. Mozile, which stands for Mozilla Inline Editor, is a new Mozilla plug-in for in-browser editing. This article by Conor Dowling provides an overview of Mozile and what in-browser editing means.
  [ Mozilla DevCenter]

The Future of Mozilla Application Development  Recently, announced a major update to its development roadmap. Some of the changes in the new document represent a fundamental shift in the direction and goals of the Mozilla community. In this article, David Boswell and Brian King analyze the new roadmap, and demonstrate how to convert an existing XPFE-based application into an application that uses the new XUL toolkit. David and Brian are the authors of O'Reilly's Creating Applications with Mozilla.   [Mozilla DevCenter]

Remote Application Development with Mozilla, Part 2  In their first article, Brian King, coauthor of Creating Applications with Mozilla, and Myk Melez looked at the benefits of remote application development using Mozilla technologies such as XUL and web services support. In this article, they present a case study of one such application, the Mozilla Amazon Browser, a tool for searching Amazon's catalogs.   [Mozilla DevCenter]

Remote Application Development with Mozilla  This article explores the uses for remote XUL (loaded from a Web server), contrasts its capabilities with those of local XUL (installed on a user's computer), explains how to deploy remote XUL, and gives examples of existing applications.   [Mozilla DevCenter] Made Easy  Now that is about to release Mozilla 1.2 and Netscape has come out with the latest version of their own Mozilla-based browser, Netscape 7, this is a great time to see what other people are building with Mozilla's cross-platform development framework. Here's a little history about, and a roadmap to,   [Mozilla DevCenter]

XML Transformations with CSS and DOM  Mozilla permits XML to be rendered in the browser with CSS and manipulated with DOM. If you're already familiar with CSS and DOM, you're more than halfway to achieving XML transformations in Mozilla. This article demonstrates how to render XML in the browser with a minimum of CSS and JavaScript.   [Mozilla DevCenter]

Roll Your Own Browser  Here's a look at using the Mozilla toolkit to customize, or even create your own browser.   [Mozilla DevCenter]

Let One Hundred Browsers Bloom  In this article, David Boswell, coauthor of Creating Applications with Mozilla surveys some of the more interesting, and useful, Mozilla-based browsers available now.   [Mozilla DevCenter]

Using the Mozilla SOAP API  With the release of Mozilla 1.0, the world now has a browser that supports SOAP natively. This article shows you how Web applications running in Mozilla can now make SOAP calls directly from the client without requiring a browser refresh or additional calls to the server.   [Web Development DevCenter]

Today's News
August 01, 2014

Pascal Finette: A Personal Update

Last year, on November 11th I joined Exactly 90 days later I quit.

My plan for 2014 was to take some time off and focus on the things I love doing most - which is the magic which happens at the intersection of entrepreneurship, technology and impact.

I founded/co-founded two non-profits: POWERUP and The Coaching Fellowship. I did a ton of public speaking and mentored a whole bunch of entrepreneurs. I spent a week in Boulder, CO, working with the incredible Unreasonable Institute. I worked with a couple of very large companies on their innovation strategy. I became an executive coach working with some of the most inspiring individuals I’ve ever met.

And then everything changed.

For a long time I’ve been a huge fan of the work being done at Singularity University. Their mission of leveraging bleeding edge technologies to solve for the most intractable problems in the world is what I live and breath. It feels like we have been circling each other for a long time now - I have spoken a whole bunch of people there for years; and every conversation ended with “we should do something together”.

That “something” is now here!

Today I joined Singularity University to head up their Startup Lab.

We grow startups solving the world’s most intractable problems. We support, convene, collaborate and innovate. We bring the support of the world’s biggest companies to the table. We work together with the leading impact organizations worldwide.

I am at home. Let’s get cranking!

[Source: Planet Mozilla]

Frédéric Harper: HTML5 to the next level, the recording of my presentation at Montreal Python


Last month I spoke at the monthly Python Montréal meetup about, guess what, Firefox OS. I already uploaded the slides online, and now the recording of my talk.

Thanks again to the friend Christian Aubry, who, like always, did an amazing job with the recording. Thanks also to Python Montréal for having me and Google Montréal for sponsoring the event.

HTML5 to the next level, the recording of my presentation at Montreal Python is a post on Out of Comfort Zone from Frédéric Harper

[Source: Planet Mozilla]

Karl Dubost: IE is aliasing some WebKit properties

DOUBLE RAINBOW. Microsoft Internet Explorer is aliasing some of the WebKit properties. Read their blog post The Mobile Web should just work for everyone.

Two men around a fire

A little while ago I was working for Opera in the Open The Web (aka Web Compatibility) team when Opera decided an experiment for Opera on Mobile. A version of the browser was released with aliases for popular CSS WebKit prefixes which were often forgotten by Web developers and name_here_your_popular framework. I can tell you that it didn't please anyone in particular at Opera, but as Bruce is mentionning in his blog post:

It’s difficult to argue for ideological purity when a simple aliasing makes the user experience so demonstrably better – and one thing I’ve learned at Opera is most users don’t care two hoots for ideology if their favourite site works better in another browser.

Any Web professional who is shocked by IE announcement has first to go through a serious introspection assessment about his/her own Web practices. What is the browser you are using on Desktop, on Mobile? Do you even know what is it to use a Web browser which is not Webkit compatible as your main browser, not just for testing? Go use Firefox for Android for one year or IE on mobile and then talk about the issues at stake. Mike on his blog, Hallvord on his and here myself are regularly talking about these issues. We specifically started because of these issues. IE Team is participating to this. We hope to get wider participation from Chrome and Opera teams too.

No, what IE has announced is not surprising or even shocking. What really surprises me is that they didn't in fact fully switch to Blink or implemented a dual rendering engine. I'm not in the known, but I would not be surprised it happens one day. That would left Mozilla in a pretty nasty place of the Web and would probably force Mozilla to switch to Blink.

After wiping out all our tears if this was announced that would raise an interesting set of questions on Web governance around some projects. For example, you could imagine that Blink becomes a real opensource library not mainly controlled by Google. You may be too young for remembering, but at the very beginning of the Web most Web clients were using a single common opensource library: LibWWW.

The common code library is the basis for most browers. It contains the network access code and format handling.

Note that I'm not wishing a Blink world, because in the current situation, we don't really have an equilibrium of powers around the Blink project. Libwww was not driven by one company with a few participants. The work for standard organizations like W3C and IETF around Web technology would be dramatically be shifted from specifications to managing issues and pull requests. It would be another social dynamics.


[Source: Planet Mozilla]

Jeff Walden: mfbt now has UniquePtr and MakeUnique for managing singly-owned resources

Managing dynamic memory allocations in C++

C++ supports dynamic allocation of objects using new. For new objects to not leak, they must be deleted. This is quite difficult to do correctly in complex code. Smart pointers are the canonical solution. Mozilla has historically used nsAutoPtr, and C++98 provided std::auto_ptr, to manage singly-owned new objects. But nsAutoPtr and std::auto_ptr have a bug: they can be “copied.”

The following code allocates an int. When is that int destroyed? Does destroying ptr1 or ptr2 handle the task? What does ptr1 contain after ptr2‘s gone out of scope?

typedef auto_ptr<int> auto_int;
  auto_int ptr1(new int(17));
    auto_int ptr2 = ptr1;
    // destroy ptr2
  // destroy ptr1

Copying or assigning an auto_ptr implicitly moves the new object, mutating the input. When ptr2 = ptr1 happens, ptr1 is set to nullptr and ptr2 has a pointer to the allocated int. When ptr2 goes out of scope, it destroys the allocated int. ptr1 is nullptr when it goes out of scope, so destroying it does nothing.

Fixing auto_ptr

Implicit-move semantics are safe but very unclear. And because these operations mutate their input, they can’t take a const reference. For example, auto_ptr has an auto_ptr::auto_ptr(auto_ptr&) constructor but not an auto_ptr::auto_ptr(const auto_ptr&) copy constructor. This breaks algorithms requiring copyability.

We can solve these problems with a smart pointer that prohibits copying/assignment unless the input is a temporary value. (C++11 calls these rvalue references, but I’ll use “temporary value” for readability.) If the input’s a temporary value, we can move the resource out of it without disrupting anyone else’s view of it: as a temporary it’ll die before anyone could observe it. (The rvalue reference concept is incredibly subtle. Read that article series a dozen times, and maybe you’ll understand half of it. I’ve spent multiple full days digesting it and still won’t claim full understanding.)

Presenting mozilla::UniquePtr

I’ve implemented mozilla::UniquePtr in #include "mozilla/UniquePtr.h" to fit the bill. It’s based on C++11′s std::unique_ptr (not always available right now). UniquePtr provides auto_ptr‘s safety while providing movability but not copyability.

UniquePtr template parameters

Using UniquePtr requires the type being owned and what will ultimately be done to generically delete it. The type is the first template argument; the deleter is the (optional) second. The default deleter performs delete for non-array types and delete[] for array types. (This latter improves upon auto_ptr and nsAutoPtr [and the derivative nsAutoArrayPtr], which fail horribly when used with new[].)

UniquePtr<int> i1(new int(8));
UniquePtr<int[]> arr1(new int[17]());

Deleters are callable values, that are called whenever a UniquePtr‘s object should be destroyed. If a custom deleter is used, it’s a really good idea for it to be empty (per mozilla::IsEmpty<D>) so that UniquePtr<T, D> is as space-efficient as a raw pointer.

struct FreePolicy
  void operator()(void* ptr) {

  void* m = malloc(4096);
  UniquePtr<void, FreePolicy> mem(m);
  int* i = static_cast<int*>(malloc(sizeof(int)));
  UniquePtr<int, FreePolicy> integer(i);

  // integer.getDeleter()(i) is called
  // mem.getDeleter()(m) is called

Basic UniquePtr construction and assignment

As you’d expect, no-argument construction initializes to nullptr, a single pointer initializes to that pointer, and a pointer and a deleter initialize embedded pointer and deleter both.

UniquePtr<int> i1;
assert(i1 == nullptr);
UniquePtr<int> i2(new int(8));
assert(i2 != nullptr);
UniquePtr<int, FreePolicy> i3(nullptr, FreePolicy());

Move construction and assignment

All remaining constructors and assignment operators accept only nullptr or compatible, temporary UniquePtr values. These values have well-defined ownership, in marked contrast to raw pointers.

class B
    int i;

    B(int i) : i(i) 
    virtual ~B()  // virtual required so delete (B*)(pointer to D) calls ~D()

class D : public B
    D(int i) : B(i) 

UniquePtr<B> MakeB(int i)
  typedef UniquePtr<B>::DeleterType BDeleter;

  // OK to convert UniquePtr<D, BDeleter> to UniquePtr<B>:
  // Note: For UniquePtr interconversion, both pointer and deleter
  //       types must be compatible!  Thus BDeleter here.
  return UniquePtr<D, BDeleter>(new D(i));

UniquePtr<B> b1(MakeB(66)); // OK: temporary value moved into i1

UniquePtr<B> b2(b1); // ERROR: b1 not a temporary, would confuse
                     // single ownership, forbidden

UniquePtr<B> b3;

b3 = b1;  // ERROR: b1 not a temporary, would confuse
          // single ownership, forbidden

b3 = MakeB(76); // OK: return value moved into b3
b3 = nullptr;   // OK: can't confuse ownership of nullptr

What if you really do want to move a resource from one UniquePtr to another? You can explicitly request a move using mozilla::Move() from #include "mozilla/Move.h".

int* i = new int(37);
UniquePtr<int> i1(i);

UniquePtr<int> i2(Move(i1));
assert(i1 == nullptr);
assert(i2.get() == i);

i1 = Move(i2);
assert(i1.get() == i);
assert(i2 == nullptr);

Move transforms the type of its argument into a temporary value type. Move doesn’t have any effects of its own. Rather, it’s the job of users such as UniquePtr to ascribe special semantics to operations accepting temporary values. (If no special semantics are provided, temporary values match only const reference types as in C++98.)

Observing a UniquePtr‘s value

The dereferencing operators (-> and *) and conversion to bool behave as expected for any smart pointer. The raw pointer value can be accessed using get() if absolutely needed. (This should be uncommon, as the only pointer to the resource should live in the UniquePtr.) UniquePtr may also be compared against nullptr (but not against raw pointers).

int* i = new int(8);
UniquePtr<int> p(i);
if (p)
  *p = 42;
assert(p != nullptr);
assert(p.get() == i);
assert(*p == 42);

Changing a UniquePtr‘s value

Three mutation methods beyond assignment are available. A UniquePtr may be reset() to a raw pointer or to nullptr. The raw pointer may be extracted, and the UniquePtr cleared, using release(). Finally, UniquePtrs may be swapped.

int* i = new int(42);
int* i2;
UniquePtr<int> i3, i4;
  UniquePtr<int> integer(i);
  assert(i == integer.get());

  i2 = integer.release();
  assert(integer == nullptr);

  assert(integer.get() == i2);

  integer.reset(new int(93)); // deletes i2

  i3 = Move(integer); // better than release()

  Swap(i3, i4); // mozilla::Swap, that is

When a UniquePtr loses ownership of its resource, the embedded deleter will dispose of the managed pointer, in accord with the single-ownership concept. release() is the sole exception: it clears the UniquePtr and returns the raw pointer previously in it, without calling the deleter. This is a somewhat dangerous idiom. (Mozilla’s smart pointers typically call this forget(), and WebKit’s WTF calls this leak(). UniquePtr uses release() only for consistency with unique_ptr.) It’s generally much better to make the user take a UniquePtr, then transfer ownership using Move().

Array fillips

UniquePtr<T> and UniquePtr<T[]> share the same interface, with a few substantial differences. UniquePtr<T[]> defines an operator[] to permit indexing. As mentioned earlier, UniquePtr<T[]> by default will delete[] its resource, rather than delete it. As a corollary, UniquePtr<T[]> requires an exact type match when constructed or mutated using a pointer. (It’s an error to delete[] an array through a pointer to the wrong array element type, because delete[] has to know the element size to destruct each element. Not accepting other pointer types thus eliminates this class of errors.)

struct B ;
struct D : B ;
UniquePtr<B[]> bs;
// bs.reset(new D[17]()); // ERROR: requires B*, not D*
bs.reset(new B[5]());
bs[1] = B();

And a mozilla::MakeUnique helper function

Typing out new T every time a UniquePtr is created or initialized can get old. We’ve added a helper function, MakeUnique<T>, that combines new object (or array) creation with creation of a corresponding UniquePtr. The nice thing about MakeUnique is that it’s in some sense foolproof: if you only create new objects in UniquePtrs, you can’t leak or double-delete unless you leak the UniquePtr‘s owner, misuse a get(), or drop the result of release() on the floor. I recommend always using MakeUnique instead of new for single-ownership objects.

struct S { S(int i, double d)  };

UniquePtr<S> s1 = MakeUnique<S>(17, 42.0);   // new S(17, 42.0)
UniquePtr<int> i1 = MakeUnique<int>(42);     // new int(42)
UniquePtr<int[]> i2 = MakeUnique<int[]>(17); // new int[17]()

// Given familiarity with UniquePtr, these work particularly
// well with C++11 auto: just recognize MakeUnique means new,
// T means single object, and T[] means array.
auto s2 = MakeUnique<S>(17, 42.0); // new S(17, 42.0)
auto i3 = MakeUnique<int>(42);     // new int(42)
auto i4 = MakeUnique<int[]>(17);   // new int[17]()

MakeUnique<T>(...args) computes new T(...args). MakeUnique of an array takes an array length and constructs the correspondingly-sized array.

In the long run we probably should expect everyone to recognize the MakeUnique idiom so that we can use auto here and cut down on redundant typing. In the short run, feel free to do whichever you prefer.


UniquePtr was a free-time hacking project last Christmas week, that I mostly finished but ran out of steam on when work resumed. Only recently have I found time to finish it up and land it, yet we already have a couple hundred uses of it and MakeUnique. Please add more uses, and make our existing new code safer!

A final note: please use UniquePtr instead of mozilla::Scoped. UniquePtr is more standard, better-tested, and better-documented (particularly on the vast expanses of the web, where most unique_ptr documentation also suffices for UniquePtr). Scoped is now deprecated — don’t use it in new code!

[Source: Planet Mozilla]

Vladimir Vukićević: VR and CSS Integration in Firefox

It’s taken a little longer than expected, but he second Firefox build with VR support and preliminary CSS content rendering support is ready. It is extremely early, and the details of interactions with CSS have not yet been worked out. I’m hoping that experimentation from the community will lead to some interesting results that can help us define what the interaction should be.

These builds support both the Oculus Rift DK1 and DK2 (see DK2 instructions towards the end of the post). No support for other devices is available yet.

API changes since last build

The API for accessing the VR devices has changed, and is now using Promises. Additionally, the “moz” prefix was removed from all methods. Querying VR devices now should look like:

function vrDeviceCallback(devices) {


CSS content integration

This build includes experimental integration of CSS 3D transforms and VR fullscreen mode. It also allows for mixing WebGL content along with browser-rendered CSS content. Within a block element that is made full screen with a VR HMD device, any children that have the transform-style: preserve-3d CSS property will cause the browser to render the content twice from different viewpoints. Any elements that don’t have preserve-3d will cause those elements to be stretched across the full display of the output device. For example:

#container { }
#css-square {
  position: absolute;
  top: 0; left: 0;

  transform-style: preserve-3d;
  transform: translate(100px, 100px, 100px);
  width: 250px;
  height: 250px;
  background: blue;

<div id="container">
   <canvas id="webgl" width="1920" height="1080"></canvas>

   <div id="css-square">Hello World</div>

Will cause the css-square element to be rendered by the browser in the 3D space, but the WebGL canvas will be rendered only once, in this case underneath all content. No depth buffering is done between elements at this time.

The interaction between CSS transformed elements and the VR 3D space is poorly defined at the moment. CSS defines a coordinate space where 0,0 starts at the top left of the page, with Y increasing downwards, X increasing to the right, and Z increasing towards the viewer (i.e. out of the screen). For 3D content creation using CSS, “camera” and “modelview” elements could be used to provide transforms for getting a normal scene origin (based on the page’s dimensions) and camera position. It should also take care of applying orientation and position information from the HMD.

The browser itself will take care of applying the per-eye projection matrices and distortion shaders. Everything else is currently up to content. (I’ll go into detail exactly what’s done in a followup blog post.) So, a suggested structure could be:

<div id="container">
  <div id="camera">
    <div id="modelview">
      <div id="contentItem1">...</div>
      <div id="contentItem2">...</div>

One issue is that there currently is no way to specify the min and max depth of the scene. Normally, these would be specified as part of the projection, but that is inaccessible. For regular CSS 3D transforms, the perspective property provides some of this information, but it’s not appropriate for VR because the browser itself will define the projection transform. In this particular build, the depth will range from -(max(width,height) / 2) * 10 .. +(max(width,height) / 2) * 10. This is a complete hack, and will likely be replaced with an explicit CSS depth range property very soon. Alternatively, it might be replaced by an explicit setDepthRange call on the VR HMD device object (much like the FOV can be changed there).

I have not yet worked out the full best practices here. Some combination of transform-origin and transform will be needed to set up a useful coordinate space. A simple demo/test is available here.

As before, issues are welcome via GitHub issues on my gecko-dev repo. Additionally, discussion is welcome on the web-vr-discuss mailing list.

DK2 Support

These builds can support the DK2 when it is run in legacy/extended desktop mode. The following steps should enable rendering to the DK2, with orientation/position data:

  1. Install the DK2 runtime, and update the firmware as specified in the manual.
  2. Inside the OculusConfigTool, under Tools -> Rift Display Mode, switch to extended desktop mode
  3. The DK2 display will now appear as a normal display, in a tall-and-narrow configuration (1080 x 1920). You need to change this to normal 1920x1080 – On Windows, in the NVIDIA Control Panel, you can select the “Portrait” orientation under “Rotate display” for the DK2. This will rotate it so that it becomes 1920x1080. Similar steps should be possible on other video cards.
  4. At this point, you should be able to fire up the Firefox build and be able to get input from the DK2, as well as going fullscreen on the DK2.
  5. If you can’t, quit Firefox, and kill the “wscrip.exe” process that’s running an Oculus script, and “ovservice_x64.exe”. This seems to be a service that mediates access to the Rift, which is not compatible with the older SDK in use by the current Firefox build.
[Source: Planet Mozilla]

Kent James: Thunderbird’s Future: the TL;DR Version

In the next few months I hope to do a series of blog posts that talk about Mozilla’s Thunderbird email client and its future. Here’s the TL;DR version (though still pretty long). These are my personal views, I have no authority to speak for Mozilla or for the Thunderbird project.

Current Status

  • Thunderbird usage is growing, we have a strong core team, and expect to remain relevant to the internet for the foreseeable future. Thunderbird is mission critical to tens of millions of users.
  • The last two “community-developed” Thunderbird releases, 24 and 31, while successful as stability releases, had few new features. The enormous effort required to maintain that stability left little time for feature development.
  • Thunderbird is an important piece, under the Mozilla Manifesto, of maintaining an open internet. But it is not “The Web” and is outside of the current Mozilla Mission of “Our mission is to promote openness, innovation & opportunity on the Web.” Mozilla and the Thunderbird team need to better define the implications of that.
  • Mozilla’s strategic focus on a “Web” that excludes Thunderbird has indirectly resulted in dis-empowerment of the Thunderbird team in a variety of ways. This is becoming an existential threat to the product that needs addressing.

Where We Need to Go

  • Thunderbird should be a full-featured desktop personal information management system, incorporating messaging, calendar, and contacts. We need to incorporate the calendaring component (Lightning) by default, and drastically improve contact management.
  • We should be actively promoting open internet standards in messaging, calendaring, and contacts through product implementations as well as advocacy and standards development.
  • Our product should continually adapt to changing internet usage patterns and issues, including messaging security challenges and mobile interoperability.
  • We need to focus on the needs of our existing user base through increased reliability and performance, as well as adding long-requested features that are expected of a full-featured application.

How We Get There

  • Three full-time developers are needed to ensure a stable core base, and allow forward progress on the minimum feature set expected of us.
  • We cannot reasonably expect Firefox and MoCo to subsidize our operations, so we need to raise income independently, through donations directly from our users.
  • We are proudly Mozillians and expect to remain under the Mozilla umbrella, but the current governance structure, reporting through a Web-focused corporate management, is dis-empowering and needs conversion to a community-focused model that is focused on the needs of Thunderbird users.
  • We should ask MoFo to fund one person on the Thunderbird team to serve as an advocate for open messaging standards, contributing product code as well as participating publicly in standards development and discussions.

The Thunderbird team is currently planning to get together in Toronto in October 2014, and Mozilla staff are getting together in December 2014 for an all-hands. Let’s discussion the future in conjunction with those events, to make sure that in 2015 we have a sustainable plan for the future.


[Source: Planet Mozilla]

Bogomil Shopov: Optimize your GitHub Issues and 4 tricks and facts you should know about GitHub

I wrote an article, that can be found here about the new GitHub Issues, web development processes, using visual feedback and some facts about GitHub:['bigdata','github stats','xkcd comic ban','more''].

Actually I am using one old bug from project (a.k.a) Fjord. It’s a good 4 mins read full of useful stuff and fun.

If you are interested in the tool I am using to optimize your GitHub Issues processes, it is available for free for F(L)OSS projects from here, but you should read the article first.

Any thoughts?

[Source: Planet Mozilla]

Lucas Rocha: The new TwoWayView

What if writing custom view recycling layouts was a lot simpler? This question stuck in my mind since I started writing Android apps a few years ago.

The lack of proper extension hooks in the AbsListView API has been one of my biggest pain points on Android. The community has come up with different layout implementations that were largely based on AbsListView‘s code but none of them really solved the framework problem.

So a few months ago, I finally set to work on a new API for TwoWayView that would provide a framework for custom view recycling layouts. I had made some good progress but then Google announced RecyclerView at I/O and everything changed.

At first sight, RecyclerView seemed to be an exact overlap with the new TwoWayView API. After some digging though, it became clear that RecyclerView was a superset of what I was working on. So I decided to embrace RecyclerView and rebuild TwoWayView on top of it.

The new TwoWayView is functional enough now. Time to get some early feedback. This post covers the upcoming API and the general-purpose layout managers that will ship with it.

Creating your own layouts

RecyclerView itself doesn’t actually do much. It implements the fundamental state handling around child views, touch events and adapter changes, then delegates the actual behaviour to separate components—LayoutManager, ItemDecoration, ItemAnimator, etc. This means that you still have to write some non-trivial code to create your own layouts.

LayoutManager is a low-level API. It simply gives you extension points to handle scrolling and layout. For most layouts, the general structure of a LayoutManager implementation is going to be very similar—recycle views out of parent bounds, add new views as the user scrolls, layout scrap list items, etc.

Wouldn’t it be nice if you could implement LayoutManagers with a higher-level API that was more focused on the layout itself? Enter the new TwoWayView API.

TWAbsLayoutManagercode is a simple API on top of LayoutManager that does all the laborious work for you so that you can focus on how the child views are measured, placed, and detached from the RecyclerView.

To get a better idea of what the API looks like, have a look at these sample layouts: SimpleListLayout is a list layout and GridAndListLayout is a more complex example where the first N items are laid out as a grid and the remaining ones behave like a list. As you can see you only need to override a couple of simple methods to create your own layouts.

Built-in layouts

The new API is pretty nice but I also wanted to create a space for collaboration around general-purpose layout managers. So far, Google has only provided LinearLayoutManager. They might end up releasing a few more layouts later this year but, for now, that is all we got.


The new TwoWayView ships with a collection of four built-in layouts: List, Grid, Staggered Grid, and Spannable Grid.

These layouts support all RecyclerView features: item animations, decorations, scroll to position, smooth scroll to position, view state saving, etc. They can all be scrolled vertically and horizontally—this is the TwoWayView project after all ;-)

You probably know how the List and Grid layouts work. Staggered Grid arranges items with variable heights or widths into different columns or rows according to its orientation.

Spannable Grid is a grid layout with fixed-size cells that allows items to span multiple columns and rows. You can define the column and row spans as attributes in the child views as shown below.



The new TwoWayView API will ship with a convenience view (TWView) that can take a layoutManager XML attribute that points to a layout manager class.


This way you can leverage the resource system to set layout manager depending on device features and configuration via styles.

You can also use TWItemClickListener to use ListView-style item (long) click listeners. You can easily plug-in support for those in any RecyclerView (see sample).

I’m also planning to create pluggable item decorations for dividers, item spacing, list selectors, and more.

That’s all for now! The API is still in flux and will probably go through a few more iterations. The built-in layouts definitely need more testing.

You can help by filing (and fixing) bugs and giving feedback on the API. Maybe try using the built-in layouts in your apps and see what happens?

I hope TwoWayView becomes a productive collaboration space for RecyclerView extensions and layouts. Contributions are very welcome!

[Source: Planet Mozilla]

Daniel Stenberg: Me in numbers, today

Number of followers on twitter: 1,302

Number of commits during the last 365 days at github: 686

Number of publicly visible open source commits counted by openhub: 36,769

Number of questions I’ve answered on stackoverflow: 403

Number of connections on LinkedIn: 608

Number of days I’ve committed something in the curl project: 2,869

Number of commits by me, merged into Mozilla Firefox: 9

Number of blog posts on, including this: 734

Number of friends on Facebook: 150

Number of open source projects I’ve contributed to, openhub again: 35

Number of followers on Google+: 557

Number of tweets: 5,491

TOTAL life achievement: 49,613

[Source: Planet Mozilla]

Brian Warner: To Infinity And Beyond!

It’s been a great four and a half years at Mozilla, where I’ve had the privilege to work with the wonderful and brilliant people in Labs, Jetpack, Identity, and most recently Cloud Services. I’m grateful to you all.

Now it’s time for me to move on. This Friday will be my last day in the office (but certainly not as a Mozillian!), and this blog will probably be closed down or frozen at that time. You can reach me at, and my home blog lives at .

Mozilla is an amazing place, and will always be in my heart. Thank you all for everything!

[Source: Planet Mozilla]

Zbigniew Braniecki: Reducing MozL10n+Gaia technical debt in Firefox OS 2.1 cycle

Firefox OS is becoming a more mature platform, and one of the components that is maturing with it is the mozL10n library.

In 2.0 cycle, which is already feature complete, we introduced the codebase based on the L20n project.

The 2.1 cycle we’re currently in is a major API cleanup effort. We’re reviewing how Gaia apps use mozL10n, migrating them to the new API and minimizing the code complexity.

Simplifying the code responsible for localizability of Firefox OS is crucial for our ability to maintain and bring new features to the platform.

There are four major areas we’re working on:

  • mozL10n.translate – with introduction of Mutation Observer, we want to phase out manual DOM translation calls.
  • mozL10n.localize – this function is extremely hard to maintain and does enough “magic” to confuse devs.
  • mozL10n.get – manual l10n gets are the biggest cause of bugs and regressions in our code. They are synchronous, not retranslatable and badly misused
  • mock_l10n – many apps still use custom MockL10n class in tests, some even use real MozL10n code in tests. This makes testing harder to maintain and develop new l10n features.

We’re working on all four areas and would love to get your help.

No matter if you are a Gaia app owner, or if you’ve never wrote a patch for Gaia. If you know JavaScript, you can help us!

All of those bugs have instructions on how to start fixing, and I will be happy to mentor you.

We have time until October 13th. Let’s get Gaia ready for the next generation features we want to introduce soon! :)

[Source: Planet Mozilla]

Justin Crawford: Vouched Improvements on

Back in October I wrote a few blog posts describing a significant problem with the way we admit new members into the community platform. Yesterday the team fixed it!

Before yesterday, everyone with a “vouched” account in was empowered to vouch others. But we never explained what it meant to vouch someone: What it implied, what it granted. As a result, the standard for being vouched was arbitrary, the social significance of being vouched was diluted, and the privileges granted to vouched users were distributed more widely than they ought to be.

Yesterday the development team released a major refactor of the vouching system. For the first time we have a shared definition and understanding of vouching: A vouch signals participation and contribution in Mozilla’s community, and grants access to content and systems not available to the general public.

The new vouch system includes features that…

  • ask a “voucher” to explain to the community why they are vouching someone
  • grant the “vouching” privilege only to people who have themselves been vouched multiple times
  • remove “legacy vouches” from accounts that were vouched before we agreed what vouching meant and whose current contributor status can’t be easily verified

It is much clearer now who can access non-public information using (people who have been vouched because they participate and contribute to Mozilla) and how that list of people can grow (through individual judgments by people who have themselves been vouched numerous times).

When we know the composition of a network and understand how it will grow, we can make better decisions about sharing things with the network. We can confidently choose to share some things because we understand who we’re sharing with. And we can reasonably choose to withhold some things for the very same reason. Understanding a network simultaneously encourages more sharing and reduces inadvertent disclosure.

Thanks to the development team for making these excellent improvements!

[Source: Planet Mozilla]

Wesley Johnston: Better tiles in Fennec

We recently reworked Firefox for Android‘s homescreen to look a little prettier on first-run by shipping “tile” icons and colors for the default sites. In Firefox 33, we’re allowing sites to designate their own tiles images by supporting  msApplication-Tile and Colors in Fennec. So, for example, you might start seeing tiles that look like:

appear as you browse. Sites can add these with just a little markup in the page:

<meta name="msapplication-TileImage" content="images/myimage.png"/>
<meta name="msapplication-TileColor" content="#d83434"/>

As you can see above in the Boston Globe tile, sometimes we don’t have much to work with. Firefox for Android already supports the sizes attribute on favicon links, and our fabulous intern Chris Kitching improved things even more last year. In the absence of a tile, we’ll show a screenshot. If you’ve designated that Firefox shouldn’t cache the content of your site for security reasons, we’ll use the most appropriate size we can find and pull colors out of it for the background. But if sites can provide us with this information directly its 1.) must faster and 2.) gives much better results.

AFAIK, there is no standard spec for these types of meta tags, and none in the works either. Its a bit of the wild wild west right now. For instance, Apple supports apple-mobile-web-app-status-bar-style for designating the color of the status bar in certain situations, as well as a host of images for use in different situations.

Opera at one point supported using a minimized media query to designate a stylesheet for thumbnails (sadly they’ve removed all of those docs, so instead you just get a github link to an html file there). Gecko doesn’t have view-mode media query support currently, and not many sites have implemented it anyway, but it might in the future provide a standards based alternative. That said, there are enough useful reasons to know a “color” or a few different “logos” for an app or site, that it might be useful to come up with some standards based ways to list these things in pages.

[Source: Planet Mozilla]

James Long: Blog Rebuild: A Fresh Start

About two years ago I wanted to start blogging more seriously, focusing on in-depth tech articles and tutorials. Since then I've successfully made several posts like the one about games and another about react.js.

I decided to write my own blog from scratch to provide a better blogging experience, and it has served me well. I didn't want something big and complicated to maintain like Wordpress, and I had used static generators before but in my opinion you sacrifice a lot, and there's too much friction for writing and updating posts.

Back then I wanted to learn more about node.js, redis, and a few other things. So I wrote a basic redis-backed node.js blogging engine. In a few months (working here and there), I had a site with all the basic blog pages, a markdown editor with live preview, autosaving, unpublished drafts, tags, and some basic layout options. Here is the current ugly editor:

Redis is an in-memory data store, and node handles multiple connections well by default, so my simple site scales really well. I've have posts reach #1 on hacker news with ~750 visitors at the same time for hours (reaching about 60,000 views) with no problem at all. It may also help that my linode instance has 8 cores and I load up 4 instances of node to serve the site.

You may wonder why I don't just use something like ghost, a modern blogging platform already written in node. I tried ghost for a while but it's early software, includes complex features like multiple users which I don't need, and most importantly it was too difficult to implement my ideas. This is the kind of thing where I really want my site to be my code; it's my area to play, my grand experiment. For me, it's been working out really well (check out all of my posts).

But the cracks are showing. The code is JavaScript as I wrote it 2 years ago: ugly callbacks, poor modularity, no tests, random jQuery blobs to make the frontend work, and more. The site is stable and writing blog posts works, but implementing new features is pretty much out of the question. Since this is my site and I can do whatever I want, I'm going to commit the cardinal sin and rewrite it from scratch.

I've learned a ton over the past two years, and I'm really excited to try out some new techniques. I have a lot of the infrastructure set up already, which uses the following software:

  • react — for building user interfaces seamlessly between client/server
  • react-router — advanced route handling for react components
  • js-csp — CSP-style channels for async communication
  • mori — persistent data structures
  • gulp — node build system
  • webpack — front-end module bundler
  • sweet.js — macros
  • es6-macros — several ES6 features as macros
  • regenerator — compile generators to ES5

Check out the new version of the site at You can see my progress there (right now it's just a glimpse of the current site). I will put it up on github soon.

I thought it would also be interesting to blog throughout the development process. I'm using some really interesting libraries in ways that are very new, so I'm eager to dump my thoughts quite often. You can expect a post a week, explaining what I worked on and how I'm using a library in a certain way. It will touch on everything such as build systems and cross-compiling, testing, front-end structuring. Others might learn something new as well.

Next time, I'll talk about build systems and cross-compiling infrastructure. See you then!

[Source: Planet Mozilla]

Bogomil Shopov: Capture screenshots and annotate web sites in your Firefox

Usersnap’s visual communication addon was just approved by the addon team and now we have a “green button”. Hooray!

This is a “must have” addon for every web developer who wants to solve problems with web sites faster and who wants to earn more money by shortening the communication time with the client or inside the team.

Collect ideas and share them with your team

  • Capture and annotate every website.
  • Share and discuss it with your team.
  • Communicate visually and save time.

Annotate screenshots and integrate like a pro

  • Sticky notes, a pen, the pixel ruler and more help you express yourself visually.
  • Integrate Usersnap in your existing workflow and connect it to one of our supported third party tools.

Capture screens in all environments

  • Works on every site, including localhost.
  • Works behind firewalls.
  • Works on your password-protected staging and QA servers.

Every developer will get access and  to the  Usersnap Dashboard where he/she can:

  • Discuss mockups and sketches. Annotate them and push them back to a bug tracking system
  • See advanced client-side JavaScript errors and XHR Logs and browse them.
  • Access extended Information about the user’s session: OS, browser version, screen and browser size and installed plugins


Click here to install it (no restart needed)

[Source: Planet Mozilla]

More News

Sponsored by: