onkeypress in "Enter here to filter..." needs script-src 'unsafe-inline' in Content-Security-Policy

[KalleOlaviNiemitalo]

Operation System: Windows

DocFX Version Used: 2.41

Template used: default

Steps to Reproduce:

1. docfx init
2. Answer "No" to the first question "Does the website contain API documentation from source code?"
3. Accept defaults to all other questions.
4. docfx build docfx_project\docfx.json
5. Copy docfx_project\_site to IIS7 and serve with the following web.config:

   <?xml version="1.0" encoding="UTF-8"?>
   <configuration>
      <system.webServer>
          <httpProtocol>
              <customHeaders>
                  <add name="Content-Security-Policy" value="script-src 'self'" />
              </customHeaders>
          </httpProtocol>
      </system.webServer>
   </configuration>

6. Start Firefox 60.7.0esr (64-bit).
7. Select Tools ⇒ Web Developer ⇒ Web Console (Ctrl+Shift+K).
8. Browse to …/articles/intro.html over HTTPS.
9. Select the "Enter here to filter…" text box in the navigation bar.
10. Type "intro".
11. Press the Enter key.

Expected Behavior:

Pressing the Enter key has no effect. No warnings about scripts appear.

Actual Behavior:

Pressing the Enter key reloads the page and clears the text box. The following warning appears in the Web Console:

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: onkeypress attribute on INPUT element. intro.html

Notes:

If you add 'unsafe-inline' to the script-src directive, then it works as expected. However, this onkeypress seems to be the only inline script in HTML generated from the default template, so it would be nicer not to require the unsafe mode.

The problem is in this line. Making it not require script-src 'unsafe-inline' would presumably require deleting the onkeypress attribute and instead having a script in a *.js file look up the element by id="toc_filter_input" and attach the event handler.

The inline script cannot be whitelisted by using script-src 'sha256-tUJzElOLFIo61uslF1ywDNIvP1YF9Cv48VcSoc9RvnI=' because the hash-source expression matches only elements, not attributes. Chromium may support script-src 'unsafe-hashed-attributes' to enable that, but Firefox 60 does not (Bug 1343950). CSP3 defines 'unsafe-hashes' for a similar purpose but [recommends against it](https://w3c.github.io/webappsec-csp/#unsafe-hashes-usage "8.3. Usage of \"'unsafe-hashes'\". Content Security Policy Level 3. Editor’s Draft, 28 February 2019").

[KalleOlaviNiemitalo]

2412 applies to the same text box. If that one is implemented, I hope it will not make the Content-Security-Policy problem worse.