and pageActions.
Before this change, browserActions and pageActions did not trigger
onClick events when middle-clicked, and no information on the button or
any modifiers were passed in the onClick event. With this change, middle
clicking triggers an event, and a clickData object is passed in the
onClick event, with the button and a list of modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D41492
--HG--
extra : moz-landing-system : lando
and pageActions.
Before this change, browserActions and pageActions did not trigger
onClick events when middle-clicked, and no information on the button or
any modifiers were passed in the onClick event. With this change, middle
clicking triggers an event, and a clickData object is passed in the
onClick event, with the button and a list of modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D41492
--HG--
extra : moz-landing-system : lando
and pageActions.
Before this change, browserActions and pageActions did not trigger
onClick events when middle-clicked, and no information on the button or
any modifiers were passed in the onClick event. With this change, middle
clicking triggers an event, and a clickData object is passed in the
onClick event, with the button and a list of modifiers.
Differential Revision: https://phabricator.services.mozilla.com/D41492
--HG--
extra : moz-landing-system : lando
Checking extension.shutdownReason for any purpose other than detecting
app shutdown is unreliable, since actions such as disabing, uninstalling,
etc. may happen ito an extension after it has shut down. Remove the
temptation for api authors to write incorrect code by removing
extension.shutdownReason and replacing it with an isAppShutdown boolean
passed to shutdown handlers.
Differential Revision: https://phabricator.services.mozilla.com/D30605
--HG--
extra : rebase_source : 07ff7710757150d011fec6bc3ed134c6509e9a12
***
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
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
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
- 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
This allows extensions to include tab/bookmark menu items from other
extensions. Built-in menu items from the browser are *not* added.
Depends on D6623
Differential Revision: https://phabricator.services.mozilla.com/D6624
--HG--
extra : moz-landing-system : lando
The new method allows extensions to modify menu items in their own
moz-extension:-pages, with the following features:
- All matching extension items are shown in the root menu (instead of
being moved into a submenu), above other menu items, if any.
- The icons for these menu items are customizable.
- Optionally, the default menu items (including those from other
extensions) can be hidden.
Depends on D6621
Differential Revision: https://phabricator.services.mozilla.com/D6622
--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
- Add info.targetElementId to menus.onShown event.
- Add info.targetElementId to menus.onClicked event.
- Add menus.getTargetElement API that is available to all contexts,
including content scripts, which allows extensions to get the DOM
element for a given targetElementId.
- Add new schema instead of re-using schemas/menus.json to avoid sending
too much schema data (of the existing menus API) to content processes.
MozReview-Commit-ID: 6Onf7jZlIho
--HG--
extra : rebase_source : eb095d04ce381606be90d325712bfc57233d8291
This allows the JS to work in HTML documents, where whitespace is preserved. In XUL
documents, whitespace is ignored when parsing so text nodes are generally not returned.
The following changes were made, with manual cleanups as necessary (i.e. when firstChild actually
refers to a text node, or when firstChild is used in a loop to empty out an element):
firstChild->firstElementChild
lastChild->lastElementChild
nextSibling->nextElementSibling
previousSibling->previousElementSibling
childNodes->children
MozReview-Commit-ID: 95NQ8syBhYw
--HG--
extra : rebase_source : 186d805f7a2a56694dda9032aceac2dfe5424753
