Something has broken temporarily loading an unpacked WebExtension (XPI versions are fine). For instance, if given a manifest containing: > "content_scripts": [{ > "js": ["content.js"], > "matches": ["<all_urls>"] > }] The content script exists, and contain nothing but a "use strict" directive. I see this appear in my console: >uncaught exception: Unable to load script: moz-extension://29f0b3a1-1f92-cc4c-a525-34171074b4f9/content.js Mozregression hinted at the problem being introduced in bug 1334550, but as per the discussion starting at comment 150, it may not be related.

Ran an hg bisect and that led me to the June 28th backout of 1365133: $ hg bisect -b The first bad revision is: changeset: 366259:6190181ff409 user: Sebastian Hengst <archaeopteryx@coole-files.de> date: Wed Jun 28 06:24:50 2017 +0200 summary: Backed out changeset 74b19063d4e2 (bug 1365133) for failing browser/components/preferences/in-content-new/tests/browser_security.js and leaking in browser_notification_open_settings.js on Linux debug. r=backout on a CLOSED TREE

I'm wondering if we have a backout mismerge here. Prior to landing 1365133 (changeset 366239:b79b4644a3fe), unpacked extensions were working. After the backout of 1365133 (comment 1), unpacked extensions stopped working.

(In reply to Haik Aftandilian [:haik] from comment #1) > Ran an hg bisect and that led me to the June 28th backout of 1365133: I was wrong about this so I'm clearing the needinfo for aryx. I was using artifact builds to "hg bisect" and those builds are not reliable in this situation. This bug is a regression introduced by bug 1334550. The culprit is this check in ExtensionProtocolHandler::NewStream(). nsCOMPtr<nsIPrincipal> childPrincipal; NS_TRY(aChildLoadInfo->GetLoadingPrincipal(getter_AddRefs(childPrincipal))); if (nsContentUtils::IsSystemPrincipal(childPrincipal)) { return Err(NS_ERROR_FILE_ACCESS_DENIED); } It is failing because the child is using the system principal when trying to load a web-accessible resource. We'll have to either remove this check or, if possible, downgrade the principal when its received in the parent.

In the meantime, to workaround this bug, set extensions.webextensions.protocol.remote=false and restart the browser.

Christoph, do you have a recommendation on the principal issue? The check added (in the parent) to require the principal not be the system principal is failing because the child loads extension resources using the system principal. Can we just drop this check? We are already checking that the URI is moz-extension. Or is there a way to downgrade the principal?

(In reply to Haik Aftandilian [:haik] from comment #5) > Christoph, do you have a recommendation on the principal issue? > > The check added (in the parent) to require the principal not be the system > principal is failing because the child loads extension resources using the > system principal. Can we just drop this check? We are already checking that > the URI is moz-extension. Or is there a way to downgrade the principal? I am uncomfortable allowing that. I would like smaug to weigh in as well. Commonly nothing coming from the child should load using a systemPrincipal, right?

After further discussion with Christoph, we don't think the Principal check is necessary given the other checks we are doing. Namely, when a moz-extension URI comes from the child for an unpacked extension resource, we 1) Make sure the URI is a moz-extension URI 2) Make sure the host/UUID portion of the URI matches an existing enabled extension 3) Make sure the host/UUID maps to a directory in the substitution hash table 4) Make sure the file the URI resolves to is within the extension directory

Comment on attachment 8882651 [details] Bug 1377355 - Unable to load unpacked web extensions in about:debugging; content script cannot be loaded; https://reviewboard.mozilla.org/r/153732/#review158938

As discussed, I guess we can remove the whole loadinfo passing between child and parent. Should we do that in this bug or in a different one?

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #10) > As discussed, I guess we can remove the whole loadinfo passing between child > and parent. Should we do that in this bug or in a different one? I've filed bug 1377569 to stop passing the LoadInfo's to the parent. I'd rather do that in another bug so that I can get this fixed quickly, letting unpacked WebExtension work again.

Pushed by haftandilian@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3def9b35478f Unable to load unpacked web extensions in about:debugging; content script cannot be loaded; r=jimm

Thanks for the quick fix :haik, this is working great for me now.