This is a rollup of all the patches that have landed on the cedar project branch:
891252fdd0
Bug 1492475 - Part 1: Migrate most, if not all nsSearchService consumers to use async APIs. r=florian
79b2eb2367
Bug 1492475 - Part 2: Move nsIBrowserSearchService.idl to toolkit/components/search/nsISearchService.idl and update references. r=florian
a947d3cdf0
Bug 1492475 - Part 3: The search service init() method should simply return a Promise. r=florian
c1e172dfac
Bug 1492475 - Part 4: Remove the synchronous initialization flow. r=florian
cd41189eac
Bug 1492475 - Part 5: Since async initialization of the search service now is implicit behavior, remove the distinctive verbiage used internally. r=florian
2ae7189dfa
Bug 1492475 - Part 6: Update the cache build task to work with an actual Promise and re-initialize only once at the same time - all to fix race conditions here. r=florian
c8ee92973f
Bug 1492475 - Part 7: Make the region fetch not block the init flow, to ensure it's as fast as possible. r=florian
c44e674e16
Bug 1492475 - Part 8: Introduce an init flag, which can only be used privately, that allows to explicitly skip waiting for the region check process to complete. r=florian
6c79eaf1d3
Bug 1492475 - Part 9: Update unit tests to stop using 'currentEngine', in favor of 'defaultEngine'. r=Standard8
21b3aa17ee
Bug 1492475 - Part 10: Update unit tests to be fully aware of the new, async signatures of the search service API and remove sync init flow tests. r=mkaply,florian
ce5ba69019
Bug 1492475 - Part 11: Repair incorrect usage of the `identifier` property of nsISearchEngine instances. r=florian
fd177a7994
Bug 1518543 - Fix up the Android (Fennec) nsISearchService shim to work with the new asynchronous API. r=florian
3653d8ee22
Bug 1523708 - Change the search service interaction in the show-heartbeat action to use the new async API. r=florian
Differential Revision: https://phabricator.services.mozilla.com/D18355
This patch applies the following changes:
- make sure that the WebExtensions internals do not create any devtools_page related to a private tabs' toolbox
if the extension is not allowed to access the private browsing windows
- define a new mochitest to verify the expended behaviors on the private windows when the extension is
allowed and not allowed
Depends on D15948
Differential Revision: https://phabricator.services.mozilla.com/D15949
This patch moves some "devtools related" test helpers into a shared support file,
and updates all the existing devtools API mochitests to use the new shared test helpers.
This change has also the following nice side-effects:
- remove any usage of the custom devtools module loader from the webextensions mochitests.
- use a custom "test blank toolbox panel" in all the devtools API tests that doesn't need a specific
panel to be selected (which should help to make the test able to run a bit faster because none of
the more expensive devtools panels is going to be loaded during the tests if not actually needed).
Differential Revision: https://phabricator.services.mozilla.com/D15948
This patch applies the following changes:
- Reduce the chances of retrieving the initial popup panel size while it is resizing, by comparing the
content dimensions retrieved before and after the delay (which is already set to a value comparable
to the time used by the resize debouncing timer), and wait until both the dimensions collected are the same
- split browser_ext_browserAction_popup_resize.js into two test files (as it seems, based on the investigations
I did by reproducing this intermittent locally, that the part that can still fail intermittently from time
to time with the change describe above is related to the testBrowserActionMenuResizeBottomArrow test case)
- move the test helpers shared between the two test files into a new head_browserAction.js support file
- re-enabled browser_ext_browserAction_popup_resize.js
- mark the new browser_ext_browserAction_popup_resize_bottom.js as disabled on debug build,
because it is consistently triggering a "shutdown leak" failure when running locally
Differential Revision: https://phabricator.services.mozilla.com/D17267
This changes the policy to use the pref and permissions rather than a boolean flag. Using permissions gets us proper settings on startup without introducing any new overhead. Going this way flips our tests around so rather than testing an override to turn off private browsing support, we test overrides to enable private browsing support.
Differential Revision: https://phabricator.services.mozilla.com/D14482
This patch applies the following changes:
- Reduce the chances of retrieving the initial popup panel size while it is resizing, by comparing the
content dimensions retrieved before and after the delay (which is already set to a value comparable
to the time used by the resize debouncing timer), and wait until both the dimensions collected are the same
- split browser_ext_browserAction_popup_resize.js into two test files (as it seems, based on the investigations
I did by reproducing this intermittent locally, that the part that can still fail intermittently from time
to time with the change describe above is related to the testBrowserActionMenuResizeBottomArrow test case)
- move the test helpers shared between the two test files into a new head_browserAction.js support file
- re-enabled browser_ext_browserAction_popup_resize.js
- mark the new browser_ext_browserAction_popup_resize_bottom.js as disabled on debug build,
because it is consistently triggering a "shutdown leak" failure when running locally
Differential Revision: https://phabricator.services.mozilla.com/D17267
This patch applies the following changes:
- Reduce the chances of retrieving the initial popup panel size while it is resizing, by comparing the
content dimensions retrieved before and after the delay (which is already set to a value comparable
to the time used by the resize debouncing timer), and wait until both the dimensions collected are the same
- split browser_ext_browserAction_popup_resize.js into two test files (as it seems, based on the investigations
I did by reproducing this intermittent locally, that the part that can still fail intermittently from time
to time with the change describe above is related to the testBrowserActionMenuResizeBottomArrow test case)
- move the test helpers shared between the two test files into a new head_browserAction.js support file
- re-enabled browser_ext_browserAction_popup_resize.js
- mark the new browser_ext_browserAction_popup_resize_bottom.js as disabled on debug build,
because it is consistently triggering a "shutdown leak" failure when running locally
Differential Revision: https://phabricator.services.mozilla.com/D17267
This patch fixes the typo in the requiresCleanup getter and adds an additional step
in the automated tests to verify that the scripts created by browser.tabs.removeCSS
are not being added to the content scripts that requires cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D17345
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
The places-tree destructor lacks a `result.removeObserver(this.view);`
call before the assignment to `result.root.containerOpen`, which is
causing a memory leak.
This patch fixes the leak by removing the `result.root.containerOpen`
assignment, since the correct logic already exists in the `setTree`
method of `PlacesTreeView`, which is called upon `this.view = null;`
(XULTreeElement::SetView -> nsTreeBodyFrame::SetView -> setTree).
Differential Revision: https://phabricator.services.mozilla.com/D17241
This patch applies the following small change to the openContextMenuInOptionsPage test helper:
Instead of using BrowserTestUtils.synthesizeMouseAtCenter, the new version of the test helper
triggers a contextmenu event directly on the target element, to prevent intermittent failures
on debug builds (especially linux32-debug).
The intermittent failures seem to be originated by an unexpected behavior of DOMWindowUtils's
sendMouseEvent method, which is randomly triggering mouse events targeting the entire HTML document
instead of the intended DOMElement (despites the EventUtils.js "synthesizeMouseAtPoint" method is
computing the same `left` and `top` position in both the cases).
It seems that there could be some timing reasons behind the issue, because the intermittency
is reduced by adding an arbitrary long delay before triggering the mouse event.
Differential Revision: https://phabricator.services.mozilla.com/D16345
This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
