Since we're naming this new file as DateTimePickerContent, it's also a good opportunity to rename the DateTimePickerHelper to DateTimePickerParent to make it more meaningful
MozReview-Commit-ID: 9xNwUjZb6UF
--HG--
rename : toolkit/content/browser-content.js => toolkit/modules/DateTimePickerContent.jsm
rename : toolkit/modules/DateTimePickerHelper.jsm => toolkit/modules/DateTimePickerParent.jsm
extra : rebase_source : 89cbaa19e74a904d39087de2cdfbc2789c40057f
This probe will register and record (for the duration of the study only):
* When a login form is loaded
* When a login form is submitted (excluding the case from unresolved bug 1287202)
The login_form probe has an 'extra' field called 'flow_id'. This value associates actions that occur in the same tab.
It should be noted that for several reasons, we should expect a higher than 1:1 ratio between 'load' and 'submit' events:
* Some sites, like Google and Amazon, have a two-step login process, and each step fires its own 'load' event. Only the second step fires a 'submit' event.
* Some sites, like Facebook and Twitter, fire multiple 'load' events on the same page.
* A common pattern for unsuccessful logins is for the site to redirect to a page with a login form. This would be a 'load' --> 'submit' --> 'load' series.
* Unlike 'load', the 'submit' event fires only when the Password Manager is enabled and the user is in a non-private window. 'Load' events will have a 'canRecordSubmit' key in the 'extra' field which will be true if a submit event for that form can be recorded.
MozReview-Commit-ID: LOMDSN6tgRV
--HG--
extra : rebase_source : d88dbf2ad97892e14c6a9378cae2559af9c40b92
These probes will register and record (for the duration of the study only):
* When the user is prompted by the Password Manager
* When the user saves their login information through the Password Manager prompt
* When the user updates their login information through the Password Manager prompt
* When the user uses login information stored by the Password Manager
Both the 'pwmgr' and 'pwmgr_use' probe have an 'extra' field called 'flow_id'. This is a tab identifier. For a given session, flow_id remains constant, even if the tab is moved to a different index within the same window. Tabs at the same index in different windows will have different flow_ids.
MozReview-Commit-ID: CoBNl6lUQmH
--HG--
extra : rebase_source : 3708e443de487766ff8bf38237a462519a9db82b
These probes will register and record (for the duration of the study only):
* When a bookmark is added.
* When a bookmark is removed.
* When a bookmark is visited.
Also moved init of study module to later in startup as an idle task to mitigate performance impact. Previously, this patch was failing the browser/base/content/test/performance/browser_startup.js test.
Note for bookmark added/removed: Using the source argument, we can filter out bulk events like from Sync, import, restore, etc.
Note for bookmark visited: This will also fire for the case when the user visits a page directly that happens to be bookmarked. The user doesn't have to "click" on a bookmark.
MozReview-Commit-ID: EYVlTLfVLkd
--HG--
extra : rebase_source : 4363a7725c7fd8a25ab4980b87c68f619437c764
Intended to undo study-related changes that don't need to persist between sessions: clear prefs, remove observers, etc.
MozReview-Commit-ID: GsoDhxf6CVJ
--HG--
extra : rebase_source : 5679a48de8e7e95c2b02619738582948032b2c19
Module was renamed in order to be more consistent with references to this study elsewhere, as in the tracking bug 1457226.
Also removed TelemetryEvents.sendEvent method, set log level to 'warn' and added milestone bug to search probe.
MozReview-Commit-ID: KU82dQZLgxB
--HG--
rename : browser/modules/ShieldStudySavant.jsm => browser/modules/SavantShieldStudy.jsm
extra : rebase_source : 175a029e1d0c3c536cc601e6382568832258aad5
This module observes the study pref to enable/disable the study.
MozReview-Commit-ID: 1dcHfk5tc3Q
--HG--
extra : rebase_source : 4f5846f1931369f5549c67dcb8cb1584c8888d14
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Aside from making things easier for JS callers, this also makes it harder to
accidentally trigger an early load of the service, which can be expensive
during startup.
This also makes a slight change to nsPluginHost to initially preserve the
previous blocklist state when a plugin is updated, to avoid the risk of the
possible additioanl asynchrony unblocking a plugin that should stay blocked.
MozReview-Commit-ID: 4EvIGJ1Ke0Z
--HG--
rename : toolkit/mozapps/extensions/nsBlocklistService.js => toolkit/mozapps/extensions/Blocklist.jsm
extra : rebase_source : e7047615ea3a728478695c76a0c521b0281f363b
extra : amend_source : b74115abacacd17ae3e8433a534a5bbb541905b0
***
Bug 1454202: Part 1a - Auto-replace uses of callback-based AddonManager APIs with Promise-based versions. r=aswan
This was done using the following script:
4cd5ae9597/processors/aom-api-generators.jsm
MozReview-Commit-ID: 8hobLz15a66
***
Bug 1454202: Part 1b - Manually fix eslint errors after auto-rewrite. r=aswan
This also deletes an obsolete test whose xpcshell variant was already deleted.
MozReview-Commit-ID: DM9W9Q2SVIE
***
Bug 1454202: Part 1c - Manually fix non-eslint issues after auto-rewrite. r=aswan
MozReview-Commit-ID: DtMscWZuExc
--HG--
extra : rebase_source : d4c2f80bdf02ec4a07e3713a9ae1823145d25942
