-
Notifications
You must be signed in to change notification settings - Fork 11
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
Remove assumptions about same-origin runtime. #32
Comments
theengineear
added a commit
that referenced
this issue
Jun 14, 2024
Previously, we looked for a “frameElement.id” property to determine if a document running tests was the “root” test runner or not. This was too naive as it assumes that integrators looking to iframe a test suite into a part of a parent application _won’t_ set an “id” property / attribute on that iframe. Instead, we now use a “data-*” attribute with a namespace: ``` data-x-test-test-id ``` See #32.
theengineear
added a commit
that referenced
this issue
Jun 14, 2024
Previously, we looked for a “frameElement.id” property to determine if a document running tests was the “root” test runner or not. This was too naive as it assumes that integrators looking to iframe a test suite into a part of a parent application _won’t_ set an “id” property / attribute on that iframe. Instead, we now use a “data-*” attribute with a namespace: ``` data-x-test-test-id ``` See #32.
theengineear
added a commit
that referenced
this issue
Jun 14, 2024
Previously, we looked for a “frameElement.id” property to determine if a document running tests was the “root” test runner or not. This was too naive as it assumes that integrators looking to iframe a test suite into a part of a parent application _won’t_ set an “id” property / attribute on that iframe. Instead, we now use a “data-*” attribute with a namespace: ``` data-x-test-test-id ``` See #32.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The general architecture for
x-test
usespostMessage
everywhere — which is perfectly fine for cross-origin environments. However, there are a couple assumptions that may need to be double-checked / changed.Here are a handful of things to check / change:
null
. That would shunt off how we pass information from parent to child for identifiers.One thing we might do is Demeter this thing and limit parent-child comms to single-use, private MessageChannel ports. It would essentially change from a common bus architecture to more like a forwarding pyramid architecture. It’d be worth investigating.
The text was updated successfully, but these errors were encountered: