When building gtest libxul with LTO, the fact that
StaticXULComponentStart is not passed first to the linker makes the
linker pull the NSModule symbols out of all the other objects first,
presumably because linking the gtest objects (which appear first) pulls
code from the other non StaticXULComponent* objects first.
So, to make things link properly with LTO, we trick the build system
to always put StaticXULComponentStart first.
--HG--
extra : rebase_source : 7ddda118903f5845f6b6d12db2bf39cd22d67ab5
Result of running the update script and updating gecko's
integration crate for the layout change.
MozReview-Commit-ID: GaIMFKmPmtf
--HG--
extra : rebase_source : 0d3a2f1d211840879e562cb56afcc9ef7e38c730
This patch introduces helper for the embedding of a webextension (and new related tests).
The new exported helpers are going to be integrated in the XPIProvider
to provide the Embedded WebExtension to the Legacy Extensions which
have enabled it in their install.rdf
MozReview-Commit-ID: 7M1DRkXjGat
--HG--
extra : rebase_source : 3226a83652b97601d9d4d34693761cfc720735a0
- this new module contains helpers to be able to receive connections
originated from a webextension context from a legacy extension context
(implemented by the `LegacyExtensionContext` class exported from
this new jsm module)
- two new test files (an xpcshell-test and a mochitest-browser) ensures that the LegacyExtensionContext can receive a Port
object and exchange messages with a background page and a content script (the content script test
is in a different test file because it doesn't currently work on android, because it needs
the browser.tabs API and the TabManager internal helper)
MozReview-Commit-ID: DS1NTXk0fB6
--HG--
extra : rebase_source : 462d6a461167e317297d204e72c2f6773bc5c770
This mirrors the location of Servo_Init. This is important because xpcshell runs
don't use nsAppRunner, and so we end up with an unpaired call to Servo_Shutdown,
which crashes.
Don't reject a temporary install if AddonManager.checkCompatibility is false.
Don't try to add missing info from addon to error message.
Fix up test_webextension_install.js to use equal and notEqual and pass assertion messages.
MozReview-Commit-ID: 46kxpXdWQtx
--HG--
extra : rebase_source : 2dae6f82dcaf489d2bd3eef62e0f460e008e1b88
They are non-standard aliases for "DragEvent" and "KeyboardEvent" that
are not supported by any other UA, and we would like to drop support.
So first let's stop using them ourselves, so we can use telemetry to see
if any sites are using them.
MozReview-Commit-ID: ICC33ORa2st
The reason this works is because the window object stays the same between location
changes, but the document object changes.
Since stylesheets are applied to documents, not windows, we need to make sure to
inject a stylesheet for each document, otherwise the find toolbar highlights will
look unstyled and wonky.
In bug 1279695 I made a change - to make tests pass and patch landable - to keep
track of all the things (state, mainly range sets) mapped to window objects, because
I hadn't thought of the fact that the content scripts and JSMs that are loaded in
its scope will see many different window objects. As many as there are tabs open,
actually (not counting frames).
The mistake I made there was to keep track of the state flag 'did I already install
the stylesheet?' on a per-window basis, unlike I did before. This patch corrects
this back to the way it was and should be, really.
MozReview-Commit-ID: 2t0mer2s10x
--HG--
extra : rebase_source : 6e793b695a4a86874898ca470639b60d5a91a001
Throw some process selectors in the Histograms and Keyed Histograms sections
to allow users to choose which process type's histograms they'd like to see.
Rewrite the categorical histogram accumulation code to use the common path.
This way it gets remote accumulation for cheap.
MozReview-Commit-ID: 3q6gdSvBix
I saw a one-off crash on try in internal_GetHistogramByEnumId. Not reproducible
but maybe possible if we're trying to accumulate using an invalid ID. So let's
guard against that.
MozReview-Commit-ID: Ei6eTlV91mJ
On content process shutdown we send a content process ping to ensure we have
up-to-date data from the content process before it goes away. Now we need to
also flush the batched telemetry accumulations to the parent so that it can be
present in the ping.
No attempt is made to synchronize access to IPCTimerFired. It is safe to
re-enter.
No attempt is made to cancel the timer as its firing is benign.
MozReview-Commit-ID: 1gjNH9IPhKf
Clear isn't generally called at all, and isn't dispatched to the parent process
for child telemetry aggregation. Clear should only be called on the parent
process.
MozReview-Commit-ID: stIutvAO6h
The JS histograms, too, need to dispatch their accumulations from child to
parent.
JSHistograms_Add now only supports histograms that are in gHistogramsMap or
that were created in the parent process. After bug 1288745, maybe we'll be able
to change this to be less convoluted.
MozReview-Commit-ID: 3qTH89YKbGP
Take the opportunity presented through changing child telemetry accumulation
to bring the ping form closer to the ideas expressed in bug 1281795.
childPayloads still exists, but without histograms or keyedHistograms which are
now at root.processes.content.{keyedH|h}istograms. This will require coordinated
changes in the aggregator and moztelemetry libraries.
MozReview-Commit-ID: AqG2jmBBC2W
To simplify using child telemetry from the parent process, only allow child
telemetry payloads to be generated once per child process, on shut down.
This will allow us to use the child telemetry's subsession information to leave
childPayloads the way it currently is.
Will need to update test_ChildHistograms.js as it is the only consumer.
MozReview-Commit-ID: 2qSztg0QHV5
I originally thought we'd be able to avoid the previous implementation's waste
of a map full of every kind of keyed histogram. Unfortunately, other code
(TelemetrySession at the very least) depends on this (and will throw if a keyed
histogram isn't present, even if it is empty)
MozReview-Commit-ID: 8MCGVa595UB
The original commit didn't properly support subsession histograms, so rectify
that lapse by adding support for stripping out the base name of a histogram
when trying to determine its id.
MozReview-Commit-ID: LvUek6f5WUx
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
Throw some process selectors in the Histograms and Keyed Histograms sections
to allow users to choose which process type's histograms they'd like to see.
nsTimer fires on the thread that created the timer. An nsTimer instance should
only be manipulated on its target thread (it isn't threadsafe). IPC using
PContent must be on the main thread.
Thus, everything to do with the gIPCTimer must be on the main thread.
This also takes care of bug 1299312.
MozReview-Commit-ID: IcVRYsoX2R9
Throw some process selectors in the Histograms and Keyed Histograms sections
to allow users to choose which process type's histograms they'd like to see.
Rewrite the categorical histogram accumulation code to use the common path.
This way it gets remote accumulation for cheap.
MozReview-Commit-ID: 3q6gdSvBix
I saw a one-off crash on try in internal_GetHistogramByEnumId. Not reproducible
but maybe possible if we're trying to accumulate using an invalid ID. So let's
guard against that.
MozReview-Commit-ID: Ei6eTlV91mJ
On content process shutdown we send a content process ping to ensure we have
up-to-date data from the content process before it goes away. Now we need to
also flush the batched telemetry accumulations to the parent so that it can be
present in the ping.
No attempt is made to synchronize access to IPCTimerFired. It is safe to
re-enter.
No attempt is made to cancel the timer as its firing is benign.
MozReview-Commit-ID: 1gjNH9IPhKf
Clear isn't generally called at all, and isn't dispatched to the parent process
for child telemetry aggregation. Clear should only be called on the parent
process.
MozReview-Commit-ID: stIutvAO6h
The JS histograms, too, need to dispatch their accumulations from child to
parent.
JSHistograms_Add now only supports histograms that are in gHistogramsMap or
that were created in the parent process. After bug 1288745, maybe we'll be able
to change this to be less convoluted.
MozReview-Commit-ID: 3qTH89YKbGP
Take the opportunity presented through changing child telemetry accumulation
to bring the ping form closer to the ideas expressed in bug 1281795.
childPayloads still exists, but without histograms or keyedHistograms which are
now at root.processes.content.{keyedH|h}istograms. This will require coordinated
changes in the aggregator and moztelemetry libraries.
MozReview-Commit-ID: AqG2jmBBC2W
To simplify using child telemetry from the parent process, only allow child
telemetry payloads to be generated once per child process, on shut down.
This will allow us to use the child telemetry's subsession information to leave
childPayloads the way it currently is.
Will need to update test_ChildHistograms.js as it is the only consumer.
MozReview-Commit-ID: 2qSztg0QHV5
I originally thought we'd be able to avoid the previous implementation's waste
of a map full of every kind of keyed histogram. Unfortunately, other code
(TelemetrySession at the very least) depends on this (and will throw if a keyed
histogram isn't present, even if it is empty)
MozReview-Commit-ID: 8MCGVa595UB
The original commit didn't properly support subsession histograms, so rectify
that lapse by adding support for stripping out the base name of a histogram
when trying to determine its id.
MozReview-Commit-ID: LvUek6f5WUx
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
Services.logins.removeAllLogins is already done in registerCleanupFunction
MozReview-Commit-ID: 8FGF3kJmvj0
--HG--
extra : rebase_source : fa3dc1d635620f0285009685ff7d0a281a8ba49b
More splitting of test_prompt.html to make these tests easier to maintain/digest.
MozReview-Commit-ID: DuakmtkJ41I
--HG--
rename : toolkit/components/passwordmgr/test/mochitest/test_prompt_promptAuth.html => toolkit/components/passwordmgr/test/mochitest/test_prompt_promptAuth_proxy.html
extra : rebase_source : b0056d757df10befd6d662bdff29e52343835fa9
This switches getPrompt to use a ChromeWindow which matches what the shipping code does for e10s.
MozReview-Commit-ID: DcVSr6JfmdK
--HG--
extra : rebase_source : 35178483a1223c71c0dd2142479799225ccde1bb
This introduces a new NLP (Natural Language Processing) module with only one
method: 'levenstein'. We're using it to allow the highlighter to keep running
when the it starts the iterator with a word that's one edit distance behind the
value in the findField.
MozReview-Commit-ID: K8oeiXoiLUe
This fix is not related to the referenced bug but came up during review.
MozReview-Commit-ID: IjrxWzkLIq1
--HG--
extra : rebase_source : d53179af98106049bcf1a12efed74c4527ac62c1
And change `this.global.Object.create(null)` to
`Cu.createObjectIn(this.global)`. The tests pass either way, but
`Cu.createObjectIn` is more explicit.
MozReview-Commit-ID: LmL6rTru5zZ
--HG--
extra : rebase_source : 4cf7b1463bf8b6882b6fd453657eae0ff43ed64d
Split the `shouldInject` method into separate methods:
- `shouldInject` to determine whether the API (or namespace)
should be injected.
- `getImplementation` to return the actual implementation.
Introduced `SchemaAPIInterface` for documentation purposes, and
two concrete implementations `LocalAPIImplementation` and
`ProxyAPIImplementation` which provide the functionality to run a local
and remote implementation of the API for which the schema API is
generated, respectively. These classes store the necessary details for
the invocation, so the methods that were formerly in the `Context` in
Schemas.jsm no longer get the `pathObj`, `path` or `name` parameters.
And merge the `path` and `name` in the implementation of remote APIs
because there is no need for having them separate, as the callers and
callees often did redundant pre/post-processing on `data.path` because
of the way it was implemented.
MozReview-Commit-ID: isbG9i9pNP
--HG--
extra : rebase_source : 22cdc3ab3d14c6381f9f540739d6750281ae8c71
The API implementation is already available upfront when the schema API
is generated, so `pathObj` has the implementation and can be used
instead of looking up the implementation over and over again with
`findPathInObject`.
MozReview-Commit-ID: FnCIyoaxgA4
--HG--
extra : rebase_source : 440b25fcfb4a0438b1ff8680ad770930e7427de7
- This was the last non-schema-generated API in content scripts.
MozReview-Commit-ID: FaIOCHoircf
--HG--
extra : rebase_source : 7bab2249a7462a581e493f7aa937df45cb895107
