Closed Bug 1724183 Opened 1 year ago Closed 10 months ago

Add to test API WebIDL bindings implementations for the remaining assertion methods


(WebExtensions :: General, task, P1)



(firefox95 fixed)

95 Branch
Tracking Status
firefox95 --- fixed


(Reporter: rpl, Assigned: rpl)


(Blocks 1 open bug)


(Whiteboard: [mv3-m2])


(4 files)

In Bug 1724026 we are working on allow us to cherry-pick existing WebExtensions API tests and make them run on both the manifest v2 background page and manifest v3 background service worker, possibly with no or minimal changes to the test cases.

As part of Bug 1688040 we will be introducing a good chunk of the browser.test API, which is a test-only API that is used in almost all the WebExtensions test to coordinate the test scenario and run assertions from the extension code, most of the test API can use the existing stub methods (introduced in Bug 1682632) and just let the existing underlying implementation of the test API (toolkit/components/extensions/child/ext-test.js) to handle the API call, but there are 3 that needs to be implemented in the owner thread (the worker thread) because they are expected to accept parameters that can't be structured cloned:

  • browser.test.assertEq
  • browser.test.assertThrows
  • browser.test.assertRejects

This issue goal is to add the implementation for these 3 methods.

A separate follow up will be filed to add an implementation for browser.test.withHandlingUserInput (which also needs to be special cased, but it is used in a way smaller number of tests).

This patch introduce a new method to ExtensionTest.h/.cpp that implements the parts of
browser.test.assertEq that needs to happen on the background service worker thread
(because the first two parameters are expected to not be always of types that can be structure cloned).

The C++ method is meant to follow closely enough what the current implementation is doing
in privileged JS code (See
after that the C++ method calls the existing assertEq implementation, which will be actually be getting
the first 2 parameters already converted as strings (which will be already different if expected and
actual js values were different despite their stringified value may be looking the same, because the
method will add " (different)" to the stringified actual value if the two parameter were not strictly

The existing test.assertEq implementation will also take care to send the result of the assertion
to the parent process (which will make sure that the test case being executed will fail as expected),
as it happens for all other test API methods that are just forwarding their parameters to the
main thread through the pre-existing stub methods.

Depends on D107555

This patch introduce a new AssertMatchInternal to ExtensionTest, this method isn't exposed to
js callers through the webidl definition, it is meant to be used internally by the
AssertThrows and AssertRejects methods (which are instead both methods part of the ExtensionTest

This patch also introduces small changes to ExtensionAPIRequestForwarder and RequestWorkerRunnable,
to allow AssertMatchInternal to accept as an optional parameter a serialized caller stack trace
(to be sent as part of the APIRequest forwarded from the worker thread to the main thread),
which is needed for AssertRejects (to include the strack trace retrieved when AssertRejects is
called, and then after the promise parameter has been rejected or resolved to send it as part
of the forwarded aPI request).

Depends on D121890

See Also: → 1731094
Pushed by
Add test.assertEq WebExtensions API implementation to ExtensionTest webidl bindings. r=baku,mixedpuppy
Add ExtensionTest::AssertMatchInternal to provide the logic to be shared between AssertThrows and AssertRejects. r=baku,sfink
Add test.assertThrows WebExtensions API implementation to ExtensionTest webidl bindings. r=baku
Add test.assertRejects WebExtensions API implementation to ExtensionTest webidl bindings. r=baku
You need to log in before you can comment on or make changes to this bug.