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
--HG--
extra : moz-landing-system : lando
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
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
The test failed if onHighlighted was received late, since it has an array of IDs. This change should address any case where we need to get the tab from id.
Differential Revision: https://phabricator.services.mozilla.com/D14860
--HG--
extra : moz-landing-system : lando
Also, use a single hidden window to hold <browser> elements
for multiple extensions.
Differential Revision: https://phabricator.services.mozilla.com/D14163
--HG--
rename : browser/components/extensions/test/browser/browser_ext_tabs_cookieStoreId.js => browser/components/extensions/test/browser/browser_ext_tabs_cookieStoreId_private.js
extra : moz-landing-system : lando
This patch replace the LWT aliases with their related non-deprecated alias in all the theme API tests
that don't seem to be specifically testing the LWT aliases (e.g. browser_ext_themes_lwtsupport.js is
leaved unmodified for this reason).
The main reason to replace them in the "not stricly LWT-related" tests before their final removal
(currently planned for Firefox 69) is that the deprecation warnings will make these tests more
noisy (and so they may be making harder to investigate failures, without any actual gain in terms
of coverage).
Depends on D12297
Differential Revision: https://phabricator.services.mozilla.com/D12783
--HG--
extra : moz-landing-system : lando
Previously the omnibox keyword would not allow trailing slashes, such as go/
Chrome allows this keyword, and Firefox should allow this too.
Differential Revision: https://phabricator.services.mozilla.com/D12242
--HG--
extra : moz-landing-system : lando
1. Add successorTabId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
Add an optional previousTabId property to the onActivated event,
which is present if the previously activated tab is still open.
Differential Revision: https://phabricator.services.mozilla.com/D9271
--HG--
extra : moz-landing-system : lando
All instances of nsIBrowserSearchService::currentEngine have been replaced by nsIBrowserSearchService::defaultEngine. Dropping this variable now.
Differential Revision: https://phabricator.services.mozilla.com/D12223
--HG--
extra : moz-landing-system : lando
Bug 1469148 added support for detecting which mouse button was used,
by synthetizing "command" events when a "click" event was captured.
The implementation did not account for unclickable menu items, such
as items that act as the parent of a submenu (see bug report),
separators and disabled menu items.
This patch adds the necessary checks and regression tests for these
scenarios to make sure that such clicks are ignored, as expected.
Differential Revision: https://phabricator.services.mozilla.com/D13084
--HG--
extra : moz-landing-system : lando
This improves performance by keeping snapshots around for some time if there are no changes done by other processes. If a snapshot is not destroyed immediately after getting into the stable state then there's a chance that it won't have to be synchronously created again when a new opeartion is requested.
The implementation is based on a cache (datastore) living in the parent process and sync IPC calls initiated from content processes.
IPC communication is done using per principal/origin database actors which connect to the datastore.
The synchronous blocking of the main thread is done by creating a nested event target and spinning the event loop.
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
1. Add successorId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Depends on D4731
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
Add an optional previousTabId property to the onActivated event,
which is present if the previously activated tab is still open.
Differential Revision: https://phabricator.services.mozilla.com/D9271
--HG--
extra : moz-landing-system : lando
In Bug 1479125 we put calls to .children that were intended to access child elements into the custom
method, which is a slower path. We may eventually want to remove itemChildren altogether and just assume
that all children are items, but that's out of scope for a perf fix like this.
Differential Revision: https://phabricator.services.mozilla.com/D10751
--HG--
extra : moz-landing-system : lando
This patch solves half of the problem but it will still show the transition when the window regains focus. I am OK with removing the transition on the title bar, we will still have it on the navbar and bookmarks toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D11282
--HG--
extra : moz-landing-system : lando
Until container tabs are supported in private browsing mode
(bug 1320757), extensions should not be able to open container tabs when
perma-private browsing mode is off.
Differential Revision: https://phabricator.services.mozilla.com/D9517
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
Usually, documentUrlPatterns applies to the URL of the document where
the context menu is opened. In some cases, there is no document, such
as menus on browser UI (extension action buttons, tools menu, tabs).
In these cases, `documentUrlPatterns` matches the (active) tab's URL.
This causes ambiguity when `browser.menus.overrideContext` is used to
change the context to the "tab" context.
Before this patch, `documentUrlPatterns` applied to the tab's URL.
After this patch, `documentUrlPatterns` applies to the URL of the
document where the menu was opened, *if* `viewTypes` is also set.
Using this property is a strong signal from the extension that the menu
is meant to be shown in a document rather than browser UI, so extensions
can reasonably expect `documentUrlPatterns` to match the original
document's URL instead of the URL of the spoofed tab context.
There was no existing test coverage for documentUrlPatterns on tab
contexts, so this does not only add tests for documentUrlPatterns on
overridden contexts (browser_ext_menus_replace_menu_context.js), but
also documentUrlPatterns in normal tab contexts (browser_ext_menus.js).
Differential Revision: https://phabricator.services.mozilla.com/D9249
--HG--
extra : moz-landing-system : lando
Prior to this patch, if a user attempted to use a keyboard shortcut that used a numeric key, the action would not be triggered if they used the numeric key from the number pad. This patch triggers the shortcut regardless of the source.
Differential Revision: https://phabricator.services.mozilla.com/D8535
--HG--
extra : moz-landing-system : lando
Use a homepage URL instead of a new tab URL by default in
browser.windows.create.
Differential Revision: https://phabricator.services.mozilla.com/D6030
--HG--
extra : moz-landing-system : lando
Use a homepage URL instead of a new tab URL by default in
browser.windows.create.
Differential Revision: https://phabricator.services.mozilla.com/D6030
--HG--
extra : moz-landing-system : lando
This updates the test to use a multiple of the default process count rather
than hardcoding 8.
--HG--
extra : rebase_source : b5d7d34b4994ea7e2e453ec833f218919146636f
extra : source : 403c3d0daf6a24a7bb21e9f8ca2493cb4956fb4c
This updates the test to use a multiple of the default process count rather
than hardcoding 8.
--HG--
extra : rebase_source : 2aa15de90a58e38e480aca5e10f0b680820ecb2c
Changed the validation function for PageInfo to use a more general validateItemProperties.
This changes the error message being thrown. Changed the respective test cases to accomodate the change.
Differential Revision: https://phabricator.services.mozilla.com/D5831
--HG--
extra : moz-landing-system : lando
mkaply for overall search engine api changes
adw for searchservice changes. note that a small part of it will be removed in favor of the fix from bug 1485508
aswan for webextension side. note that I want to do better with the distribution signal, that can be in bug 1488517
Differential Revision: https://phabricator.services.mozilla.com/D4473
--HG--
extra : moz-landing-system : lando
- Support viewTypes property in menus.create / menus.update.
- Add info.viewType to menus.onShown / menus.onClicked event.
- This "viewType" reuses the existing extension.ViewType enum,
which is a "tab", "popup" (pageAction/browserAction) or "sidebar".
Differential Revision: https://phabricator.services.mozilla.com/D6205
--HG--
extra : moz-landing-system : lando
Stop checking whether `browser.menus.overrideContext` is called during
a `contextmenu` event, because the implementation cannot rely on
`window.event` due to bug 1493869.
Because of the removed check, `overrideContext` does not throw any more
when called outside of a "contextmenu" event. An extra check was added
to make sure that this does not impact menus of non-extension documents.
The new implementation has the following other effects:
- overrideContext can be called from shadow DOM (+tests).
- overrideContext can be called for context menu in a different
(same-origin) document (e.g. a menu in a blank child frame).
Differential Revision: https://phabricator.services.mozilla.com/D7249
--HG--
extra : moz-landing-system : lando
The new permission is added to make it easier to audit the usage of the
API. It is an optional permission, in case we ever decide to introduce
a permission warning for it.
Differential Revision: https://phabricator.services.mozilla.com/D6771
--HG--
extra : moz-landing-system : lando
This refactor is mainly meant to support bug 1367160, but it also eases
the implementation of bug 1294429, bug 1325758 or bug 1370735 if we ever
decide to fix those bugs.
Previously, the menu was constructed by creating one root menu item
and moving the submenu to the root if there was only one item.
The refactored code constructs the menu items by generating a list of
(potentially more than one) top-level menu items, and moving excess menu
items to a submenu (as before). Besides the ability to support an
arbitrary number of top-level menu items, this new implementation also
makes it easier to insert menu items and optionally separators at
arbitrary locations in the menu.
The refactored code obsoletes some separate code paths for browserAction
and pageAction menus, which improves the maintainability of the code.
There are two user-visible functional changes in this commit:
- Excess action menu items (more than ACTION_MENU_TOP_LEVEL_LIMIT = 6)
are not silently discarded, but shown in a submenu. See updated test.
- menus.onShown/onHidden are now always fired when the action menu is
shown, even if the extension has not created any action menu items.
Differential Revision: https://phabricator.services.mozilla.com/D6621
--HG--
extra : moz-landing-system : lando
