RFC 212: Introduce require_webdriver_bidi metadata tag

[sadym-chromium]

Preview

[jgraham]

In principle I think this seems like a reasonable approach to the problem of opting in to BiDi and has the short-term benefit that implementations without BiDi support can simply skip the tests that require it.

[jgraham]

The BiDi testdriver APIs could enforce a check that they are only being called by a test with this flag set, perhaps? At least when they're called from a top-level test. I don't think documentation alone will be enough here.

[jgraham]

A different alternative here would be to make testdriver.js have a features query parameter that it could check before enabling the features, and which could be supported in the manifest to extract the required features. So the author would need to write <script src="/resources/testdriver.js?features=bidi"></script>, and that would be used both by the js code to decide whether to enable the feature, and also the manifest code to set the flag on the test. The problem would be cases where you include testdriver in a support file but not in the top-level test.

[sadym-chromium]

To clarify: do you think it worse mentioning as an alternative, or you insist we should implement this way instead?

[jgraham]

I thought of it when reviewing, and I think it's worth discussing here :)

The fact that it doesn't really work for tests that are using testdriver outside the test document seems like a notable downside because you'd still need some mechanism e.g. the meta tag in the test document. But it does naturally fail closed in the sense that if you don't specify the feature you can't use it, which is a notable advantage.

[sadym-chromium]

I don't think think this approach would allow adding or not adding bidi in the test_driver object. So in fact in both cases of testdriver.js?features=bidi and testdriver.js, the bidi will be in the test_driver object. However, it's up to the backend to restrict the bidi calls if "bidi" parameter is not set. Please confirm I understood your proposal correctly, and if so, I think it makes sense and I will re-write the proposal accordingly.

[sadym-chromium]

UPD: actually, testdriver can use document.currentScript.src to get it's query parameters, and enable/disable BiDi based on this.

[sadym-chromium]

https://github.com/sadym-chromium/wpt_rfcs/blob/sadym/require_webdriver_bidi/rfcs/require_webdriver_bidi.md#add-feature-query-parameter-to-testdriverjs

[mathiasbynens]

UPD: actually, testdriver can use document.currentScript.src to get it's query parameters, and enable/disable BiDi based on this.

Note that this doesn’t work in <script type=module>. Is that a use case testdriver needs/wants to support?

[sadym-chromium]

I started drafting this alternative in the #214

[OrKoN]

Note that this doesn’t work in <script type=module>. Is that a use case testdriver needs/wants to support?

I think testdriver.is currently not a module but import.meta.url could be used if it becomes a module.