Hi,

We have the same problem since the update. It is currently affecting hundreds of users..

Please fix this.

Just reported same bug.  Having identical issues as of latest Chrome.

Workaround: blacklist entries including protocol appear to be properly superseded by whitelist entries.

IE: Blacklist 'http://*', 'https://*', 'chrome://*', 'ftp://*', etc instead of just '*'.

Insecure due to probably not catching every possible protocol, but better than nothing.

WE're having the same problem. We have 1000's of customers this is affecting. Please fix promptly!

Blacklist 'file://*' as well

We're experiencing the same issue. To add to the comments however is that other whitelist overrides are working. So domain.com blocked works and then whitelisting subdomain.domain.com will allow subdomain so the problem is specific to the wildcard.

Same issue over here - we switched to the proposed workaround using proto://* while waiting for a fix.

atwilson@ do we have someone who can look at this as it seems to be affecting numerous enterprise customers.

- atwilson
+ blumberg

My apologies, should have looked at the OS :-/

blumberg@ can you assign a resource to look at this?

Trying a repro!

Hi,

We were able to reproduce on ChromeOS as well. It happens on version 60 and works fine on 59.

I am able to reproduce this issue on Latest Stable#60.0.3112.101 and not on M59#59.0.3071.115.

Working on a narrow bisect.

 Issue 755505  has been merged into this issue.

This shut down dozens of users. Please make this a priority!

Here is the change log: https://chromium.googlesource.com/chromium/src/+log/60.0.3109.0..60.0.3110.0?pretty=fuller&n=10000

estark@, can you please look into these changes (https://chromium.googlesource.com/chromium/src/+/0445935b1f4740e0e283c3fcd5fa7760e9d517b7, https://chromium.googlesource.com/chromium/src/+/80618c346d3f78823fe6061349319a98a867b6cf) if possible?

PS: Some reason 'URLWhitelist' didn't work w/ bisect.py, however 'URLBlacklist' does.

Thank you!

Correction: 

PS: Some reason this issue didn't repro with "bisect.py" (Though it's honoring registry entries: URLWhitelist/URLBlacklist).

 Issue 755541  has been merged into this issue.

At first glance, not sure how this could be affected by my changes, which just introduce an unrelated enterprise policy. Passing over to components/policy OWNERS.

Possibly PlzNavigate (that's on for 60, right?)

PlzNavigate is enabled at 100% on stable.

I have no idea if it's related since there are no repro instructions for me (i.e. not sure how the steps in the first comment can be applied locally).

For whoever has a repro, you can try running chrome with --disable-features=browser-side-navigation to see if it fixes it or not.

Not seeing this issue with "--disable-features=browser-side-navigation".

Repro Steps:
=============
1. Install latest stable chrome#60.0.3112.101
2. regedit -> Software\Policies\Google\Chrome\URLBlacklist\1 = "*" 
3. Software\Policies\Google\Chrome\URLWhitelist\2 = "google.com"
4. Try to launch chrome and access 'google.com'

Adding Navigation label for PlzNavigate.

 Issue 755665  has been merged into this issue.

removing m-60 label since PlzNavigate was rolled back on stable

Here's a fix: https://chromium-review.googlesource.com/c/616350

How to apply this fix ?

To fix the issue, just restarting the browser should work.

It seems to work, strange thing is the browser is still on .101 version how is this possible ?

We have a mechanism to push features that is separate from versions. In this case, the bug was caused by a new feature (navigation refactoring) that we pushed at a 100%. We scaled it back down when we realized there was an issue, which does not require releasing a new version of Chrome. Restarting the browser re-initializes the lists of features enabled, which turns off the problematic feature in this case.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/337a87dc2c9e67d0185d0058f7c466d5f1448d41

commit 337a87dc2c9e67d0185d0058f7c466d5f1448d41
Author: John Abd-El-Malek <jam@chromium.org>
Date: Wed Aug 16 15:06:02 2017

Fix URL blacklisting not working with PlzNavigate.

The problem was that the PlzNavigate blob url used to send data to the renderer was being incorrectly triggered. This was fixed for Android in r456824.

BUG= 755256 

Change-Id: I890e95a22580c33f4a478f2f99d76c04d0fdb22f
Reviewed-on: https://chromium-review.googlesource.com/616350
Reviewed-by: Bartosz Fabianowski <bartfab@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494784}
[modify] https://crrev.com/337a87dc2c9e67d0185d0058f7c466d5f1448d41/android_webview/browser/net/aw_network_delegate.cc
[modify] https://crrev.com/337a87dc2c9e67d0185d0058f7c466d5f1448d41/chrome/browser/policy/policy_browsertest.cc
[modify] https://crrev.com/337a87dc2c9e67d0185d0058f7c466d5f1448d41/components/policy/core/browser/url_blacklist_manager.cc

