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
This pref was removed in bug 1387081, when the sidebar-button started to
be shown by default. I have also removed the end of the test that
removed the button, since these were attempts to restore the default
state. At the inception of the tests, the default state is to not show
the button, but now the button is to be shown by default.
Differential Revision: https://phabricator.services.mozilla.com/D2954
--HG--
extra : moz-landing-system : lando
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
Likely fixed by the patch for bug 1417052
Ran the test with --repeat=50 on Linux and did not observe any failures.
MozReview-Commit-ID: FuMo8jdgJCn
--HG--
extra : rebase_source : 2a296cc7817607d352bc56b5b200da81d3e26bf0
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 : source : 1070e943ab79f6c46fd6518bc3695b1bee3dfd48
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 : source : ef15c7fe957fd48be8a963ab16ddd5a172fe987d
This removes the requirement for browser-style checkboxes and radio buttons
to be followed by a label since the reason why this was originally done
no longer applies because bug 418833 made it possible for checkboxes and radio
buttons to handle styling themselves rather than requiring a label::before
element.
--HG--
extra : rebase_source : 61957bd667b509e8769b86de7f783472d801bb0f
This ensures that the check that was introduced by bug 1370499 still
continues to work even though it was refactored by the previous commit.
MozReview-Commit-ID: GdbIPA6vxIB
--HG--
extra : rebase_source : 9246a1d6855de45eca8de5ee806d3a3e5ab7f0be
Manually verified using the STR from
https://bugzilla.mozilla.org/show_bug.cgi?id=1417052#c47
I am not re-enabling the test by default because the same test file is
reported to have another intermittent (bug 1416103).
MozReview-Commit-ID: 1xsyjMMby1H
--HG--
extra : rebase_source : 67080c8d7d7d804bf66aa40b577486c68dcaeb4b
And re-enable the test_ext_all_apis.html test to ensure that new APIs
are only available by default if the contributor really intents to.
MozReview-Commit-ID: FWIKybrk0EE
--HG--
extra : rebase_source : 58c5bd98ddb59be74b9454995cbbd3edef6c45f9
The hard-coded wait exists to avoid a test failure caused by a
non-functional click event in an options browser. However, that
still does not get rid of the intermittent failure.
To really avoid the timing issue, check whether onclick was fired
after supposedly triggering a click, and if not, wait and retry.
MozReview-Commit-ID: 9eg6sz1s1e3
--HG--
extra : rebase_source : 8945f2597beb99e9c5d03c08bc054692960e6281
