Skip to content

Change test status race conditions in design of web_extensions.md #243

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
justinlulejian wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Change test status race conditions in design of web_extensions.md #243

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions rfcs/web_extensions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,10 +29,13 @@ Because these tests don’t leverage `testharness.js` directly, we introduce a n
`.extension.js`, that creates the necessary boilerplate to convert these messages into the
corresponding assertions in `testharness.js`.

It’s important to note that it isn’t guaranteed that the web page loads before the extension.
A race condition could occur that causes the `browser.test` assertion results not to be reported
back to the test harness if the `browser.test.onMessage` listener isn’t registered. To resolve
this, user agents queue the results until a listener is registered, then report them.
It is important to note that the web page driving the extension loading and tests will load before
the extension. We take advantage of this to ensure that test status listeners
(`browser.test.onTestStarted` and `browser.test.onTestFinished`) are registered before a test
starts. This avoids race conditions stemming from variations in how different browsers load
extensions and the speed at which tests execute. It also prevents the need for complex browser
logic to handle both scenarios (test status listeners registering before or after the tests start),
which will hopefully simplify each browser's implementation of this RFC.

Lastly, since the `Classic` and `BiDi` implementations support loading an extension using a
`path` or `archivePath` to the extension’s resources, the full path to the extension’s resources
Expand Down