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