All instances of nsIBrowserSearchService::currentEngine have been replaced by nsIBrowserSearchService::defaultEngine. Dropping this variable now.
Differential Revision: https://phabricator.services.mozilla.com/D12223
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
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
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
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
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
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
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
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
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
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
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
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
