In preferences tests, all calls to waitForEvent function defined in
browser/components/preferences/in-content/tests/head.js has been replaced with
calls to BrowserTestUtils.waitForEvent.
MozReview-Commit-ID: IrtGJFtWPPj
In preferences tests, all calls to waitForEvent function defined in
browser/components/preferences/in-content/tests/head.js has been replaced with
calls to BrowserTestUtils.waitForEvent.
Since we are no longer using the waitForEvent function defined in the
aforementioned head.js file, that definition has been removed.
MozReview-Commit-ID: IrtGJFtWPPj
This adjusts both the new Tracking Protection UI and the old Tracking Protection UI on
about:preferences to indicate when an extension is controlling Tracking Protection. It
will disable the controls on about:preferences if an extension is in control, and provide
a button to disable the extension.
MozReview-Commit-ID: G04jWrS6Pr9
Binding the Preferences object to a "this" object was supposed to enable userChangedValue to access the DeferredTask instance that XPCOMUtils.defineLazyModuleGetter defines on the "this" object.
I thought that worked, because tests passed, but it turned out that no tests are exercising the branch within userChangedValue that references DeferredTask, which is only followed for pref form controls that specify "delayprefsave."
Only font controls specify that attribute, and there weren't any tests for changes to those controls. This patch adds such tests and then changes the way that DeferredTask is lazily retrieved and referenced to ensure it's defined as referenced in userChangedValue.
MozReview-Commit-ID: BPbGp55s9wC
The nsGIOService now provides GetAppsForURIScheme which is used to append handlers
for specific scheme in handler list dialog (toolkit/mozapps/handling/content/dialog.js)
and also in Applications section in preferences. In case the default system handler
or user added handler has same name as one of the GIO handlers, the GIO handler
is not appended. The check for not adding handler is by using handler name.
The nsGIOMimeApp class now implements nsIHandlerApp interface. Instead overloaded
GetName methods (nsCString and nsString) we now use nsString variant everywhere.
This require change of nsGNOMERegistry::GetFromType which if fact leads to code
simplification.
The implementation of nsGNOMEShellService::SetDefaultBrowser has been changed
because implementation of CreateAppFromCommand has changed.
The CreateAppFromCommand no longer tries to find the application,
for that FindAppFromCommand has been introduced.
MozReview-Commit-ID: KmfFWRPqV3
The nsGIOService now provides GetAppsForURIScheme which is used to append handlers
for specific scheme in handler list dialog (toolkit/mozapps/handling/content/dialog.js)
and also in Applications section in preferences. In case the default system handler
or user added handler has same name as one of the GIO handlers, the GIO handler
is not appended. The check for not adding handler is by using handler name.
The nsGIOMimeApp class now implements nsIHandlerApp interface. Instead overloaded
GetName methods (nsCString and nsString) we now use nsString variant everywhere.
This require change of nsGNOMERegistry::GetFromType which if fact leads to code
simplification.
The implementation of nsGNOMEShellService::SetDefaultBrowser has been changed
because implementation of CreateAppFromCommand has changed.
The CreateAppFromCommand no longer tries to find the application,
for that FindAppFromCommand has been introduced.
MozReview-Commit-ID: KmfFWRPqV3
