This should address the bug noted above, as well as several other bugs where `validArchs` is responsible for TEST-UNEXPECTED-FAIL.
Differential Revision: https://phabricator.services.mozilla.com/D19822
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
This patch defines a new xpcshell test which loads all the WebExtensions API modules twice,
first in alphabetic order and then again in reversed order.
The goal of this new test is to make it easier to detect issues with API module loading,
because all these API modules are loaded lazily in a shared global and it can fail
if multiple API modules defines the same global in incompatible ways (e.g. something which
is defined as a `const` in one module, and then as a `var` in a different one).
Depends on D18683
Differential Revision: https://phabricator.services.mozilla.com/D19160
--HG--
extra : moz-landing-system : lando
This patch move the part of test_ext_userScripts.js that is testing the userScripts' export API helpers
(script.defineGlobals and script.export) into a separate test_ext_userScripts_exports.js test file.
Based on the logs from the intermittent failures of the test_ext_userScripts.js test file
on android debug builds, it seems that this xpcshell test was just timing out while exiting after all
the test tasks were actually completed.
The results got from pushing to try this patch seems to confirm that once the test tasks are splitted
over two test files, the intermittent failures are not being triggered anymore on the android debug
builds.
Differential Revision: https://phabricator.services.mozilla.com/D17374
--HG--
rename : toolkit/components/extensions/test/xpcshell/test_ext_userScripts.js => toolkit/components/extensions/test/xpcshell/test_ext_userScripts_exports.js
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
AddonManagergetInstallForURL() has a number of optional arguments, most
of which are passed infrequently. Convert them from positional arguments
to a single options object.
Differential Revision: https://phabricator.services.mozilla.com/D18475
--HG--
extra : rebase_source : 503c09b54fab90cefe69286b05def43ef70074df
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
--HG--
rename : netwerk/base/nsIBrowserSearchService.idl => toolkit/components/search/nsISearchService.idl
extra : moz-landing-system : lando
I didn't use the checkPromptModal function because the implementation in chromeScript was getting a null document reference. Since handlePrompt already has access to this information it made sense to extend handlePrompt to cover more cases.
Differential Revision: https://phabricator.services.mozilla.com/D18267
--HG--
rename : toolkit/components/passwordmgr/test/test_xhr.html => toolkit/components/passwordmgr/test/mochitest/test_xhr.html
extra : rebase_source : fdd7b11b6d8cace8b7bef63228aa95f3fceca6df
This test seems to be still failing intermittently, and its intermittency rate looks high enough.
Looking to the logs collected on the recent intermittent failures, it seems that the issue
is still related to the extension tabs opened in the test:
The two extension tabs (each one part of one of the two test extension) are going to exchange messages
between each other, and currently there is a chance (and apparently a very good chance) that one of the
two extension tabs is not yet ready to listen to the messages sent from the other extension tab.
This patch applies to the test the additional changes needed to ensure that both the extension tabs
are ready to exchange messages, before we let them exchange these messages over the extension messaging
API.
Differential Revision: https://phabricator.services.mozilla.com/D18230
--HG--
extra : moz-landing-system : lando
Bug 1450114 -Update browser themes to allow customization of selection background and text r=Jaws
Differential Revision: https://phabricator.services.mozilla.com/D17076
--HG--
extra : moz-landing-system : lando
Prevent adding commands to private windows when extensions do not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17414
--HG--
extra : moz-landing-system : lando
Based on what I've been able to reproduce locally using --verify, there is a chance that
the notifications created by the test case named `test_notifications_populated_getAll`
may have been removed before the `browser.notifications.getAll` is going to retrieve them,
and when this happens the test gets stuck because `browser.test.notifyPass("getAll populated");`
is never reached, and the test timeouts.
This patch includes the following changes to prevent the intermittent failure described above:
- add a new head_notifications.js support file and create a new MockAlertsService test helper that
loads a chrome script which replace the alerts service with a mock service (based on a
similar mock defined in dom/notification/test/mochitest/MockServices.js), the mocked alert
service doesn't close the notification until the test case itself has called
`MockAlertsService.clearNotifications` (so that the test shouldn't fail intermittently as
described above).
- applies the changes needed on test_ext_notifications.html to make use of the MockAlertsService
Differential Revision: https://phabricator.services.mozilla.com/D17863
--HG--
rename : dom/notification/test/mochitest/MockServices.js => toolkit/components/extensions/test/mochitest/head_notifications.js
extra : moz-landing-system : lando
This patch should fix the test_ext_sendmessage_reply2.html intermittency which, based on the
timeout failure that I've been able to intermittently reproduce when running this test
locally using --verify, seems to be likely due to the following race:
the tabs.create API (used to create the extension tabs used as part of the tests) was called
right before subscribing the extension message listeners, and so from time to time the
extension tabs were not able to successfully send their messages to the background page listeners
(because the background page didn't subscribe the listeners yet) and as a result the test was getting
stuck waiting for extension messages that were never going to be received.
Differential Revision: https://phabricator.services.mozilla.com/D17849
--HG--
extra : moz-landing-system : lando
Prevent web_accessible_resources resources loading in private contexts when extension does not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17138
--HG--
extra : moz-landing-system : lando
Prevent web_accessible_resources resources loading in private contexts when extension does not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17138
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
