Merge pull request #569 from Gozala/bug/layout-change@787346

fix Bug 787346 - Implement layout changes r=@ochameau

.gitignore

@@ -8,9 +8,6 @@ doc/index.html
doc/packages/
doc/status.md5
packages/*
!packages/addon-kit/
!packages/api-utils/
!packages/test-harness/

# Python
*.pyc

doc/dev-guide-source/cfx-tool.md

@@ -298,7 +298,7 @@ they contain.

See the
[tutorial on unit testing](dev-guide/tutorials/unit-testing.html) and the
[reference documentation for the `assert` module](packages/api-utils/test/assert.html)
[reference documentation for the `assert` module](modules/sdk/test/assert.html)
for details.

#### Supported Options #####
@@ -806,7 +806,7 @@ one run of `cfx` will not, by default, be available in the next run.

This includes, for example, any extra add-ons you installed, or your
history, or any data stored using the
[simple-storage](packages/addon-kit/simple-storage.html) API.
[simple-storage](modules/sdk/simple-storage.html) API.

To make `cfx` use a specific profile, pass the `--profiledir` option,
specifying the path to the profile you wish to use.

doc/dev-guide-source/guides/commonjs.md

@@ -109,27 +109,27 @@ Modules in the `api-utils` package implement low-level APIs. These
modules fall roughly into three categories:

* fundamental utilities such as
[collection](packages/api-utils/collection.html) and
[url](packages/api-utils/url.html). Many add-ons are likely to
[collection](modules/sdk/platform/xpcom.html) and
[url](modules/sdk/url.html). Many add-ons are likely to
want to use modules from this category.

* building blocks for higher level modules, such as
[event/core](packages/api-utils/event/core.html),
[event/target](packages/api-utils/event/target.html),
[heritage](packages/api-utils/heritage.html), and
[namespace](packages/api-utils/namespace.html). You're more
[event/core](modules/sdk/event/core.html),
[event/target](modules/sdk/event/target.html),
[heritage](modules/sdk/core/heritage.html), and
[namespace](modules/sdk/core/namespace.html). You're more
likely to use these if you are building your own modules that
implement new APIs, thus extending the SDK itself.

* privileged modules that expose powerful low-level capabilities
such as [xhr](packages/api-utils/xhr.html) and
[xpcom](packages/api-utils/xpcom.html). You can use these
such as [xhr](modules/sdk/net/xhr.html) and
[xpcom](modules/sdk/platform/xpcom.html). You can use these
modules in your add-on if you need to, but should be aware that
the cost of privileged access is the need to take more elaborate
security precautions. In many cases these modules have simpler,
more restricted analogs in the high-level addon-kit package (for
example, [tabs](packages/addon-kit/tabs.html) or
[request](packages/addon-kit/request.html)).
example, [tabs](modules/sdk/tabs.html) or
[request](modules/sdk/request.html)).

<div class="warning">
<p>These modules are still in active development,

doc/dev-guide-source/guides/content-scripts/communicating-with-other-scripts.md

@@ -72,7 +72,7 @@ Suppose we have a page called "listen.html" hosted at "my-domain.org", and we wa
from the add-on to a script embedded in that page.

In the main add-on code, we have a
[`page-mod`](packages/addon-kit/page-mod.html) that attaches the content script
[`page-mod`](modules/sdk/page-mod.html) that attaches the content script
"talk.js" to the right page:

    var data = require("self").data;
@@ -114,7 +114,7 @@ messages from the content script:
Sending messages from the page script to the content script is just
the same, but in reverse.

Here "main.js" creates a [`page-mod`](packages/addon-kit/page-mod.html)
Here "main.js" creates a [`page-mod`](modules/sdk/page-mod.html)
that attaches "listen.js" to the web page:

    var data = require("self").data;
@@ -164,7 +164,7 @@ to communicate between page scripts and content scripts.
Here's an example showing how to use custom DOM events to send a message
from a content script to a page script.

First, "main.js" will create a [`page-mod`](packages/addon-kit/page-mod.html)
First, "main.js" will create a [`page-mod`](modules/sdk/page-mod.html)
that will attach "talk.js" to the target web page:

    var data = require("self").data;
@@ -206,7 +206,7 @@ Finally "listen.html" listens for the new event and examines its
Sending messages using custom DOM events from the page script
to the content script is just the same, but in reverse.

Again, "main.js" creates a [`page-mod`](packages/addon-kit/page-mod.html)
Again, "main.js" creates a [`page-mod`](modules/sdk/page-mod.html)
to target the page we are interested in:

    var data = require("self").data;

doc/dev-guide-source/guides/content-scripts/index.md

@@ -10,19 +10,19 @@ content of web pages or be notified when the user clicks a link.

The SDK provides several core modules to support this:

**[panel](packages/addon-kit/panel.html)**<br>
**[panel](modules/sdk/panel.html)**<br>
Create a dialog that can host web content.

**[page-worker](packages/addon-kit/page-worker.html)**<br>
**[page-worker](modules/sdk/page-worker.html)**<br>
Retrieve a page and access its content, without displaying it to the user.

**[page-mod](packages/addon-kit/page-mod.html)**<br>
**[page-mod](modules/sdk/page-mod.html)**<br>
Execute scripts in the context of selected web pages.

**[widget](packages/addon-kit/widget.html)**<br>
**[widget](modules/sdk/widget.html)**<br>
Host an add-on's user interface, including web content.

**[context-menu](packages/addon-kit/context-menu.html)**<br>
**[context-menu](modules/sdk/context-menu.html)**<br>
Add items to the browser's context menu.

Firefox is moving towards a model in which it uses separate
@@ -57,7 +57,7 @@ relationships. The gray fill represents code written by the add-on developer.
alt="Content script events">

This might sound complicated but it doesn't need to be. The following add-on
uses the [page-mod](packages/addon-kit/page-mod.html) module to replace the
uses the [page-mod](modules/sdk/page-mod.html) module to replace the
content of any web page in the `.co.uk` domain by executing a content script
in the context of that page:

doc/dev-guide-source/guides/content-scripts/reddit-example.md

@@ -42,7 +42,7 @@ link clicks.

Finally, it registers a listener to the user-defined `click` event which in
turn passes the URL into the `open` function of the
[tabs](packages/addon-kit/tabs.html) module.
[tabs](modules/sdk/tabs.html) module.

This is the `panel.js` content script that intercepts link clicks:

doc/dev-guide-source/guides/content-scripts/using-port.md

@@ -51,7 +51,7 @@ the recipient but just emits the event and continues processing.
## Accessing `port` in the Content Script ##

<span class="aside">Note that the global `self` object is completely
different from the [`self` module](packages/addon-kit/self.html), which
different from the [`self` module](modules/sdk/self.html), which
provides an API for an add-on to access its data files and ID.</span>

In the content script the `port` object is available as a property of the
@@ -67,7 +67,7 @@ To receive an event from the add-on code:

Compare this to the technique used to receive _built-in_ events in the
content script. For example, to receive the `context` event in a content script
associated with a [context menu](packages/addon-kit/context-menu.html)
associated with a [context menu](modules/sdk/context-menu.html)
object, you would call the `on` function attached to the global `self` object:

    self.on("context", function() {

doc/dev-guide-source/guides/events.md

@@ -5,7 +5,7 @@
# Working with Events #

The Add-on SDK supports event-driven programming through its
[`EventEmitter`](packages/api-utils/events.html) framework.
[`EventEmitter`](modules/sdk/deprecated/events.html) framework.

Objects emit events on state changes that might be of interest to add-on code,
such as browser windows opening, pages loading, network requests completing,
@@ -52,7 +52,7 @@ whenever the event occurs. The arguments that will be passed to the listener
are specific to an event type and are documented with the event emitter.

For example, the following add-on registers two listeners with the
[`private-browsing`](packages/addon-kit/private-browsing.html) module to
[`private-browsing`](modules/sdk/private-browsing.html) module to
listen for the `start` and `stop` events, and logs a string to the console
reporting the change:

@@ -83,7 +83,7 @@ with "on": for example, "onOpen", "onReady" and so on. Then in the constructor
you can assign a listener function to this property as an alternative to
calling the object's `on()` method.

For example: the [`widget`](packages/addon-kit/widget.html) object emits
For example: the [`widget`](modules/sdk/widget.html) object emits
an event when the widget is clicked.

The following add-on creates a widget and assigns a listener to the

doc/dev-guide-source/guides/firefox-compatibility.md

@@ -5,7 +5,7 @@
# Firefox Compatibility #

One of the promises the SDK makes is to maintain compatibility for its
["supported" or "high-level" APIs](packages/addon-kit/index.html):
["supported" or "high-level" APIs]FIXME:
meaning that code written against them will not need to change as new
versions of Firefox are released.

doc/dev-guide-source/guides/library-detector.md

@@ -72,7 +72,7 @@ access to the un-proxied DOM window, so they can see the objects added by
libraries, so we’ll need to use the experimental [unsafeWindow](dev-guide/guides/content-scripts/accessing-the-dom.html#unsafeWindow)

The main add-on script, `main.js`, will use a
[`page-mod`](packages/addon-kit/page-mod.html)
[`page-mod`](modules/sdk/page-mod.html)
to inject the content script into every new page.

The content script, which we'll call `library-detector.js`, will keep most of
@@ -101,7 +101,7 @@ the array of library names, and post it back to `main.js`:

`main.js` responds to that message by fetching the tab
corresponding to that worker using
[`worker.tab`](packages/api-utils/content/worker.html#tab), and adding
[`worker.tab`](modules/sdk/content/worker.html#tab), and adding
the array of library names to that tab's `libraries` property:

    pageMod.PageMod({
@@ -134,11 +134,11 @@ a page contains more than one iframe, and those iframes use the same library.

#### Showing the Library Array ####

The [`widget`](packages/addon-kit/widget.html) module is a natural fit
The [`widget`](modules/sdk/widget.html) module is a natural fit
for displaying the library list. We'll specify its content using HTML, so we
can display an array of icons. The widget must be able to display different
content for different windows, so we'll use the
[`WidgetView`](packages/addon-kit/widget.html) object.
[`WidgetView`](modules/sdk/widget.html) object.

`main.js` will create an array of icons corresponding to the array of library
names, and use that to build the widget's HTML content dynamically:
@@ -163,7 +163,7 @@ names, and use that to build the widget's HTML content dynamically:
    }

`main.js` will
use the [`tabs`](packages/addon-kit/tabs.html) module to update the
use the [`tabs`](modules/sdk/tabs.html) module to update the
widget's content when necessary (for example, when the user switches between
tabs):

doc/dev-guide-source/guides/module-search.md

@@ -21,7 +21,7 @@ The module-search logic needs to provide features like:
* support for "packages": groups of related modules that are bundled together
  for easy distribution
* easy and concise use of "stdlib" modules like `panel` and `page-mod` in
  `packages/addon-kit/lib`, perhaps searching multiple packages for a module
  `FIXMElib`, perhaps searching multiple packages for a module
  with the right name
* "absolute" imports: minimize searching (and ambiguity) by specifying
  exactly which package contains the module of interest

doc/dev-guide-source/guides/program-id.md

@@ -11,7 +11,7 @@ add-on for distribution using `cfx xpi`, it will become the
The ID is used for a variety
of purposes. For example: [addons.mozilla.org](http://addons.mozilla.org) uses
it to distinguish between new add-ons and updates to existing add-ons, and the
[`simple-storage`](packages/addon-kit/simple-storage.html) module uses it
[`simple-storage`](modules/sdk/simple-storage.html) module uses it
to figure out which stored data belongs to which add-on.

It is read from the `id` key in your add-on's [`package.json`](dev-guide/package-spec.html) file.

doc/dev-guide-source/guides/xul-migration.md

@@ -81,7 +81,7 @@ registers a listener function for messages from the content script
* the content script (3) extracts the data from the page and (4) sends
it to the main add-on code in a message
* the main add-on code (5) receives the message and (6) sends the request,
using the SDK's [`request`](packages/addon-kit/request.html) API
using the SDK's [`request`](modules/sdk/request.html) API

<img class="image-center" src="static-files/media/xul-migration-cs.png"
alt="Content script organization">
@@ -101,7 +101,7 @@ There's much more information on content scripts in the
The SDK provides a set of high level APIs providing some basic user
interface components and functionality commonly required by add-ons.
These are collected together in the
[`addon-kit`](packages/addon-kit/index.html)
[`addon-kit`]FIXME
package. Because we expect to keep these APIs compatible as new versions
of Firefox are released, we call them the "supported" APIs.

@@ -111,8 +111,8 @@ If the supported APIs do what you need, they're the best option: you get the
benefits of compatibility across Firefox releases and of the SDK's security
model.

APIs like [`widget`](packages/addon-kit/widget.html) and
[`panel`](packages/addon-kit/panel.html) are very generic and with the
APIs like [`widget`](modules/sdk/widget.html) and
[`panel`](modules/sdk/panel.html) are very generic and with the
right content can be used to replace many specific XUL elements. But there are
some notable limitations in the SDK APIs and even a fairly simple UI may need
some degree of redesign to work with them.
@@ -166,8 +166,8 @@ continue to work as new versions of Firefox are released.

In addition to the High-Level APIs, the SDK includes a number of
Low-Level APIs some of which, such
as [`tab-browser`](packages/api-utils/tab-browser.html), [`xhr`](packages/api-utils/xhr.html), and
[`window-utils`](packages/api-utils/window-utils.html), expose powerful
as [`tab-browser`](modules/sdk/deprecated/tab-browser.html), [`xhr`](modules/sdk/net/xhr.html), and
[`window-utils`](modules/sdk/deprecated/window-utils.html), expose powerful
browser capabilities.

In this section we'll use low-level modules how to:
@@ -178,7 +178,7 @@ object

### <a name="browser-chrome">Modifying the Browser Chrome</a> ###

The [`window-utils`](packages/api-utils/window-utils.html) module gives
The [`window-utils`](modules/sdk/deprecated/window-utils.html) module gives
you direct access to chrome windows, including the browser's chrome window.
Here's a really simple example add-on that modifies the browser chrome using
`window-utils`:
@@ -206,7 +206,7 @@ collection of [third party modules](https://wiki.mozilla.org/Jetpack/Modules).
### <a name="accessing-tabbrowser">Accessing <a href="https://developer.mozilla.org/en/XUL/tabbrowser">tabbrowser</a> ###


The [`tab-browser`](packages/api-utils/tab-browser.html) module gives
The [`tab-browser`](modules/sdk/deprecated/tab-browser.html) module gives
you direct access to the
[tabbrowser](https://developer.mozilla.org/en/XUL/tabbrowser) object. This
simple example modifies the selected tab's CSS to enable the user to highlight
@@ -241,9 +241,9 @@ APIs it explicitly imports via `require()`. This is useful, because it means
that if a malicious web page is able to inject code into your add-on's
context, it is only able to use the APIs you have imported. For example, if
you have only imported the
[`notifications`](packages/addon-kit/notifications.html) module, then
[`notifications`](modules/sdk/notifications.html) module, then
even if a malicious web page manages to inject code into your add-on, it
can't use the SDK's [`file`](packages/api-utils/file.html) module to
can't use the SDK's [`file`](modules/sdk/io/file.html) module to
access the user's data.

But this means that the more powerful modules you `require()`, the greater

doc/dev-guide-source/index.md

@@ -131,9 +131,9 @@ Learn about common development techniques, such as
    <td>
      <h4>API reference</h4>
      Reference documentation for the high-level SDK APIs found in the
      <a href="packages/addon-kit/index.html">addon-kit</a>
      FIXME
      package, and the low-level APIs found in the
      <a href="packages/api-utils/index.html">api-utils</a> package.
      FIXME.
    </td>

    <td>

doc/dev-guide-source/low-level-apis.md

@@ -8,27 +8,27 @@ Modules in this section implement low-level APIs. These
modules fall roughly into three categories:

* fundamental utilities such as
[collection](packages/api-utils/collection.html) and
[url](packages/api-utils/url.html). Many add-ons are likely to
[collection](modules/sdk/platform/xpcom.html) and
[url](modules/sdk/url.html). Many add-ons are likely to
want to use modules from this category.

* building blocks for higher level modules, such as
[events](packages/api-utils/events.html),
[worker](packages/api-utils/content/worker.html), and
[api-utils](packages/api-utils/api-utils.html). You're more
[events](modules/sdk/deprecated/events.html),
[worker](modules/sdk/content/worker.html), and
[api-utils](modules/sdk/deprecated/api-utils.html). You're more
likely to use these if you are building your own modules that
implement new APIs, thus extending the SDK itself.

* privileged modules that expose powerful low-level capabilities
such as [tab-browser](packages/api-utils/tab-browser.html),
[xhr](packages/api-utils/xhr.html), and
[xpcom](packages/api-utils/xpcom.html). You can use these
such as [tab-browser](modules/sdk/deprecated/tab-browser.html),
[xhr](modules/sdk/net/xhr.html), and
[xpcom](modules/sdk/platform/xpcom.html). You can use these
modules in your add-on if you need to, but should be aware that
the cost of privileged access is the need to take more elaborate
security precautions. In many cases these modules have simpler,
more restricted analogs among the "High-Level APIs" (for
example, [tabs](packages/addon-kit/tabs.html) or
[request](packages/addon-kit/request.html)).
example, [tabs](modules/sdk/tabs.html) or
[request](modules/sdk/request.html)).

These modules are still in active development, and we expect to
make incompatible changes to them in future releases.
make incompatible changes to them in future releases.

doc/dev-guide-source/package-spec.md

@@ -56,7 +56,7 @@ called `package.json`. This file is also referred to as the
  An array of JSON objects that use the following keys `name`, `type`, `value`,
  `title`, and `description`.  These JSON objects will be used to automatically
  create a preferences interface for the addon in the Add-ons Manager.
  For more information see the documentation of [simple-prefs](packages/addon-kit/simple-prefs.html).
  For more information see the documentation of [simple-prefs](modules/sdk/simple-prefs.html).

* `license` - the name of the license as a String, with an optional
  URL in parentheses.
@@ -113,7 +113,7 @@ API documentation.
Packages may optionally contain a directory called `data` into which
arbitrary files may be placed, such as images or text files. The
URL for these resources may be reached using the
[self](packages/addon-kit/self.html) module.
[self](modules/sdk/self.html) module.

  [Markdown]: http://daringfireball.net/projects/markdown/
  [non-bootstrapped XUL extension]: #guide/xul-extensions