Issue 755297 has been merged into this issue.

Well, this is still broken for non-Enterprise browser users like us. Is there a json policy syntax workaround?

 Issue 756318  has been merged into this issue.

Can I get v59 or older in the meantime for Linux?

> We have a mechanism to push features that is separate from versions.

From which domains this features are distributed?

Verified this issue on Win7 & Win10 with chrome #62.0.3189.0 as per steps mentioned in the comment #0

Observed that url's which are mentioned in the URL white-list are able to access and remaining url's are not accessible.  Hence adding TE-Verified labels.

Attaching a screen-cast for reference.

Deleted: 755256.mp4 1.7 MB

	755256.mp4 1.7 MB View Download

 Issue 714957  has been merged into this issue.

 Issue 757032  has been merged into this issue.

Merge of c#36 approved for M61 branch 3163.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0fe737bc47e9467153b93ca83fcf8f02d1a17784

commit 0fe737bc47e9467153b93ca83fcf8f02d1a17784
Author: John Abd-El-Malek <jam@chromium.org>
Date: Fri Aug 18 23:41:55 2017

Fix URL blacklisting not working with PlzNavigate.

The problem was that the PlzNavigate blob url used to send data to the renderer was being incorrectly triggered. This was fixed for Android in r456824.

BUG= 755256 
TBR=jam@chromium.org

(cherry picked from commit 337a87dc2c9e67d0185d0058f7c466d5f1448d41)

Change-Id: I890e95a22580c33f4a478f2f99d76c04d0fdb22f
Reviewed-on: https://chromium-review.googlesource.com/616350
Reviewed-by: Bartosz Fabianowski <bartfab@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#494784}
Reviewed-on: https://chromium-review.googlesource.com/622279
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#687}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/0fe737bc47e9467153b93ca83fcf8f02d1a17784/android_webview/browser/net/aw_network_delegate.cc
[modify] https://crrev.com/0fe737bc47e9467153b93ca83fcf8f02d1a17784/chrome/browser/policy/policy_browsertest.cc
[modify] https://crrev.com/0fe737bc47e9467153b93ca83fcf8f02d1a17784/components/policy/core/browser/url_blacklist_manager.cc

 Issue 757438  has been merged into this issue.

Is there another case open for the Linux OS version still not working?

As verified in M61.0.3163.60:9765.37.0 beta reks peppy daisy candy, this issue is no longer reproduced.

#c50 was for ChromeOS. 
Re-Marking this back to Fixed status, 'cause this is pending verification on Chrome on non-ChromeOS platforms. 

This is till broken in linux after updating to 60.0.3112.113-1.  Per https://www.chromium.org/administrators/linux-quick-start I set up the most basic json policy file with the code:

{
  "HomepageLocation": "www.chromium.org"
}

The browser does not behave as expected.

@microsoft.will.crumble@gmail.com please file new bugs, and don't reuse this one. This bug is for url blacklist blocking, and that is fixed in m61 and the feature that broke it is disabled in 60.

Apologies, applied the wrong component in bulk.

Pending verification for Windows platform by Chrome team.