Closed Bug 1377355 Opened 3 years ago Closed 3 years ago

Unable to load unpacked web extensions in about:debugging; content script cannot be loaded

Categories

(WebExtensions :: Request Handling, defect)

defect
Not set
normal

Tracking

(firefox56 fixed)

RESOLVED FIXED
mozilla56
Tracking Status
firefox56 --- fixed

People

(Reporter: wisniewskit, Assigned: haik)

References

Details

Attachments

(1 file)

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.
Flags: needinfo?(aryx.bugmail)
(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.
Flags: needinfo?(aryx.bugmail)
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?
Flags: needinfo?(ckerschb)
(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?
Flags: needinfo?(ckerschb) → needinfo?(bugs)
Blocks: 1332190
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
Flags: needinfo?(bugs)
Assignee: nobody → haftandilian
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
Attachment #8882651 - Flags: review?(jmathies) → review+
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
https://hg.mozilla.org/mozilla-central/rev/3def9b35478f
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Blocks: 1377569
Thanks for the quick fix :haik, this is working great for me now.
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.