Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
Getting rid of this pref allowed some other code to be removed:
- Changed nsIUpdateService::stopChecking(duration) to nsIUpdateService::stopCurrentCheck() and got rid of the constants representing durations. The available durations were CURRENT_CHECK, CURRENT_SESSION, and ANY_CHECKS, but only CURRENT_CHECK was ever used.
- nsIUpdateChecker::stopChecking(CURRENT_SESSION) and nsIUpdateChecker::stopChecking(ANY_CHECKS) were the only mechanisms for setting Checker::_enabled to false, so Checker::_enabled and Checker::enabled were removed. References to Checker::enabled were replaced with checks for nsUpdateService::canCheckForUpdates.
- In browser/base/content/aboutDialog-appUpdater.js, the updateDisabledAndLocked() function was renamed to updateDisabledByPolicy, since the old name is no longer accurate and the new function name is a better description of the function's actual use.
MozReview-Commit-ID: 4wwqo4ROr1V
Getting rid of this pref allowed some other code to be removed:
- Changed nsIUpdateService::stopChecking(duration) to nsIUpdateService::stopCurrentCheck() and got rid of the constants representing durations. The available durations were CURRENT_CHECK, CURRENT_SESSION, and ANY_CHECKS, but only CURRENT_CHECK was ever used.
- nsIUpdateChecker::stopChecking(CURRENT_SESSION) and nsIUpdateChecker::stopChecking(ANY_CHECKS) were the only mechanisms for setting Checker::_enabled to false, so Checker::_enabled and Checker::enabled were removed. References to Checker::enabled were replaced with checks for nsUpdateService::canCheckForUpdates.
- In browser/base/content/aboutDialog-appUpdater.js, the updateDisabledAndLocked() function was renamed to updateDisabledByPolicy, since the old name is no longer accurate and the new function name is a better description of the function's actual use.
MozReview-Commit-ID: 4wwqo4ROr1V
Also changes the tooltip on the home button to be independent of the URLs
it opens, per dolske.
Some tests explicitly set browser.startup.homepage, but only through
SpecialPowers.putPrefEnv. That's a good compromise, given the extra
functionality there.
MozReview-Commit-ID: FPLxzi3jQAP
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
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
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
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
