Since JSWindowActors don't have direct access to synchronous messaging,
ChromeScript callers are going to need to migrate to asynchronous messaging
and queries instead.
Since there's no comparable API to sendQuery for frame message managers, this
patch adds a stub that uses synchronous messaging, but makes the API appear
asynchronous, and migrates callers to use it instead of direct synchronous
messaging. This will be replaced with a true synchronous API in the actor
migration.
Fortunately, most of the time, this actually leads to simpler code. The
`sendQuery` API doesn't have the odd return value semantics of
`sendSyncMessage`, and can usually just be used as a drop-in replacement. Many
of the `sendSyncMessage` callers don't actually use the result, and can just
be changed to `sendAsyncMessage`. And many of the existing async messaging
users can be changed to just use `sendQuery` rather than sending messages and
adding response listeners.
However, the APZ code is an exception. It relies on intricate properties of
the event loop, and doesn't have an easy way to slot in promise handlers, so I
migrated it to using sync messaging via process message managers instead.
Differential Revision: https://phabricator.services.mozilla.com/D35055
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
When we migrate SpecialPowers to a JSWindowActor, it will no longer be able to
use synchronous IPC messaging, which means that its current synchronous APIs
will have to become asynchronous.
This patch doesn't change the behavior of those functions, but it does change
their callers to `await` their return values rather than using them directly.
This pattern will work the same whether the functions return a promise or a
plain value, which simplifies the migration.
Differential Revision: https://phabricator.services.mozilla.com/D35053
Create test entries via update introduces performance overhead.
We can store them directly in LookupCache and do not save test entries
to disk.
Differential Revision: https://phabricator.services.mozilla.com/D34576
As now we won't load disabled text track, we have to mark track as default in order to trigger loading which would be done by automatically text track selection, or to set its track mode explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D32359
This patch does the following:
1. Run the same prefixset tests when
* browser.safebrowsing.prefixset.max_array_size = 0
* browser.safebrowsing.prefixset.max_array_size = UINT32_MAX
This makes sure both of the methods to store prefixset are tested by existing testcases
2. Refine gtest with test fixture
3. Add TinySet and LargeSet testcases
Differential Revision: https://phabricator.services.mozilla.com/D30338
This patch does the following:
1. Run the same prefixset tests when
* browser.safebrowsing.prefixset.max_array_size = 0
* browser.safebrowsing.prefixset.max_array_size = UINT32_MAX
This makes sure both of the methods to store prefixset are tested by existing testcases
2. Refine gtest with test fixture
3. Add TinySet and LargeSet testcases
Differential Revision: https://phabricator.services.mozilla.com/D30338
We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
We don't need an additional array just for byte reordering, replace
it with in-place processing.
Testcase are modified because the LookupCacheV4::Build API now clears the
input parameter.
Differential Revision: https://phabricator.services.mozilla.com/D26861
In the test_classify_by_default.html, we use "network.cookie.cookieBehavior"
to test if a channel is correctly classified.
Cookie restriction is only enabled in nightly and early beta so the
default preference is not always set. Although we set the preference
in the testcase, it is too late because that the channel's cookie
setting might inherit from it's parent and may end up with getting
the old(default) value.
In this patch, we use window.open to test the tracker frame to make
sure we use the udpated prefrence.
Differential Revision: https://phabricator.services.mozilla.com/D25657
The goal of this testcase is to provide an easier way to add callsites
to test if it is correctly classified. This is a first step, more callsites should be added to
the testcase(See Bug 1532691)
Flow of the test case:
1. setup the server(trackerFrame.sjs) with the expceted number of request it should receive
2. load the test frame(trackerFrame.html) with cookie restriction off, to ensure all the tracking requests contain cookies
3. server responses a list of tracker's request with cookie after reciving all the requests
4. the list should contain all the trackers in the test frame.
5. enable cookie restriction and load the test frame again.
6. server responses a list of tracker's request without cookie after reciving all the requests
7. the list should contain all the trackers in the test frame.
Differential Revision: https://phabricator.services.mozilla.com/D22116
This patch adds a xpcsehll-test which tests all the combinations of
those parameters used by the heuristic classification algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D22115
Some testcases are chrome scope testcase hence the resources it loads are triggered by
"system principal". This will exempt the resource from classification.
So in this patch, we used a new window to for the tracker test frame.
The window creation code is referenced from test_privatebrowsing_trackingprotection.html.
Differential Revision: https://phabricator.services.mozilla.com/D22114
The goal of this testcase is to provide an easier way to add callsites
to test if it is correctly classified. This is a first step, more callsites should be added to
the testcase(See Bug 1532691)
Flow of the test case:
1. setup the server(trackerFrame.sjs) with the expceted number of request it should receive
2. load the test frame(trackerFrame.html) with cookie restriction off, to ensure all the tracking requests contain cookies
3. server responses a list of tracker's request with cookie after reciving all the requests
4. the list should contain all the trackers in the test frame.
5. enable cookie restriction and load the test frame again.
6. server responses a list of tracker's request without cookie after reciving all the requests
7. the list should contain all the trackers in the test frame.
Differential Revision: https://phabricator.services.mozilla.com/D22116
This patch adds a xpcsehll-test which tests all the combinations of
those parameters used by the heuristic classification algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D22115
Some testcases are chrome scope testcase hence the resources it loads are triggered by
"system principal". This will exempt the resource from classification.
So in this patch, we used a new window to for the tracker test frame.
The window creation code is referenced from test_privatebrowsing_trackingprotection.html.
Differential Revision: https://phabricator.services.mozilla.com/D22114
