The problem is that Chrome 61 and newer explicitly forbids access to the contents of its built-in new tab page (NTP) via content scripts or any other API.
The solution is to create the entire replacement page as an html file in your extension and specify it in chrome_url_overrides.
As for why, here's quoting [source] rdevlin, one of the developers of chrome extensions API:
There's a few reasons for this change. One is to enforce policy,
the other is for consistency.
- We've had a public policy for awhile now that states that modification of
the NTP through anything other than Chrome URL overrides isn't allowed (though
we didn't begin enforcing this policy in many cases until July 1st). This is
merely bringing chrome code more inline with that same policy to help prevent
surprise if an extension is modifying the NTP and is taken down for policy
violations.
- This is also for consistency, since we've actually treated scripts on the NTP
differently for years now, due to certain NTP magic. For example, the URL seen
by the browser on the NTP is chrome://newtab, but the url in the renderer is
https://www.google.com/_/chrome/newtab. Since chrome.tabs.executeScript checks
the URL in the browser, the script would be denied, even though content scripts
(checked in the renderer) would be allowed. In theory, these permissions should
not be different. Similarly odd, if the user is using the local ntp
(chrome-search://local-ntp/local-ntp.html), injection would already be
disallowed in both the renderer and the browser. And, if we go waaaaay back,
the NTP used to be pure WebUI with an URL of chrome://newtab, where injections
were again disallowed. Rather than have inconsistent behavior depending on the
type of script injection the extension uses, we want to have consistency
throughout the system.
P.S. Please don't edit the quoted text.