The old chrome://history page will be removed when v56 is shipped anyway, I guess.

Using the per-revision bisect providing the bisect results,
Good build: 56.0.2896.0 (Revision: 426358).
Bad build: 56.0.2897.0 (Revision: 426673).

You are probably looking for a change made after 426482 (known good), but no later than 426483 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/f8003d49d2e17ffa67c566001d8ca454c2d80e79..e7250ebe260957a67131667cdde6b7b838a9b1f5

@lukasza -- Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.
Thank You.

This bug does seem potentially related to r426483.  OTOH, that CL should only affect navigations where a target frame is present - AFAICT this is not the case for chrome://history entries:

    <a id="title" class="website-title" title="..." href="..." focus-type="title" tabindex="0">...</a>

Also - so far I have trouble reproing the bug anywhere (I've tried Linux, Windows, Mac with PC mouse) despite watching and trying to pay close attention to the repro videos (which are usually really helpful - thanks for attaching them).

Oh, I think that the difference is that I have a different version of the chrome://history page (see the attached video).

How would I trigger the old history page?  Is it a matter of passing some command line flags or forcing a particular experiment?

If (as #c1 says) the old chrome://history page will be removed in M56, then should the current bug be resolved as WontFix?

Adding RB label as this is a recent regression.

We can see the old chrome://history page by disabling "Enable Material Design History" in chrome://flags

Thanks - I can repro with 

When trying to Ctrl-click youtube.com in chrome://history, I see the following error:
[120941:120941:1025/112730:ERROR:CONSOLE(0)] "Refused to frame 'https://www.youtube.com/' because it violates the following Content Security Policy directive: "child-src chrome:".
", source: chrome://chrome/history/ (0)

In #c9 I meant to say: I can repro with --disable-features=MaterialDesignHistory command line flag.

Structure of the old history page (relevant to this bug) looks more or less like this:

<iframe src="chrome://history-frame/"></iframe>

The iframe contains:
<a href="https://www.youtube.com" target="_top">YouTube</a>

I am not yet sure where the child-src child policy comes from, but I'll ignore it for now and just work on a browser test with a generic repro.

lukasza@: the new Material Design version is being targeted for M55 for most users, however supervised users (or those otherwise using grouped history, should be rare) will still be getting the old history page.

from the CLI (in addition to what tkonchada@ said):
--{en,dis}able-features=MaterialDesignHistory
--enable-grouped-history
also work.

A fix proposal that avoids frame-src CSP checks for shift-clicks is going through initial testing @ https://crrev.com/2453093003

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

commit d7e5f244d54d0a0c8615e4ff216f906851e9fb64
Author: lukasza <lukasza@chromium.org>
Date: Thu Oct 27 17:35:27 2016

child-src and frame-src CSP are not applicable when navigating a new window.

Shift-clicking an anchor/link will open the link in a new window
(similarily ctrl-clicking or middle-clicking will open the link
in a new background tab).  In this scenario child-src and frame-src
Content Security Policies of the parent frame are not applicable
(because we are not navigating the frame containing the anchor,
but instead we are navigating a brand new frame in a new window).

BUG= 658701 

Review-Url: https://codereview.chromium.org/2453093003
Cr-Commit-Position: refs/heads/master@{#428069}

[modify] https://crrev.com/d7e5f244d54d0a0c8615e4ff216f906851e9fb64/third_party/WebKit/LayoutTests/http/tests/navigation/post-with-modifier.html
[add] https://crrev.com/d7e5f244d54d0a0c8615e4ff216f906851e9fb64/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/frame-src-vs-shift-click.html
[add] https://crrev.com/d7e5f244d54d0a0c8615e4ff216f906851e9fb64/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/resources/frame-src-vs-shift-click-target.html
[modify] https://crrev.com/d7e5f244d54d0a0c8615e4ff216f906851e9fb64/third_party/WebKit/Source/core/loader/FrameLoader.cpp

The fix from #c16 was first released in 56.0.2903.0

I've verified in a Windows Canary with this version that both the new and the old history work fine (wrt shift-clicks and middle-clicks).

Thank you for reporting this issue.