Skip to content
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.

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

test: use Worker scope in WPT #24410

Closed
wants to merge 1 commit into from

Conversation

joyeecheung
Copy link
Member

@joyeecheung joyeecheung commented Nov 17, 2018

test: use Worker scope in WPT

Previously, we use the Window scope by default in our WPT test
runner. When one of the test fails, the WPT harness would try to
use document.getElementsByTagName() etc. to display the failure,
which is not going to work for us.

This patch switches the scope to DedicatedWorker and use our
Worker implementation as a global - this does not test the Worker
implementation per se, just tells the WPT harness to pass the results
back to us via the callbacks we installed and not try to access
a document.

We may still need to use a Window scope when we try to run
.window.js tests in the future, but for now we only run .any.js
tests so it's fine to use a worker scope by default.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the test Issues and PRs related to the tests. label Nov 17, 2018
Previously, we use the Window scope by default in our WPT test
runner. When one of the test fails, the WPT harness would try to
use document.getElementsByTagName() etc. to display the failure,
which is not going to work for us.

This patch switches the scope to DedicatedWorker and use our
Worker implementation as a global - this does not test the Worker
implementation per se, just tells the WPT harness to pass the results
back to us via the callbacks we installed and not try to access
a document.

We may still need to use a Window scope when we try to run
.window.js tests in the future, but for now we only run .any.js
tests so it's fine to use a worker scope by default.
@joyeecheung
Copy link
Member Author

@Trott
Copy link
Member

Trott commented Nov 20, 2018

@Trott
Copy link
Member

Trott commented Nov 20, 2018

Landed in 2742f38

@Trott Trott closed this Nov 20, 2018
Trott pushed a commit to Trott/io.js that referenced this pull request Nov 20, 2018
Previously, we use the Window scope by default in our WPT test
runner. When one of the test fails, the WPT harness would try to
use document.getElementsByTagName() etc. to display the failure,
which is not going to work for us.

This patch switches the scope to DedicatedWorker and use our
Worker implementation as a global - this does not test the Worker
implementation per se, just tells the WPT harness to pass the results
back to us via the callbacks we installed and not try to access
a document.

We may still need to use a Window scope when we try to run
.window.js tests in the future, but for now we only run .any.js
tests so it's fine to use a worker scope by default.

PR-URL: nodejs#24410
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
targos pushed a commit that referenced this pull request Nov 21, 2018
Previously, we use the Window scope by default in our WPT test
runner. When one of the test fails, the WPT harness would try to
use document.getElementsByTagName() etc. to display the failure,
which is not going to work for us.

This patch switches the scope to DedicatedWorker and use our
Worker implementation as a global - this does not test the Worker
implementation per se, just tells the WPT harness to pass the results
back to us via the callbacks we installed and not try to access
a document.

We may still need to use a Window scope when we try to run
.window.js tests in the future, but for now we only run .any.js
tests so it's fine to use a worker scope by default.

PR-URL: #24410
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
rvagg pushed a commit that referenced this pull request Nov 28, 2018
Previously, we use the Window scope by default in our WPT test
runner. When one of the test fails, the WPT harness would try to
use document.getElementsByTagName() etc. to display the failure,
which is not going to work for us.

This patch switches the scope to DedicatedWorker and use our
Worker implementation as a global - this does not test the Worker
implementation per se, just tells the WPT harness to pass the results
back to us via the callbacks we installed and not try to access
a document.

We may still need to use a Window scope when we try to run
.window.js tests in the future, but for now we only run .any.js
tests so it's fine to use a worker scope by default.

PR-URL: #24410
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@BridgeAR BridgeAR mentioned this pull request Dec 5, 2018
4 tasks
refack pushed a commit to refack/node that referenced this pull request Jan 14, 2019
Previously, we use the Window scope by default in our WPT test
runner. When one of the test fails, the WPT harness would try to
use document.getElementsByTagName() etc. to display the failure,
which is not going to work for us.

This patch switches the scope to DedicatedWorker and use our
Worker implementation as a global - this does not test the Worker
implementation per se, just tells the WPT harness to pass the results
back to us via the callbacks we installed and not try to access
a document.

We may still need to use a Window scope when we try to run
.window.js tests in the future, but for now we only run .any.js
tests so it's fine to use a worker scope by default.

PR-URL: nodejs#24410
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@BethGriggs
Copy link
Member

This change does not land cleanly on v10.x-staging. I've added the backport-requested-v10.x label, but feel free to swap to dont-land-on- if this change shouldn't land on v10.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants