Inline javascript might be executed first time page is loaded

[gorhill]

Test case:
http://acid3.acidtests.org/

This is probably due to the fact that chrome.contentSettings.javascript.set() is asynchronous, which means the preventing of inline javascript is not guaranteed to take effect before the page is processed/executed by the browser.

Until there is a fix (chromium developers might need to come up with something):

[Edit 2014-05-26: Some people are still using this entry as a reference. Since issue #35 has been fixed, the "workaround" below is no longer needed, it is has been rendered irrelevant with the fix.]

Workaround:

- Go to chrome/chromium "Settings".
- You might need to click "Show advanced settings".
- In "Privacy" section, click "Content settings..." button.
- In the "Javascript" section, click "Do not allow any site to run JavaScript".

HTTP Switchboard will continue to take care to enable javascript for whitelisted site.

[gorhill]

No, this needs to be studied more. Above workaround is best solution for now.

[gorhill]

There is an unfortunate side-effect of using "Do not allow any site to run JavaScript": When a main_frame is blocked (this happens for blacklisted hostnames), the page won't reload when unblocking it, this happens because the embedded replacement main_frame (encoded as a data URI) uses javascript to reload the page which has been unblocked. So far, it appears it is not possible to allow javascript for data URI... Sigh...

EDIT 2013-11-09: This one particular issue was resolved in v0.5.0 (using a different way to reload formerly blacklisted page)

[gorhill]

A side effect of the workaround, and for the same reason that contentSettings.javascript.set() is asynchronous, a web page might have its inline script blocked the first time the page is loaded. A refresh of the page allows the script to be properly executed.

[gorhill]

A bug has been formally submitted in chromium bug db: https://code.google.com/p/chromium/issues/detail?id=320300

[gorhill]

If javascript is disabled by default, one solution could be to generate the exceptions for all whitelist rules with an explicit hostname when the extension is first executed -- there can't be that many hostname/script or hostname/* for one user I suppose... Still feel a hack, but in the meantime (if even chromium address the issue), that would be better than nothing.

[hrj]

👍 Nice to see your detailed analysis. Hoping for an update from Chromium devs.

[gorhill]

Found a fix, so far it's working well. Will test more. Side-effect of the fix: blocked javascript won't be shown as blocked by chromium/chrome in the omnibar... Is it a big deal?