I'm able to repo this on Windows so I think it's at least an issue on desktop (haven't tried ChromeOS yet)

Assign to Georges as this is an old policy and the original owner has left Chrome already.

FYI, I tried this on 64.0.3274.0 (Linux) and it still reproduced, so not a recent regression (perhaps it has always been that way?).

dpapad@, could you pls try to repro this on M64 last stable version 64.0.3282.186?

I am not aware of an easy way to get latest M64 locally, but also don't think is necessary.

This is not working on some M64 version, or M65, or ToT (67.0.3371.0). If it had been fixed and merged into any of previous releases, should be already working on ToT.

Not considering this as M65 stable blocker per comments #3, #6 and per internal group chat. Thank you.

georgesak, my theory is this:

the policy code uses a navigation throttle to enforce what is blocked.
the first time this navigation throttle is called, it accesses a keyed service which holds the actual block list data structure.
it takes time to parse this block list.
the throttle doesn't wait very long before deciding that there isn't anything in the block list, and then allows the url to load

One approach to fix this is to have the PolicyBlacklistService know that url_blacklist_manager_ hasn't started and return DEFER in PolicyBlacklistNavigationThrottle::WillStartRequest until the url_blacklist_manager_  is ready.  When it is ready, you can call the appropriate method on the navigation throttle to continue that request.

Happy to discuss.

Issue 838943 has been merged into this issue.

I will take a stab at this one.