Extensions don't work with file:// protocol since 9.0.0

[ChALkeR]

Extracted from #23662, #23662 (comment), per #23662 (comment) (cc @nornagon).

Extensions get loaded for http:// and https:// protocols, but don't work for file:// protocol, which is commonly used.

This also affects devtools extensions.

Appears to be an undocumented regression from 8.x.

Chrome by default behaves the same, but it has an Allow access to file URLs switch (the fileAccess flag) on extension page at chrome://extensions/, which enables the extension to run on file:// urls (which can be verified on Content scripts tab).
Any hint how to do that in Electron?
React-devtools works on file:// protocol in Chrome with that flag enabled, but does not work in Electron since 9.0.0, as there are no ways to toggle that setting.

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
  • 9.0.0, 9.0.2
• Operating System:
  • Linux xps 5.6.14-arch1-1 #1 SMP PREEMPT Wed, 20 May 2020 20:43:19 +0000 x86_64 GNU/Linux
• Last Known Working Electron version:
  • 8.3.1

Expected Behavior

Installed extensions should load for file:// protocol automatically, or/and there should be an opt-in/out-out for that (like opt-in in Chrome).

Extension content script present in Content scripts tab.

Actual Behavior

Extensions are not loaded if the for pages requested over file:// protocol.

No extension content script present in Content scripts tab.

To Reproduce

index.js:

const { app, session, BrowserWindow } = require('electron');
const path = require('path');

(async () => {
  await app.whenReady()
  await session.defaultSession.loadExtension(path.join(__dirname, 'extensions/test'))
  const bw = new BrowserWindow({webPreferences: {sandbox: true}})
  //await bw.loadURL('about:blank')
  //await bw.loadURL('https://example.org/')
  await bw.loadURL(`file://${path.resolve('simple.html')}`)
  bw.show()
  bw.openDevTools()
})()

Put anything in simple.html.

Example extension (but you can use any other, e.g. https://github.com/electron/electron/tree/master/spec-main/fixtures/extensions/chrome-api or react-devtools)

extensions/test/main.js

console.log('extension loaded')

extensions/test/manifest.json

{
  "name": "test",
  "version": "1.0",
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["main.js"],
      "run_at": "document_start"
    }
  ],
  "permissions": [ "file:///*", "http://*/*", "https://*/*" ],
  "manifest_version": 2
}

Screenshots

https://:

file://:

Additional Information

This breaks devtools extension and is a part (if not the main reason) behind #23662.

[danielweck]

Yep, "store not found" with Redux DevTools.
#24638

[RangerMauve]

I'd like to take a shot at this. Is there somewhere in the code where there's a decision being made on whether a particular content script should get injected or not?

[nornagon]

@RangerMauve I'd probably start by searching for kFileScheme in the extensions code: https://source.chromium.org/search?q=kFileScheme%20f:extensions

From here it looks like maybe if the extension requests access to file:// urls it might be allowed? There's also a constant called Extension::ALLOW_FILE_ACCESS that looks like it might be relevant.

Hopefully that's enough to get you started!

[RangerMauve]

Sweet. Also, do you think this would be at all related to the issue I saw with extensions not loading for custom protocol handlers? #23616 (comment)

[nornagon]

Seems plausible!

[ChALkeR]

ExtensionPrefs::SetAllowFileAccess is likely related.

In Electron: https://github.com/electron/electron/search?q=ExtensionPrefs

[ChALkeR]

@nornagon do you think that should be enabled unconditionally or via an opt-in when an extension is added?

[ChALkeR]

Got to debugging this.

extension->creation_flags() & Extension::ALLOW_FILE_ACCESS being false is the effective flag here.

Flipping 4 (Extension::ALLOW_FILE_ACCESS) on creation_flags makes this work.

[ChALkeR]

#25151 seems to be a fix, but I'm unsure if this should be the path forward.
Refs: #24011 (comment)

[nornagon]

@nornagon do you think that should be enabled unconditionally or via an opt-in when an extension is added?

IMO opt-in makes sense.

[nornagon]

Some more context: Chrome allows file access to all unpacked extensions by default (ref). There's a preference that controls file access for specific extensions. Since we only ever load unpacked extensions currently, I think it makes sense for us to expose this to the app.

[bedney]

Incredibly interested in this fix! Thank you @ChALkeR for working on it (and, of course, @nornagon for all of your work on the Chrome Extension API).

[petef19]

+1 thank you for working on this fix !

[bedney]

@ChALkeR - any chance this fix might be finished before the next 10.X. series release? It's a blocker for us.

Thank you!

[raksooo]

Great that this is being worked on! What's the current status?

By looking at the historical duration between major releases I get the impression that Electron 11 isn't too far away, which will result in Electron 8, the last version with this working, becoming unsupported. This is a blocker for me and it would be nice to not have to use an unsupported version after Electron 11 has been released.

[samuelmaddock]

There's currently more work to be done regarding persisting the option in the event that an extension is reloaded.

Also, just going to mention that posting a bounty to BountySource is another option for folks eager to see this get fixed.

[RobbieTheWagner]

I would be happy to sponsor this work, if someone thinks they can fix it.

[0501814314]

mosa.alhonadi2013@gmail.com

[bedney]

I can also back this bug with some cash. Can someone speak to the level of effort required here? Given that Electron apps are really meant to run from the file system, this is a pretty severe limitation.

[m4heshd]

Looking forward to a fix. Currently writing an unfair amount of scripts to compensate for this issue. Glad It's being worked on.

[rlaranjeira]

Thank you @nornagon!!

[btzsoft]

in 2021 the same issue. it's strange, does someone use react, mobx extensions in electron 11, 12 ?

[m4heshd]

@btzsoft works fine with Vue devtools.

[RobbieTheWagner]

Works fine with Ember Inspector as well.