Print useful information about the visible autocompletion results before
failing the test, for debugging.
Differential Revision: https://phabricator.services.mozilla.com/D4700
--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
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
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
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
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
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 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
Re-enable the test that was disabled in bug 1381305 and fix the
underlying issue that caused th intermittent failure in the first place.
MozReview-Commit-ID: BL9wS2fogaf
--HG--
extra : rebase_source : 685f43b2e47d80f71814385a5c8b94fd3000eac9
Re-enable the test that was disabled in bug 1381305 and fix the
underlying issue that caused th intermittent failure in the first place.
MozReview-Commit-ID: BL9wS2fogaf
--HG--
extra : rebase_source : 685f43b2e47d80f71814385a5c8b94fd3000eac9
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
Re-enable the test that was disabled in bug 1381305 and fix the
underlying issue that caused th intermittent failure in the first place.
MozReview-Commit-ID: BL9wS2fogaf
--HG--
extra : rebase_source : 685f43b2e47d80f71814385a5c8b94fd3000eac9
Use sendMessage/awaitMessage instead of notifyPass/awaitFinish in tests
where this is not the last completion callback.
Remove an unneeded browser.contextMenus.onClicked.addListener call.
MozReview-Commit-ID: Akpla9tiAlD
--HG--
extra : rebase_source : 483acb2fd27f06c163871fa61c660ed5c2f15050
browser.menus.create and browser.contextMenus.create are asynchronous
APIs. For compatibility reasons, they cannot return a promise (since
they already return an integer).
This modifies all tests that use either of these APIs, to ensure that
the test waits for the callback of the last menus/contextMenus.create
call before continuing with the test.
In some cases in browser_ext_menus.js I did not add any callbacks,
because there were other asynchronous API calls (browser.tabs API)
that already guaranteed that the test made a round-trip to the parent
process before continuing.
This fixes:
- Bug 1462862 (browser_ext_contextMenus_icons.js)
- Bug 1403429 (browser_ext_contextMenus_onclick.js)
- Bug 1321182 (browser_ext_contextMenus.js)
- Bug 1373234 (browser_ext_menus.js)
MozReview-Commit-ID: IZFUyIw8Tbl
--HG--
extra : rebase_source : 4f28acf0189b4b93808b13200cf966a04873bf78
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
So panels provided by extensions with IDs that contain words like "inspector"
don't break.
Include test in existing panel creation test.
MozReview-Commit-ID: JerMCaKRgkl
--HG--
extra : rebase_source : 56c0262597c4070c7e16b32ebf824ef1fdd1fd8d
So panels provided by extensions with IDs that contain words like "inspector"
don't break.
Include test in existing panel creation test.
MozReview-Commit-ID: JerMCaKRgkl
--HG--
extra : rebase_source : 59a884cb616e22e3c6062d19d223b5670cf17225
Also changes the tooltip on the home button to be independent of the URLs
it opens, per dolske.
Some tests explicitly set browser.startup.homepage, but only through
SpecialPowers.putPrefEnv. That's a good compromise, given the extra
functionality there.
MozReview-Commit-ID: FPLxzi3jQAP
--HG--
extra : rebase_source : c2b014f2fb1c78ce04859344bd1803ef48d5d68d
This allows keyboard shortcuts containing both "Ctrl" and "Alt" in the
manifest of webextensions (in the "commands" -> "suggested_key" key),
rather than just one of these modifiers. The equivalent combinations
on MacOS (any two of "Command", "Alt" and "MacCtrl") are also allowed.
Non-sensical combinations (such as "Ctrl+Command" or "Ctrl+Ctrl") are
forbidden.
MozReview-Commit-ID: 59tC2efLm5q
--HG--
extra : rebase_source : 5a9375116aab6b3c4abe96c4850e4ff857d93532
extra : intermediate-source : 507b35de0e93baccb54f83e8bce6cedfe9754dd9
extra : source : 115c5332fadc1d52940f8356f6273f0e9680657f
If discard is used immediately after creating a tab, restoring the tab
resulted in an unusable tab. This was due to the sessionstate not being
ready. This adds enough sessionstate to restore when this occurs.
MozReview-Commit-ID: 6PIc71BS8VU
--HG--
extra : rebase_source : 1bb9627eee561e9bf924e9eb2a34a5071cae3742
The thing that it's testing is being removed.
I couldn't think of something that I could replace the test with. Maybe once we have
bug 1457481 we can check in an actual ELF binary and check that we're dumping its
symbol table correctly.
MozReview-Commit-ID: 9AXUwqPrivl
--HG--
extra : rebase_source : 70f7bd07804552c59a0d1ab0a1b6b344f9e6d308
I think that the intermittent error in the bug may be caused by
a pending executeScript call that is somehow handled around the
shutdown of the extension.
To verify this hypothesis, the test now explicitly waits for the
result of the first executeScript call before executing the last
script that is responsible for test completion.
The test should explicitly be checking for the error anyway.
And clean up comments and add reference to bug 1435100 in an
existing comment.
MozReview-Commit-ID: 6gV30Z6zQc4
--HG--
extra : rebase_source : d2d2f20336390ef61fefe247b3d1ae8668da7067
- Previously, if a port is disconnected by the other end, then memory
would be leaked to `ProxyMessenger.ports` in ExtensionParent.jsm.
To fix this, the port descriptor is now saved separately, keyed by
port ID instead of message manager.
- Previously, when a message manager was disconnected (e.g. window
closed/tab crashed), the port is disconnected only if the port was
created from that page.
This patch adds bookkeeping to keep track of the message managers at
both the sender and receiver's side, so that the port is always
disconnected when the other side goes away.
- The new test browser_ext_port_disconnect_on_crash.js checks whether
the ports are disconnected as expected. Previously, the subtest
connect_from_tab_to_bg_and_crash_tab failed because of the previous
point.
- Although not as deterministic as the crash test, the new
browser_ext_port_disconnect_on_window_close.js reproduces the original
test failure and serves as a regression test for the bug.
- Previously, the data structure in ProxyMessenger.ports contained
the original `sender` and `recipient`. For the purpose of sending
port disconnection messages, these are not necessary and therefore
they have been removed.
- Fix incorrect JSDoc (type of portId is number, not string)
MozReview-Commit-ID: BoaKRVAUKuq
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
The old name no longer makes sense, since it no longer exports an spawn_task
symbol, and add_task is what we really care about.
MozReview-Commit-ID: IE7B8Czv8DH
--HG--
rename : testing/mochitest/tests/SimpleTest/SpawnTask.js => testing/mochitest/tests/SimpleTest/AddTask.js
extra : rebase_source : 03bca5aa69a7625a49b4455a6c96ce4c59de3a5a
Apparently BrowserTestUtils.removeTab(gBrowser.selectedTab) does not
close the ?discoTest tab, which causes the test to fail eventually.
See comment 6 of bug 1453163 for more details.
MozReview-Commit-ID: 3UgEaVW083i
--HG--
extra : rebase_source : b1d901a611c27a269fa8129f172cfdafb7f6d81c
This patch requests a bit longer test timeout for browser_ext_devtools_panel.js, similarly
to other tests that open/close the devtools toolbox multiple times, because it often
timeouts on linux32 debug builds after we added a couple more "toolbox open/close" cycles
to test Bug 1394750 changes (and also made the devtools theme API tests more readable
by splitting it from the test case that verifies the rest of the devtools panel API).
MozReview-Commit-ID: 3JRWobPRwr5
--HG--
extra : rebase_source : 352fd4870048afa789d10afd2dd05bad9daa87ef
Use a more specific entry point for the test than
"http://mochitest.test:8888" to make sure that the test is only started
once, when the test opens a tab with the entry point.
MozReview-Commit-ID: 7iAFREDuACu
--HG--
extra : rebase_source : 6ab46b1114dc824f29d0bf21ffa784cd14651447
Extension ports are automatically closed when the message manager of
the source is destroyed. When a tab is detached from a window, its
frameloader is moved to the new window and the original message
manager is destroyed.
Bug 1445537 started listening for SwapDocShells events, but that only
works for the first swap (e.g. detaching a tab once). To avoid early
disconnection of the port, we should continue to subscribe to
SwapDocShells events.
MozReview-Commit-ID: G2ZYAhNyHIL
--HG--
extra : rebase_source : 9f888482e63d2768adf3dbd1c484a483dc307b2b
Contexts for active extension views are kept in a Set on the owning extension.
That list is meant to be kept current, with views added and removed as they're
created and unloaded. A refactoring at some point in the past, though, changed
that so that we only cleaned up parent views at extension shutdown, not at
view shutdown.
MozReview-Commit-ID: FW8KHPOD9qc
--HG--
extra : rebase_source : fab255ba2fb5ee55be41c252c89930d38f6edbe8
extra : amend_source : 54863d79a1d571a7354aa15f74e2fc4448297777
If commands are used with the page action panel, they will toggle open or
closed. We need to keep a handle on our custom panel so we can close it.
MozReview-Commit-ID: JfxwlyK8g8g
--HG--
extra : rebase_source : 25b4fbe794040d6769fa498cee5fcad154e002f9
Now that WebExtensions run OOP in Windows by default, and we have no intention
of going back, there's no need to run an extra set of in-process tests for
them.
MozReview-Commit-ID: t8ryuuNFHe
--HG--
extra : amend_source : 90e006ca618206a943991b14cb11779baa7b8934
Calling into the Photon PageAction API to update a property is orders of
magnitude more expensive than the simple DOM-based updates we used previously.
To make matters worse, a lot of our caching was removed during the migration,
and the Photon API introduces a lot of duplicated work when selecting icons.
This patch caches the last known state for each property to avoid calling into
the Photon APIs to update each property more than necessary, and removes the
extraneous preferred icon size calculations that the Photon code already
duplicates.
MozReview-Commit-ID: LjPPxolmcd6
--HG--
extra : rebase_source : 70bce5b1460c93cc738999b1e167eb17a39259b1
The shims that this rule tests for no longer exist.
MozReview-Commit-ID: DMgP7Hczavc
--HG--
extra : rebase_source : 765ddd5c62c9449c07ed050e44d86a3bd5c0ae64
extra : amend_source : 627a7694ac07182200f876901ded7a34721cd228
Now we're loading the sizemode attribute earlier, doing this on load stops
working.
MozReview-Commit-ID: ToiJiYrvFw
--HG--
extra : rebase_source : 48ad80e5535ecc5f7c8c8297f417f797deddc017
extra : source : 80194b5bf0e7bbcccf727d2fec140e747ebd0949
extra : histedit_source : 2b7755fece2a564fc806369280559c8829d3d486
Ensure remoteWebProgress is initialized for remote browsers. Includes devtools fix from jryans.
MozReview-Commit-ID: Ce3TzwkNnyi
--HG--
extra : rebase_source : 0f2bcb96ef04f4eaee447180dc21400dca3bf410
Add filtering of urls, properties, window and tab id to onUpdated events to
help reduce the quantity of update events that are dispatched.
MozReview-Commit-ID: J8Rh9uEt1gW
--HG--
extra : rebase_source : df821e63a3029e9970f6174f8132f30003b77221
Regression from bug 1398713. Before that, we reloaded the entire webext-panel.xul if the
sidebar changed. This verifies we don't reload unecessarily as well as discards
the browser to force a runtime disconnect for the extension if it does change.
MozReview-Commit-ID: LuYxmj9mSb7
--HG--
extra : rebase_source : 9839d7b96195f2323328d1a37c3d946032bbb652
This test has been disabled because it was failing intermittently with a pretty high
frequency on the Windows platform, the reasons behind the failures have been fixed
in Bug 1435100.
MozReview-Commit-ID: FNJqocBcxnf
--HG--
extra : rebase_source : f5fd1392bc53f137c8e48e433fddd103af74eaad
We need a static disable event so we can handle shutdown
of extensions using hidden tabs. This allows us to handle
shutdown when the extension has not yet used the API (thus
the ext-tabs api has not loaded).
MozReview-Commit-ID: BxV5PmbHJ8o
--HG--
extra : rebase_source : 78dd8b6e6b6ee1b09d446545dc8b38e32d7e9969
