Bug 1286530 made TCPSocket ChromeOnly, eliminating both the
dom.mozTCPSocket.enabled preference check as well as the "tcp-socket"
permission check. The API is now always exposed in chrome contexts.
This patch removes the leftover (and confusing) dead code.
Renamed and why:
- test_tcpsocket_enabled_no_perm.html renamed to
test_tcpsocket_not_exposed_to_content.html because it's now just a
question of content never seeing the API.
Removed tests and why:
- test_tcpsocket_enabled_with_perm.html used to be a standalone
verification of our permission check. We have no permission check
now and both test_tcpsocket_jsm.html and
test_tcpsocket_client_and_server_basics.html serve as tests that we
affirmatively expose the API and there are no "late" failure (such
as a secondary check in the parent).
- test_tcpsocket_default_permissions.html duplicated what (now)
test_tcpsocket_not_exposed_to_content.html accomplishes. It tried to
use the API and expect an exception. This is just superstition in a
WebIDL. (TCPSocket was not originally WebIDL-y.)
--HG--
rename : dom/network/tests/test_tcpsocket_enabled_no_perm.html => dom/network/tests/test_tcpsocket_not_exposed_to_content.html
extra : rebase_source : d2231ed3b0fb00541cc266569c2a7908a4074f9c
The use of add_task.js was ever only intended to be temporary until
bug 1078657 landed.
--HG--
extra : rebase_source : d9570859b35691002cf7f4642603f6730ddab7ad
This hint will inform readers if caching is discouraged (e.g., for
SourceBufferResource) or recommmended (e.g., for MediaCache-backed
ChannelMediaResource).
MozReview-Commit-ID: 7hopNS0s5tE
--HG--
extra : rebase_source : 681646cc904229e8513adb148baa085254508049
Right now SelectHelper and InputWidgetHelper are loaded in browser.js,
which means they only work for GeckoApp. This patch loads them in
PromptService.js instead, which means they will work in all windows. The
patch also changes some code in SelectHelper and InputWidgetHelper that
used to assume they are running under the browser.xul chrome window.
MozReview-Commit-ID: HveDzIzK1b4
It causes an assert failure in gtk which prints to the console.
MozReview-Commit-ID: A4106Z4rT36
--HG--
extra : rebase_source : 642c94a95cfa3939bc475e9139ee63caa78e3005
If MOZ_CRASH_UNSAFE_PRINTF is only given a format string, it means
either arguments are missing, or MOZ_CRASH should be used instead.
Hint at that with a static_assert.
--HG--
extra : rebase_source : 355c37deb8b007e61939a4c657e411d110e7bbe7
Bug 1368932 removed MOZ_STATIC_ASSERT_VALID_ARG_COUNT because it didn't
actually work for large numbers of arguments. But it was kind of useful
for macros that expand to something broken when they are given no
variadic argument at all.
Now that we have a macro that doesn't require tricks to count empty
arguments lists, however, we can use straightforward static_asserts
instead of a generic macro, which has the side effect of providing more
context in the error message.
--HG--
extra : rebase_source : 223f85c2c5cc7b3fa8c584b70bb084784fb5764a
In a couple places, MOZ_PASTE_PREFIX_AND_ARG_COUNT is used to only count
the number of arguments, we can now use MOZ_ARG_COUNT directly for that.
--HG--
extra : rebase_source : 1064e4cc231863dc4aff83ee6bc90d318b4be418
I'm not sure how I tested MOZ_FOR_EACH in bug 1368932, but it turns out
it doesn't work with an empty list, despite
MOZ_PASTE_PREFIX_AND_ARG_COUNT now supporting 0 arguments.
Macros can be tricky, and it ends up being easier to make things work
cross-compiler with a separate macro that does the counting, and
(re)building MOZ_PASTE_PREFIX_AND_ARG_COUNT on top of that. Then
MOZ_FOR_EACH ends up working as expected with an empty list.
So this adds a MOZ_ARG_COUNT macro that counts the number of variadic
arguments it's given, and derives MOZ_PASTE_PREFIX_AND_ARG_COUNT from
it.
And this adds a testcase validating that MOZ_FOR_EACH works properly
with an empty list as a result.
--HG--
extra : rebase_source : 309371d87bd1561fbd2153f44fc1256185045d23
Redirect the link to about:preferences#privacy-reports
MozReview-Commit-ID: HIq9zpT6Jz9
--HG--
extra : rebase_source : 8393573834367174ef743c09470f74c22e1ccbdd
The current channel annotation is happened at nsChannelClassifier::OnClassifyComplete and this is too late because this channel might be already hit the network.
This patch adds a new API CheckIsTrackerWithLocalTable in nsChannelClassifier to check if the URI is in local blacklist and whitelist before calling BeginConnectActual.
Please note that whitelist will be checked only when TP is disabled.
--HG--
extra : rebase_source : 0761f6c7631bc934691c8d018be88514568a3aa1
The original code creates nsChannelClassifier and calls ShouldEnableTrackingProtection twice when TP is enabled. To avoid redundancy, this patch makes channel classifier as a data member in nsHttpChannel. Note that the data member is a weak ptr to prevent ref count cycle.
--HG--
extra : rebase_source : 4a77f1e51b38e27a065162cc702091aca2db51de
Because the nsVideoFrame's creation is not synchronous to "append to dom tree", there is a small gap
that the TextTrackManager wants to render cue but no frame. Change the testcase to not hit the period.
MozReview-Commit-ID: 9xhMjRJnoDR
