This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
This patch introduces a new cookie behavior policy called
BEHAVIOR_REJECT_TRACKER. It also makes it possible to override that
behavior with cookie permissions similar to other cookie behaviors.
- Add info.targetElementId to menus.onShown event.
- Add info.targetElementId to menus.onClicked event.
- Add menus.getTargetElement API that is available to all contexts,
including content scripts, which allows extensions to get the DOM
element for a given targetElementId.
- Add new schema instead of re-using schemas/menus.json to avoid sending
too much schema data (of the existing menus API) to content processes.
MozReview-Commit-ID: 6Onf7jZlIho
--HG--
extra : rebase_source : eb095d04ce381606be90d325712bfc57233d8291
This schema was inherited from Chromium (where it was an internal
implementation detail. This schema only defined the OnClickData
type, but was never actively used by our WebExtensions framework,
because menus.json already defines the OnClickData type.
Note: menus_internal.json specified the "menusInternal" namespace
which we do indeed implement in parent/ext-menus.js (and use in
child/ext-menus.js). However, none of the methods that we add to
menusInternal are actually defined in the schema.
This use of menusInternal was introduced in part 2 of bug 1333403 and
works without problems because the API schemas are not being used to
validate APIs as of part 2 of bug 1315575.
The only significance of "menusInternal" is that the namespace is
defined in browser/components/extensions/ext-browser.json,
implemented in browser/components/extensions/parent/ext-menus.js
and used by browser/components/extensions/child/ext-menus.js
MozReview-Commit-ID: 2ACpn595QZQ
--HG--
extra : rebase_source : f3e16486168dfb0baa56dda7ccf591855bbe90bb
At its inception, ExtensionChild.jsm was meant to be used for the
extension child process. Over time, this intent was not consistently
followed, and in bug 1317697 this was fixed by splitting some logic
in ExtensionChild.jsm off to ExtensionPageChild.jsm.
Henceforth ExtensionChild.jsm handles logic that is common to all
content processes, including web content and extension logic.
Updated the comment at the top of the file to match this reality.
MozReview-Commit-ID: 3cAd0FPj6Vz
--HG--
extra : rebase_source : 21bfd642460dd72159af120a9f81cbc7ae0b0572
