In Unified Telemetry toolkit.telemetry.enabled controls whether we send base
collection data or extended collection. The difference is mostly in volume, not
in kind (though extended collection has a little stricter testing and monitoring
requirements).
Since the Preferences UI change in Firefox 56, users no longer have the ability
to change toolkit.telemetry.enabled. This is a good thing as for pre-release
users very few disabled extended collection, and even fewer release users
enabled it. This provides uniform collection based on channel which should
eventually net us some efficiencies.
Until then we need to align our use of the toolkit.telemetry.enabled pref with
the UI change that has already shipped. This is accomplished by locking t.t.e
to 'true' on pre-release channels and locking it to 'false' on everything else.
This doesn't apply to Android as it doesn't (yet) use Unified Telemetry. t.t.e
means something rather different there.
MozReview-Commit-ID: EOpWm8b0jWA
This patch implements followings
1. Adding extended attribute [Throws] on ServiceWorkerRegistration
::updateViaCacheattribute.
2. Instead of calling MOZ_ASSERT, returning InvalidStateError when fail to
get the registration in ServiceWorkerRegistration::GetUpdateViaCache().
3. Adding a new mochitest test_bug1408734.html to reproduce the bug
introduced by accessing ServiceWorkerRegistration::updateViaCache after
unregister() finishes.
--HG--
extra : rebase_source : 49fba33bf28bcb74601b87f79ce91787e435939d
Add a new member mAllowPaymentRequest on nsIDocument and following related
methods,
bool AllowPaymentRequest() const
void SetAllowPaymentRequest(bool aAllowPaymentRequest)
mAllowPaymentRequest is used to check if PaymentRequest is allowed to use on
the document. According to the spec
https://html.spec.whatwg.org/multipage/iframe-embed-object.html#allowed-to-use
the mAllowPaymentRequest should be true under following situations
1. The document is the top level content document.
2. The document is the same origin with its parent document and its parent
document's mAllowPaymentRequest is true.
3. The document is different origin with its parent document but its
parent node is an iframe with allowpaymentrequest flag and the parent
document's mAllowPaymentRquest is true.
This patch also include following mochitests
1. test for allowpaymentrequest flag changing. The flag change effect should
not be applied to the document immediately, it should be updated while
the browsing context is updated.
2. test for effect propagation in the nested iframe.
Because nsCString is nicer than UniqueFreePtr<char>.
The patch also streamlines pref_savePrefs(). And also changes StrEscape() to
always put quotations around the result, because that's needed in both call
sites.
MozReview-Commit-ID: HT7HZz4QiSN
--HG--
extra : rebase_source : 442bb6002e004803a9ecb637239a000f11ec5774
First, the patch removes the return values from PrefTypeFlags::Set*(). They
allow chained calls, but they're barely used and they just make the code harder
to read.
Second, the patch changes pref_SetValue() to not modify and return the pref
flags. It's clearer if the flags changing is done separately. This requires
passing pref_SetValue() the old type instead of the flags.
MozReview-Commit-ID: HZVS2TIlBIY
--HG--
extra : rebase_source : 6638244214cda15ceae5a1930659aed434d8261b
It was using the visible rect of the display item before, which can be larger
than the frame for various reasons. But the bounds we pass for the webrender
iframe item determines the iframe's position, so it needs to be informed by the
layout position of the frame, not by circumstances of the paint.
MozReview-Commit-ID: JSmFGLmAm0h
--HG--
extra : rebase_source : ba85778fe1fe509dd593afaac9bf7a4ff9952b49