[jam]:  One of the issues I mentioned.
[atwilson]:  Possible duplicate of  issue 876600 ?

this is not a duplicate of issue https://bugs.chromium.org/p/chromium/issues/detail?id=876600 as that issue talks about blacklisting of extensions and here we are talking about urlBlacklisting.

Basically, clicking on things on that page is not actually doing a navigation (no URLs are being fetched). Instead, javascript is just modifying the DOM then pushing URLs on the history stack. URLBlacklist cannot usefully do anything in that case because we can't stop Javascript from modifying the DOM.

But the URLBlacklist policy says so. If you are pushing the url on stack and updating it in navigation bar than we should also check if this url was blacklisted.

Getting pedantic for a minute:

The URLBlacklist policy says "This policy prevents the user from loading web pages from blacklisted URLs" - in this case, we are not loading web pages. In fact, hitting refresh in the browser should trigger URLBlacklisting because in that case we are actually loading a web page. URLBlacklist policy documentation does *not* state that it blocks modifying the URL history via Javascript.

Additionally, policy documentation states: "Note that it is not recommended to block internal 'chrome://*' URLs since this may lead to unexpected errors."

Again, the appropriate way to handle this use case would be via a policy to make some parts of the settings page inaccessible. The fact that clicking on "Passwords" in settings currently navigates to chrome://settings/passwords is not a binding public API - it is an implementation detail and is subject to change. This really should be driven through a dedicated policy.

In any case, I think your feature request to have URLBlacklist also restrict which URLs can be pushed on the history stack is reasonable - please bring it up on crbug.com/731104 so it can be prioritized along with the other policy-restricted-settings request.