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

RESOLVED FIXED in Firefox 56

Status

defect
RESOLVED FIXED
2 years ago
10 months ago

People

(Reporter: wisniewskit, Assigned: haik)

Tracking

unspecified
mozilla56
Dependency tree / graph

Firefox Tracking Flags

(firefox56 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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.
(Assignee)

Comment 1

2 years ago
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
(Assignee)

Comment 2

2 years ago
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)
(Assignee)

Comment 3

2 years ago
(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)
(Assignee)

Comment 4

2 years ago
In the meantime, to workaround this bug, set extensions.webextensions.protocol.remote=false and restart the browser.
(Assignee)

Comment 5

2 years ago
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)
(Assignee)

Updated

2 years ago
Blocks: 1332190
(Assignee)

Comment 7

2 years ago
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)
Comment hidden (mozreview-request)
(Assignee)

Updated

2 years ago
Assignee: nobody → haftandilian

Comment 9

2 years ago
mozreview-review
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?
(Assignee)

Comment 11

2 years ago
(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.

Comment 12

2 years ago
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

Comment 13

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/3def9b35478f
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
(Assignee)

Updated

2 years ago
Blocks: 1377569

Comment 14

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

Updated

10 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.