A note on the screencast:

- first attempt:
  I was tried to open `filesystem:chrome-extension://...` file by copy-pasting URL
- second attempt:
  I opened the same file using `Go to ...` from context menu

As per comment #0 we have tested this issue on reported chrome version 67.0.3396.87  using Windows 10.Attaching screen-cast for reference.

Steps:
--------
1. Launched chrome
2. Opened new tab and tried to load sample extension by using given URL ""filesystem:chrome-extension://${extensionId}/temporary/""
We are unable to load extension and getting blocked page  

@Reporter: As we are unable to reproduce the issue from our end. Could you please review the attached screen-cast and confirm if anything being missed here and if possible provide ""sample extension with storage permission"".

Thanks! 

Deleted: 854107.mp4 1.7 MB

	854107.mp4 1.7 MB View Download

I'll provide a test extension for you to reproduce the problem clearly. Please give me couple of hours

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please, install this demo extension, click on browser action icon and follow demopage instructions

Deleted: 854107-demo.crx.tgz 1.1 KB

854107-demo.crx.tgz 1.1 KB Download

I made a screencast with demo extension working

Deleted: Screencast 2018-06-29.mp4 4.3 MB

	Screencast 2018-06-29.mp4 4.3 MB View Download

Same behavior in Chrome 67.0.3396.99

Able to reproduce the issue on reported chrome version 67.0.3396.87 and latest stable 67.0.3396.99  also on latest chrome 69.0.3486.0 using Mac 10.13.5, Ubuntu 17.10 and Windows 10.  

Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.

Thanks!

creis@ and alexmos@: This seems to be a bug. Any explanation for these two different behaviors?

Not sure what's going on-- probably some incomplete checks trying to prevent navigations to filesystem URLs.  Nick, Alex, or Devlin might know more.

Note that the link itself also doesn't work in Chrome 69.0.3494.0, with the following error message on the console:
Not allowed to navigate top frame to filesystem URL: filesystem:chrome-extension://hengafgjonojneebkccklffnkejaleih/temporary/sample.txt

The link works in that version if you choose "Open link in new tab/window," but not if you middle or shift click it.  The link does work in 67.0.3396.99.

I'm wondering if this is intentional and the "Open link in new tab/window" is the case that should be fixed, or if some other security checks are unnecessarily blocking it in these cases.  That's beyond my understanding of what we allow and don't allow for extension filesystem URLs, though.

Hopefully Devlin or Nick can comment more on what's expected.

Investigating more... will report back shortly.

So, this is an interesting set of cases.

As of revision 5440020025c6e2de35db1bd5450bce9b69406e31 in m68, we no longer allow renderer-initiated navigations to filesystem URLs.  (See also  issue 811558  and the intent to deprecate announcement at https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X7rZeU93vjw)  +meacer@, who's running that effort.

This causes the navigation to be blocked by either the frame loader [1] or the BlockedSchemeNavigationThrottle [2].

These explain why left clicking, middle clicking, shift clicking, etc all fail in m68.

This leaves browser-initiated navigations, such as any through the context menu or the omnibox.  The context menu (right click -> "Open link in new tab") works.  Entering the address into the omnibox *on a non-extension tab* (e.g. via right click -> "Copy link address" -> omnibox "Paste and go") does not.  Entering into the omnibox on an extension tab works.  This is because of the check in ExtensionNavigationThrottle here [3], originally added in revision 419c0f16840f7c9cf0cd600da55c4db4bd30c58d, which moved it from the chrome_extensions_network_delegate, which was originally added in revision 4bfdc9292a6161980ba9a7a469d2d4515bebc6dd.  The current check is:


  const GURL& url = navigation_handle()->GetURL();
  bool url_has_extension_scheme = url.SchemeIs(kExtensionScheme);

  ...

  if (!url_has_extension_scheme && !current_frame_is_extension_process) {
    // Relax this restriction for apps that use <webview>.  See
    // https://crbug.com/652077.
    bool has_webview_permission =
        target_extension->permissions_data()->HasAPIPermission(
            APIPermission::kWebView);
    if (!has_webview_permission)
      return content::NavigationThrottle::CANCEL;
  }

A new tab is neither in an extension process, and the URL doesn't have the extension scheme (it has a filesystem scheme).  Since it's not a webview, we cancel the navigation.

So, now the question is "what is desired behavior".

Renderer-initiated:
Personally, I'd like to treat extensions similarly to the web for these checks, which would mean that renderer navigations will continue to fail.  meacer@, do you have an opinion here?  (And relatedly, is there a canonical workaround for web pages that would do this?)

Browser-initiated:
It seems like these should work.  Charlie, Alex, Nick: the check is failing because it's not an extension process, which was originally important for security checks.  Is this still the case today, with site isolation?  Shouldn't any frame navigation to an extension origin cause a process transfer, thus being safe?  It seems very broken that an omnibox-initiated navigation will succeed or fail based on the origin the tab's main frame is currently at...

[1] https://chromium.googlesource.com/chromium/src/+/f89eee15e0436ee81c92adca23eda30bac6fe325/third_party/blink/renderer/core/loader/frame_loader.cc#695
[2] https://chromium.googlesource.com/chromium/src/+/59319e0493d1aa2723310b7f6d3620de97033cc1/content/browser/frame_host/blocked_scheme_navigation_throttle.cc#63
[3] https://chromium.googlesource.com/chromium/src/+/ebdf192babb3aa96113917e119310e9643fd80ae/extensions/browser/extension_navigation_throttle.cc#87

> Renderer-initiated:
Personally, I'd like to treat extensions similarly to the web for these checks, which would mean that renderer navigations will continue to fail.  meacer@, do you have an opinion here?  (And relatedly, is there a canonical workaround for web pages that would do this?)

I agree that these should behave the same as data URLs for consistency, i.e. blocked. The canonical workaround is to put these URLs in an iframe, an example is here: https://bugs.chromium.org/p/chromium/issues/detail?id=594215#c64

creis@, nick@, alexmos@ - friendly ping for #15. :)