This does _not_ convert .disabled selectors on non-<form> elements such as
panel-list-items since presumably in such cases the 'disabled' class is being
used to grey-out a whole chunk of content.
For form elements, however, authors shouldn't be greying out elements with the
'disabled' class without also actually making the form element itself disabled
(e.g. with the disabled attribute).
Differential Revision: https://phabricator.services.mozilla.com/D3856
--HG--
extra : moz-landing-system : lando
Changes to browser.search.search API:
- Change the positional parameters to an object parameter.
- Rename "engineName" to "engine", and make this an optional parameter.
- Rename "searchTerms" to "query".
Changes to browser.search.search implementation:
- Simplify gBrowser getter. None of the "!gBrowser" conditionals are
necessary, as demonstrated by the new options page+sidebar tests
(which passed even after removing the `if (!gBrowser ...)` blocks).
Use windowTracker.topWindow for consistency with our other code.
Test changes:
- Remove unneeded name / "TEST_ID" in tests
- Use SEARCH_TERM constant in more places.
- New test: Using API from options page.
- New test: Using API from sidebar.
- New test: Using API without explicit "engine" parameter.
Differential Revision: https://phabricator.services.mozilla.com/D3417
--HG--
extra : moz-landing-system : lando
Everywhere else in this file we match on .disabled or :not(.disabled) but in two
instances we have :not(disabled). That's never going to match since it's already
combined with an `input` or `textarea` type selector (and there's no <disabled>
element).
Differential Revision: https://phabricator.services.mozilla.com/D3743
--HG--
extra : moz-landing-system : lando
This also fixes unintended behavior for which clicking the selected item in the sidebar selector would hide the sidebar.
Differential Revision: https://phabricator.services.mozilla.com/D3145
--HG--
extra : rebase_source : 891c99ab68f4689513801a1957a3d3846b7ffe58
The immediate goal is only to remove the broadcasters, so we still require the labels to be set manually on the "toolbarbutton" and "menuitem" elements. Generating these elements programmatically from the new SidebarUI.sidebars object, both for built-in sidebars and extensions, can be a future improvement.
The autoCheck attribute is also unnecessary since it is only intended for the menu items, and they are already properly updated after their command is invoked. Since the attribute was written with the wrong capitalization, it already had no effect.
The persistence of the label of the sidebar selector is also unnecessary since it is already set on startup. Removing this does not seem to cause any additional flickering.
Differential Revision: https://phabricator.services.mozilla.com/D3143
--HG--
extra : rebase_source : a5712b8e9bbdea29ab9e9a1bbd93217b24c354b4
From what I saw by reproducing it locally (e.g. I've also been able to trigger it locally pretty often on linux64 by using "./mach mochitest --verify"), the select popup may sometimes be still using part of its previous position while switching between the test case for the browserAction and the test case for the pageAction.
On linux64 this test was also (from time to time) sending the mouse event when the select element wasn't yet ready to be clicked in the extension popup.
This patch aims to make the behaviors of this test more stable by applying the following changes:
- disable the cosmeticAnimations while running these tests
- explicitly wait the select element in the popup (using ContentTask.spawn and ContentTaskUtils.waitForCondition) before sending it a mouse event
- explicilty close the select popup (and wait the select popup to be hidden) before proceeding to the next test case
The following push to try seems to confirm that these changes are helping to make the test more stable:
- https://treeherder.mozilla.org/#/jobs?repo=try&revision=086c526724ba409068d679036dd3ef13788535b6&selectedJob=194152144
Differential Revision: https://phabricator.services.mozilla.com/D3438
--HG--
extra : moz-landing-system : lando
Creating non-shared scopes for frame scripts is fairly expensive. After these
changes it's even more expensive. However, many frame scripts have no use for
the shared scopes at all. Run-once scripts which execute in closures, for
instance, make no use of them. And after bug 1472491, neither do most of our
default frame scripts.
MozReview-Commit-ID: 9PK7bYdQ0yh
--HG--
extra : rebase_source : db2516d2f00a75e233e1957649f2b62a9299b7cd
A lot of the ad-hoc frame scripts we execute for tests does not run in strict
mode, and therefore has its functions' `this` objects set to the global when
they are called without a target object.
At the moment, this gives them a MessageManager global. Once message managers
become non-global objects, however, it will give them the shared JSM global,
which is not what they expect.
This patches changes scripts which rely on this to explicitly capture or set
the appropriate `this` object for their calls.
MozReview-Commit-ID: DY8DDb0xE1K
--HG--
extra : rebase_source : 86c1fa4df070711f666dfee5487182afe28a7611
Basically it tests in which order various tab events are dispatched, so the old name
didn't make sense, and it will be more suited for a new test specific to onHighlighted.
MozReview-Commit-ID: Kj8GZfHA0Ap
--HG--
rename : browser/components/extensions/test/browser/browser_ext_tabs_onHighlighted.js => browser/components/extensions/test/browser/browser_ext_tabs_events_order.js
extra : rebase_source : 243155e897d08bd70091c6a7ee11b4671a098ef2
The tests are split in two files:
- browser_ext_menus_targetElement.js to test interaction with web pages
via content scripts.
- browser_ext_menus_targetElement_extension.js to test interaction
with menus in extension processes.
And browser_ext_menus_events.js was updated to recognize the new
property.
MozReview-Commit-ID: F0HEiNADRuM
--HG--
extra : rebase_source : 1f304c37a024ec94e2a8104bd7ae3d53eb68aa60
- 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 schema was inherited from Chromium (where it was an internal
implementation detail. This schema only defined the OnClickData
type, but was never actively used by our WebExtensions framework,
because menus.json already defines the OnClickData type.
Note: menus_internal.json specified the "menusInternal" namespace
which we do indeed implement in parent/ext-menus.js (and use in
child/ext-menus.js). However, none of the methods that we add to
menusInternal are actually defined in the schema.
This use of menusInternal was introduced in part 2 of bug 1333403 and
works without problems because the API schemas are not being used to
validate APIs as of part 2 of bug 1315575.
The only significance of "menusInternal" is that the namespace is
defined in browser/components/extensions/ext-browser.json,
implemented in browser/components/extensions/parent/ext-menus.js
and used by browser/components/extensions/child/ext-menus.js
MozReview-Commit-ID: 2ACpn595QZQ
--HG--
extra : rebase_source : f3e16486168dfb0baa56dda7ccf591855bbe90bb
