This adds support for separators to the bookmarks API. Separators can now be created
and will be returned by any method that returns BookmarkTreeNodes. They will also be
included in data for the onCreated and onRemoved events.
BookmarkTreeNodes will now contain a `type` property which will be one of bookmark,
folder or separator. When creating a bookmark object, one can specify the type, or one
can rely on the Chrome-compatible behaviour which treats any bookmarks without a URL
as a folder. To create a separator one must specify a type as part of the CreateDetails
object.
MozReview-Commit-ID: BoyGgx8lMAZ
--HG--
extra : rebase_source : 95a06fe81d21d660aeecbd86b71ca6bbcd66eb10
Also declare all top-level functions in those files via const.
MozReview-Commit-ID: FsIEHVeotX8
--HG--
extra : rebase_source : 8257fac9824fddb78bf79c6d45eb16f6c0797603
BookmarkTreeNodes without children do not contain a children property, but they should actually
contain a children property which is an empty array. This is what Chrome does as well.
This patch fixes that, and includes a test for a case of getChildren that was previously
untested, which I noticed when working on this code.
MozReview-Commit-ID: CjUwExma760
--HG--
extra : rebase_source : b3297eaf444ec987baeb97c8f0c7547450eb256d
This patch adds the ability to run SingletonEventManager handlers in
different modes: sync, async, raw (no exception handling, arg cloning,
or asynchrony), or asyncWithoutClone. When you call the handler,
you're required to specify which variant you want.
Existing uses of SingletonEventManager are all converted to async calls.
Note that some of them were previously synchronous, but it didn't appear
to be necessary.
Also added a callOnClose for SingletonEventManager when the last listener
is removed.
MozReview-Commit-ID: ATHO97dWf3X
--HG--
extra : rebase_source : bf02d79e3fbab84892be8a7e52ea7a1caf2e003d
CLOSED TREE
Backed out changeset 2d42350d209a (bug 1203330)
Backed out changeset 3a12c51c3eca (bug 1203330)
Backed out changeset 31fac390e15d (bug 1203330)
This patch adds the ability to run SingletonEventManager handlers in
different modes: sync, async, raw (no exception handling, arg cloning,
or asynchrony), or asyncWithoutClone. When you call the handler,
you're required to specify which variant you want.
Existing uses of SingletonEventManager are all converted to async calls.
Note that some of them were previously synchronous, but it didn't appear
to be necessary.
Also added a callOnClose for SingletonEventManager when the last listener
is removed.
MozReview-Commit-ID: ATHO97dWf3X
--HG--
extra : rebase_source : 43988ee453e965e1c591b1c64603c22f5a103cff
- Add `envType` to BaseContext.
- Pass an explicit envType to all `registerSchemaAPI` invocations.
- The factories passed to `registerSchemaAPI` will be split up later, so
that content scripts (`content_child`) and addon pages can share
common implementations.
- The factories that implement the addon API will also be split up,
to separate code running in the main process (`addon_parent`) from
code running in a child process (`addon_child`).
- Remove the use of a hardcoded list of `namespaces` from ProxyContext.
Now `envType` is used to specify whether an API should be activated.
MozReview-Commit-ID: Jiff8HIwG92
--HG--
extra : rebase_source : 946a3c0009a4e3223c2d10044b3099a94c845394
ExtensionContext in Extension.jsm has |extension| as an instance member,
so use it instead of passing |extension| to registerSchemaAPI's
callback.
And to make sure that this pattern also works in content processes, move
the |extension| member to BaseContext.
MozReview-Commit-ID: BgsGGCPQxJR
--HG--
extra : rebase_source : 7aa9fb7a53e057e8d3d8c477bd6821f8344c571a
ExtensionContext in Extension.jsm has |extension| as an instance member,
so use it instead of passing |extension| to registerSchemaAPI's
callback.
And to make sure that this pattern also works in content processes, move
the |extension| member to BaseContext.
MozReview-Commit-ID: BgsGGCPQxJR
--HG--
extra : rebase_source : 9a85d95f0c147198938b86c57127f6e7403fd53c
Add coverage for getChildren() when the promise is rejected
Add coverage for create() specifying index
Add coverage for update() specifying a URL
Add coverage for update() when the promise is rejected
MozReview-Commit-ID: 7ANRDWRublL
--HG--
extra : transplant_source : %C0vL%13%B2%BFo%07%0B%0B%CB%BD%BD4%15QA%FCY%7C
Update Bookmarks.update to not require a parentGuid when updating just the index.
MozReview-Commit-ID: JJO2IDyI5oN
--HG--
extra : rebase_source : 390d6c80f034f01cc419b1c2c3c9a93722fa1c59
The base .eslintrc is essentially a merge of the root Toolkit .eslintrc and
the devtools .eslintrc, with some minor changes to match our prevalent style.
For the most enforces the coding styles that we've been using most
consistently. There are a couple of significant differences, though:
* The rule for opening brace alignment can only be applied globally, and
doesn't make exceptions for top-level functions. I chose to turn it on, and
change the brace style of existing top-level functions that violated it,
since the rule seemed worth using, and that's the direction most Toolkit JS
code has been headed anyway.
* The rule for switch/case statements requires an added indentation level for
case statements. Most of our switch statements did not use an extra level
of indentation, and I initially wrote the rule to enforce that style, until
I came across case statements that used blocks, and required the extra
indentation level for sanity.
--HG--
rename : devtools/.eslintrc => toolkit/components/extensions/.eslintrc
extra : commitid : 4aDZOi5MNPc
extra : rebase_source : f34ba43aeb8046a0c971cb76b76410497bd12b42
extra : source : 2a7eb4ef7b375e5fd52d843ca206a071367a6475
