Adds testing webrequest events related to async handling in httpChannel
that was added in bug 1407384.
Differential Revision: https://phabricator.services.mozilla.com/D22373
--HG--
extra : moz-landing-system : lando
When the dns resolution for an url's hostname fails, the webRequest API seems to be
receiving (from time to time but more often on macos and windows) more then one call
to the HttpObserverManager.observeActivity method for the activityType
nsISocketTransport.STATUS_RESOLVING and nsISocketTransport.STATUS_RESOLVED
while channel wrapper errorString property is still null.
The observeActvity method goal seems to fire fallback WebRequest errors for error conditions
that are not fired as ChannelWrapper error events, but the "NS_ERROR_UNKNOWN_HOST" error
is also being fired right after the fallback webRequest error event fired as
"NS_ERROR_NET_ON_RESOLVED" (or "NS_ERROR_NET_ON_RESOLVING").
This behavior consistently triggers the two intermittent failures on the test
test_ext_webrequest_basic.html while executing the test_webRequest_frames
task
"expected error message received in onErrorOccurred - Expected: NS_ERROR_UNKNOWN_HOST, Actual: NS_ERROR_NET_ON_RESOLVED"
(when the fallback NS_ERROR_NET_ON_RESOLVED is fired first)
and then
"received onErrorOccurred"
(because the "NS_ERROR_UNKNOWN_HOST" error is also being fired
right after the fallback error message).
Differential Revision: https://phabricator.services.mozilla.com/D22587
--HG--
extra : moz-landing-system : lando
This patch addresses remaining test issues when pref'ing on. These are tests that
previously ran some tests in private contexts that now require the use of incognitoOverride.
This also fixes an xpcshell test wrapper to set the permission when overridden.
Differential Revision: https://phabricator.services.mozilla.com/D21300
--HG--
extra : moz-landing-system : lando
This patch addresses remaining test issues when pref'ing on. These are tests that
previously ran some tests in private contexts that now require the use of incognitoOverride.
This also fixes an xpcshell test wrapper to set the permission when overridden.
Differential Revision: https://phabricator.services.mozilla.com/D21300
--HG--
extra : moz-landing-system : lando
mDomain in MatchPattern is inconsistent with nsIURI for IPv6 URL, which causes
failure of IPv6 matching. We normalize mDomain by droping the brackets so that
it's consistent with nsIURI.
Differential Revision: https://phabricator.services.mozilla.com/D20603
--HG--
extra : moz-landing-system : lando
The main behavior changes are:
1) We no longer create a new Window when doing document.open(). We use the
same Window but remove all the event listeners on it and on the existing DOM
tree before removing the document's existing kids.
2) We no longer create a new session history entry. The existing one always
gets replaced instead.
3) We now support document.open on documents that are not in a Window.
The reasons for the various test changes are as follows:
The change to browser_modifiedclick_inherit_principal.js is because we no
longer set the docshell to a wyciwyg URL when document.open() happens and the
test was depending on that to terminate.
browser_wyciwyg_urlbarCopying.js is being removed because it's trying to test
wyciwyg URIs, which no longer exist.
The changes in docshell/test/navigation are because document.open() no longer
affects session history. One of the tests was testing the interactions there
and is being removed; another is being repurposed to just test that
document.open() does not affect history.length.
The change to test_x-frame-options.html is because document.open() now removes
event listeners on the window, which it didn't use to do (and in the specific
case in this test reused the existing inner too, so the listener was still
around in practice). The new behavior matches other browsers.
The removal of test_bug172261.html is because document.open() no longer affects
session history, so you can't go back across it or forward to the "opened"
state, so the situation that test is trying to test no longer exists.
The changes to test_bug255820.html are because reloading a document after
document.open() will now just load the URL of the document that was the entry
document for the open() call, not reload the written content. So there's not
much point testing reload behavior, and in this test it was just reloading the
toplevel test file inside the frames.
The change to test_bug346659.html is because now we no longer create a new
Window on document.open().
The change to test_bug1232829.html is because document.open() (implicit in this
test) no longer adds history entries, so the back() was just leaving the test
page instead of going back across the document.open(). The test is a
crashtest in practice, so might still be testing something useful about how
document.open() interacts with animations.
The change to test_bug715739.html is because the URL of the document after
document.open() is now the URL of the entry document, not a wyciwyg URL, so
reload() has different behavior than it used to.
The change to test_bug329869.html is because now when we go back we're
reloading the original document we had, not doing a wyciwyg load, and the
security info now doesn't include the untrusted script.
The changes to the wpt expectations are removing a bunch of expected failures
now that we pass those tests and disabling some tests that are fundamentally
racy and hence fail randomly. The latter all have github issues filed for the
test problem.
The change to testing/web-platform/tests/common/object-association.js is fixing
tests that were not matching the spec (and were failing in other browsers).
The change to parser-uses-registry-of-owner-document.html is fixing tests that
were not matching the spec (and were failing in other browsers).
The change to document-write.tentative.html is because the test was buggy: it
was using the same iframe element for all its tests and racing loads from some
tests against API calls from other tests, etc. It's a wonder it ever managed
to pass, independent of these patches (and in fact it doesn't pass according to
wpt.fyi data, even in Firefox).
The changes in html/browsers/history/the-history-interface are because
document.open() no longer adds history entries. The test was failing in all
other browsers for the same reason.
The changes in html/browsers/history/the-location-interface are because
reloading a document.open()-created thing now loads the URL of the page that
was the entry document for the open() call. The test was failing in all other
browsers.
The change to reload_document_open_write.html is because we now reload the url
of the document that entered the script that called open() when we reload, not
the written content. Other browsers were failing this test too; Gecko with
the old document.open implementation was the only one that passed.
The change to http-refresh.py is to fix a test bug: it was not returning a
Content-Type header, so we were putting up helper app dialogs, etc.
The change to test_ext_contentscript.js is because we no create a new global
for document.open() calls. Kris Maglione OKed this part.
Differential Revision: https://phabricator.services.mozilla.com/D17323
--HG--
extra : moz-landing-system : lando
When a user first upgrades to a version where incognito is enabled,
add the permission to all enabled extensions. This preserves user workflow
and addresses other issues (e.g. proxy). This will only happen once.
Differential Revision: https://phabricator.services.mozilla.com/D19442
--HG--
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.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
Setting the permission has to happen after the call to parseManifest so
it may be set if the manifest is already cached. Also grant permission
when installed from permanent private browsing.
Differential Revision: https://phabricator.services.mozilla.com/D18879
--HG--
extra : moz-landing-system : lando
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
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
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
***
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
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
If the extension had either default_icon or one of it's property as an empty string, it would show a black icon in the toolbar. With this patch, it checks if any of default_icon property is empty and throws an error on extension load.
Differential Revision: https://phabricator.services.mozilla.com/D16070
--HG--
extra : moz-landing-system : lando
The fixes in bug 1503760 inadvertently broke searches of downloads that
have not yet started receiving data (which have a value of -1 for the
totalBytes property). That regression is fixed here.
Differential Revision: https://phabricator.services.mozilla.com/D16889
--HG--
extra : rebase_source : d6abf7e5bdc2ae10e690df56c060b30166fc75f7
extra : amend_source : 6580b889860d4d28f216fd92522ecd539a8f7d1d
If an extension with the "mozillaAddons" permission is updated, the
permission diffing logic should support restricted schemes.
Otherwise the MatchPattern will throw and prevent the update from being
installed.
`Extension.comparePermissions` is called with the result of
`.userPermissions`, which in turn is equivalent to the result of the
`manifestPermissions` getter. This already filters out restricted
schemes if needed. Therefore we can unconditionally use
`restrictSchemes:false` in `comparePermissions`.
And update the regexp in formatPermissionStrings to support permissions
that start with "about:", since the "MatchPatternUnestricted" type in
toolkit/components/extensions/schemas/manifest.json supports this,
and the lack of "//" in about:-URLs prevents the scheme from being
matched by the existing pattern.
Depends on D14963
Differential Revision: https://phabricator.services.mozilla.com/D14964
--HG--
extra : moz-landing-system : lando
Permission warnings only include the host name (ignoring any scheme),
so the comparison of old and new permissions should ignore schemes too.
Any origin permission has to match the definition of "MatchPattern"
as defined in toolkit/components/schemas/manifest.json.
For normal (non-privileged extensions), this is either <all_urls>, or a
pattern consisting of the "http", "https", "ws", "wss", "file", "ftp"
schemes.
Depends on D5527
Depends on D5527
Differential Revision: https://phabricator.services.mozilla.com/D14963
--HG--
extra : moz-landing-system : lando
The "permissions" array of the raw manifest is not (and should not) be
used for permission checking, so it is not necessary to strip the
"mozillaAddons" permission from it.
This commit moves the validation of the "mozillaAddons" permission to
classifyPermission, so that the "manifestPermissions" getter (that uses
this method too) accurately reflects the supported permissions of an
extension.
New tests has been added to verify the permission warnings for some
combinations of permissions. This also includes tests that verify
that only privileged extensions can use "mozillaAddons" to unlock
unrestricted schemes.
Differential Revision: https://phabricator.services.mozilla.com/D5527
--HG--
extra : moz-landing-system : lando
Add support for enumerations to boolean types, and use it to only show
a deprecation message when background.persistent is false.
Differential Revision: https://phabricator.services.mozilla.com/D15507
--HG--
extra : moz-landing-system : lando
This patch includes the following changes:
- move into the API schema wrappers the additional checks needed (in the child process) to ensure that we throw a validation error when
a webRequest blocking listener is registered by an extension that doesn't have the required webRequestBlocking permission:
- define a new webRequestBlockingPermissionRequired postprocessor
- add to web_request.json API schema the `"postprocess": "webRequestBlockingPermissionRequired"` property
to all the webRequest options types that allows "blocking" as a valid string value (currently
OnBeforeRequestOptions, OnBeforeSendHeadersOptions, OnHeadersReceivedOptions and OnAuthRequiredOptions)
- add back an additional check for the webRequestBlocking permission in parent/ext-webRequest.js
(just in case a new webRequest event is added in the future and we forget to add the postprocess
property, so that we still ensure that an extension without the webRequestBlocking permission
is not able to register any blocking listener)
- tweak the test_no_webRequestBlocking_error test case to use browser.test.assertThrows to explicitly check
that the error is thrown and "catchable" by the extension code, and not just logged in the console
messages, and extend it to run on all the webRequest API events that can be blocking.
Differential Revision: https://phabricator.services.mozilla.com/D14994
--HG--
extra : moz-landing-system : lando
