I can reproduce.
I will take a look thanks!

I think my patch caused the issue. This console message is displayed:
```
  if (!request.OriginDocument()->GetSecurityOrigin()->CanDisplay(url)) {
    request.OriginDocument()->AddConsoleMessage(ConsoleMessage::Create(
        kSecurityMessageSource, kErrorMessageLevel,
        "Not allowed to load local resource: " + url.ElidedString()));
    return false;
  }
```

FYI: video are inverted.

I am working on a fix.

FYI: fix is in review here:
https://chromium-review.googlesource.com/c/chromium/src/+/836607

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

commit ec09d1903c3cfadbaf6953afd1bc9d4280b54b44
Author: arthursonzogni <arthursonzogni@chromium.org>
Date: Mon Jan 15 11:16:00 2018

Fix initiator for reload initiated by DevTools.

This CL fixes  issue 795694 . It was introduced by
https://chromium-review.googlesource.com/730729.

Why is this bug related to DevTools?
|
|  In LocalFrame::Reload, there are two path for reload:
|  1) The first is used by:
|     * window.location.reload()
|     * window.history.go(0)
|     * DOMPluginArray::refresh()
|
|     This path use the NavigationScheduler::ScheduleReload(). There is
|     no issue with it.
|
|  2) The second is used by:
|     * DevTools page.Reload
|     * window.internals.forceReload([...])
|
|     There is a bug here. It turns out that DevTools was one of the
|     only ways to use this path. Other than that, DevTools and this
|     regression are not really connected.

What is the issue with the second path and chrome://dino ?
|
|  When using the chrome://dino URL, there are 2 differents URL.
|   * chrome://dino is used in the omnibox and in the renderer
|     HistoryItem.
|   * chrome-error://chromewebdata/ is the renderer current document
|     URL.
|  The issue is that the wrong one was used as the initiator. Since
|  chrome://dino is a WebUI URL, the navigation was blocked.

This CL restores the reload behavior to what it was before
https://chromium-review.googlesource.com/730729. That is to say, the
FrameLoadRequest origin_document is always nullptr and the request's
initiator is the request's url (the right one this time).

A regression test is included to cover this particular path.

Bug:  795694 , 648608 , 625969 
Change-Id: I6064b1852b56aa301de0ad16e4ffbbc025e246f4
Reviewed-on: https://chromium-review.googlesource.com/836607
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529246}
[modify] https://crrev.com/ec09d1903c3cfadbaf6953afd1bc9d4280b54b44/content/browser/devtools/render_frame_devtools_agent_host_browsertest.cc
[modify] https://crrev.com/ec09d1903c3cfadbaf6953afd1bc9d4280b54b44/third_party/WebKit/Source/core/frame/LocalFrame.cpp
[modify] https://crrev.com/ec09d1903c3cfadbaf6953afd1bc9d4280b54b44/third_party/WebKit/Source/core/loader/FrameLoader.cpp
[modify] https://crrev.com/ec09d1903c3cfadbaf6953afd1bc9d4280b54b44/third_party/WebKit/Source/core/loader/NavigationScheduler.cpp