[WebDriver BiDi] respect "WebDriver BiDi scripting is enabled"

[sadym-chromium]

Based on #11441. The bare minimal required changes.

• Enable scripting disabled emulation via WebDriver BiDi. Required for WebDriver BiDi command emulation.setScriptingEnabled.
• Allow bypassDisabledScripting to force-run scripts. Required for some automation scenarios like WebDriver BiDi command script.evaluate.

The following nuances are kept untouched and should be addressed later on as a part of Based on #11441:

• The "get the current value of the event handler" and "event handler IDL attribute" will return null when the JS is disabled.
• "8.1.6.6.2 HostEnqueueFinalizationRegistryCleanupJob(finalizationRegistry)" will NOT run when the JS is disabled. Meaning the FinalizationRegistry will not work even for scripts created with bypassDisabledScripting
  flag.
• "8.1.6.6.4 HostEnqueuePromiseJob(job, realm)" will NOT run when the JS is disabled. Meaning the FinalizationRegistry will not work even for scripts created with bypassDisabledScripting
  flag.

---

• At least two implementers are interested (and none opposed):
  • Chromium
  • Mozilla
• Tests are written and can be reviewed and commented upon at:
  • [wdspec] test emulation.setScriptingEnabled web-platform-tests/wpt#54289
• Implementation bugs are filed:
  • Chromium: feat: implement emulation.setScriptingEnabled command GoogleChromeLabs/chromium-bidi#3566
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1982563
  • WebKit: N/A
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/infrastructure.html ( diff )
/webappapis.html ( diff )

[sadym-chromium]

@foolip @zcorpan WDYT if we split the original PR?

[foolip]

This makes sense to me, but review from @zcorpan would also be good too.

[zcorpan]

Is this subset something that can be shipped in implementations and still be useful?

[sadym-chromium]

Is this subset something that can be shipped in implementations and still be useful?

Yes:

1. It allows for user agents to disable JS via WebDriver BiDi.
2. It allows for WebDriver BiDi users to evaluate JS (with very limited capabilities) even if the JS is disabled.

The extending available JS capabilities to inline with actual implementations is discussed in #11874 and partly implemented in the original #11441.

[sadym-chromium]

@annevk I addressed your comments

[annevk]

Thanks, it seems that @zcorpan asked some questions in #11874 (comment) that probably need to be answered. I'll defer to him as to how to move this forward.

[sadym-chromium]

Thanks, it seems that @zcorpan asked some questions in #11874 (comment) that probably need to be answered. I'll defer to him as to how to move this forward.

This PR is a bare minimum to enable disabled JS emulation for WebDriver BiDi users and enable some scripting. Regardless of the discussions in #11874 outcome, this PR still seem to make sense.

[juliandescottes]

While I agree the PR makes sense as an incremental step, the current implementations of disabling script via remote protocols, in Chrome and Firefox, are rather aligned with #11441 .

So while it's fine to go ahead and merge this, we will need to decide relatively quickly if we are ultimately going to allow promises/weakmap finalization for BiDi evaluated script or if that seems too complicated to specify. Because if not, we will need to start modifying our implementations to match that, knowing that we probably can't break eg devtools' behavior for legacy reasons.

@sadym-chromium do you plan on enforcing the limitations related to this PR for Chrome or are you waiting until we get an agreement for #11441 to do any implementation changes?