1637059 - add/move permission to optional_permissions caused error

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P2)

Description

[TheRave]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce:

Moved webRequest fro permission to optional permission

1. on Firefox start
2. addon disable/enable

Tried to reproduce this as a separate xpi testcase for this bug, but there was all working.

Actual results:

1. on firefox start

can't access property "primeListener", api is undefined ExtensionCommon.jsm:2285
primeListeners resource://gre/modules/ExtensionCommon.jsm:2285
onManifestEntry chrome://extensions/content/parent/ext-backgroundPage.js:156
asyncEmitManifestEntry resource://gre/modules/ExtensionCommon.jsm:1546
AsyncFunctionNext self-hosted:693
(Async: async)
runManifest resource://gre/modules/Extension.jsm:2203
addStartupStatePromise resource://gre/modules/Extension.jsm:1905
addPromise resource://gre/modules/Extension.jsm:2197
runManifest resource://gre/modules/Extension.jsm:2202
startup resource://gre/modules/Extension.jsm:2504
addStartupStatePromise resource://gre/modules/Extension.jsm:1905
startup resource://gre/modules/Extension.jsm:2503
AsyncFunctionNext self-hosted:693
(Async: async)
startup resource://gre/modules/Extension.jsm:1699
callBootstrapMethod resource://gre/modules/addons/XPIProvider.jsm:1803
startup resource://gre/modules/addons/XPIProvider.jsm:1907
startup resource://gre/modules/addons/XPIProvider.jsm:2506
callProvider resource://gre/modules/AddonManager.jsm:212
_startProvider resource://gre/modules/AddonManager.jsm:583
startup resource://gre/modules/AddonManager.jsm:807
startup resource://gre/modules/AddonManager.jsm:3440
observe resource://gre/modules/addonManager.js:87
1589219456752 addons.xpi WARN Exception running bootstrap method startup on xxx-xxx@xxxxxxxx: TypeError: can't access property "primeListener", api is undefined(resource://gre/modules/ExtensionCommon.jsm:2285:11) JS Stack trace: [e-mail]:2285:11
[e-mail]:156:18
[e-mail]:1546:18
async_runManifest/<@Extension.jsm:2203:[e-mail]:1905:[e-mail]:2197:[e-mail]:2202:19startup/<@Extension.jsm:2504:[e-mail]:1905:[e-mail]:2503:[e-mail]:1699:27
[e-mail]:1803:33
[e-mail]:1907:32
[e-mail]:2506:39
[e-mail]:212:31
[e-mail]:583:17
[e-mail]:807:14
[e-mail]:3440:26
[e-mail]:87:29

2. addon disable/enable
   no failure

Expected results:

1. on Firefox start
   no failure

2. addon disable/enable
   no failure

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Firefox Bug Husbandry Bot]

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 3

[Andrew Swan [:aswan]]

Can you spell out the steps to reproduce more clearly? i.e., install version N where webRequest is a mandatory permission, then install version N+1 in which webRequest has become optional, then restart?

If you're getting this error in that case, then it sounds like another manifestation of bug 1618500.

Comment 4

[TheRave]

I thought i had exactly this already tested in my test case but maybe something was going wrong.

Starting Firefox with webRequest in permissions, close Firefox, move webRequest to optional permissions and start Firefox again. Today i tested this again and here is the result:

Uncaught TypeError: can't access property "primeListener", api is undefined
primeListeners resource://gre/modules/ExtensionCommon.jsm:2285
onManifestEntry chrome://extensions/content/parent/ext-backgroundPage.js:156
asyncEmitManifestEntry resource://gre/modules/ExtensionCommon.jsm:1546
runManifest resource://gre/modules/Extension.jsm:2203
addStartupStatePromise resource://gre/modules/Extension.jsm:1905
addPromise resource://gre/modules/Extension.jsm:2197
runManifest resource://gre/modules/Extension.jsm:2202
startup resource://gre/modules/Extension.jsm:2504
addStartupStatePromise resource://gre/modules/Extension.jsm:1905
startup resource://gre/modules/Extension.jsm:2503
startup resource://gre/modules/Extension.jsm:1699
callBootstrapMethod resource://gre/modules/addons/XPIProvider.jsm:1803
startup resource://gre/modules/addons/XPIProvider.jsm:1907
startup resource://gre/modules/addons/XPIProvider.jsm:2506
callProvider resource://gre/modules/AddonManager.jsm:212
_startProvider resource://gre/modules/AddonManager.jsm:583
startup resource://gre/modules/AddonManager.jsm:807
startup resource://gre/modules/AddonManager.jsm:3440
observe resource://gre/modules/addonManager.js:87
ExtensionCommon.jsm:2285
1589384407360 addons.xpi WARN Exception running bootstrap method startup on [e-mail]: TypeError: can't access property "primeListener", api is undefined(resource://gre/modules/ExtensionCommon.jsm:2285:11) JS Stack trace: [e-mail]:2285:11
[e-mail]:156:18
[e-mail]:1546:18
asyncrunManifest/<@Extension.jsm:2203:22
[e-mail]:1905:13
[e-mail]:2197:26
[e-mail]:2202:19
startup/<@Extension.jsm:2504:16
[e-mail]:1905:13
[e-mail]:2503:14
[e-mail]:1699:27
[e-mail]:1803:33
[e-mail]:1907:32
[e-mail]:2506:39
[e-mail]:212:31
[e-mail]:583:17
[e-mail]:807:14
[e-mail]:3440:26
[e-mail]:87:29

Comment 5

[TheRave]

As next step i have removed the optional_permission completely. The failure persist.

The failure disappears only if i add the webrequest permission back to permissions and will come back if i remove the webrequest permission again. So optional_permissions is not relevant here. This is related to removal of webRequest permission (at least this one) from permissions.

If i disable/enable the addon in addonmanager the addon starts normally, at next firefox restart failure is back. This appears only at Firefox startup.

Maybe it is also relevant that my development profile use proxy files and no packed xpi.

Comment 6

[Andrew Swan [:aswan]]

(In reply to TheRave from comment #5)

If i disable/enable the addon in addonmanager the addon starts normally, at next firefox restart failure is back. This appears only at Firefox startup.

Maybe it is also relevant that my development profile use proxy files and no packed xpi.

Ah, are you changing the extension version when you change the manifest?

Comment 7

[TheRave]

I do not have changed the addon version after the permission change in my dev enviroment.

To check if this is caused by proxy file enviroment, i made a xpi wihout webRequest and install. Proxy file is gone and xpi in extension folder. But fault is present at firefox start.

Then i installed a xpi with webRequest, failure is away and installed again the XPI without webRequest and failure is back.
Last but not least to exclude influence of addon versions number i made a 3rd test with different versions, same behavior.

So we can conclude

• only at firefox start
• not on addon enable
• also with xpi files
• also with different version numbers
• needed to access the API to get the failure message

I will upload the both testcases.

Is there a reason why the webRequest permission is not listed in addon manager addon properties or during install popup?

Comment 8

[TheRave]

Attachment: testcases.zip

Comment 9

[TheRave]

I was able to get rid of the permanent webRequest permission fault via the manual permission.remove()

1. removed webRequest from manifest "permissions"
2. placed a button to my options.html/js
3. started Firefox and disable/enable my addon to get the addon working
4. clicked the button to call permission.remove()
   5 no success - permissions getAll() show that webRequest is still present, after next restart primeListener fault was still present

Added optional_permissions section with webRequest

1. started Firefox and disable/enable my addon to get the addon working
2. made a permissions.request() for webRequest permission
3. Restart Firefox and no fault
4. tried again permissions.remove() and permissions.getAll() show that webRequest permission is gone
5. Restart Firefox / no fault

Comment 10

[Rob Wu [:robwu]]

We mistakenly assume that api is not null at https://searchfox.org/mozilla-central/rev/df4c90d4b8c92c99f76334acfe4813c573c12661/toolkit/components/extensions/ExtensionCommon.jsm#2285

However, when the extension lacks the permission, api can be null. I suppose that we can add !api || to the condition to fix this bug.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[Andrew Swan [:aswan]]

(In reply to TheRave from comment #7)

Is there a reason why the webRequest permission is not listed in addon manager addon properties or during install popup?

webRequest is used in conjunction with host permissions, so the user-facing prompt here is about "access your data on site ..."

(In reply to Rob Wu [:robwu] from comment #10)

We mistakenly assume that api is not null at https://searchfox.org/mozilla-central/rev/df4c90d4b8c92c99f76334acfe4813c573c12661/toolkit/components/extensions/ExtensionCommon.jsm#2285

However, when the extension lacks the permission, api can be null. I suppose that we can add !api || to the condition to fix this bug.

That would eliminate the exception but I think it might be papering over a deeper problem. That code only runs when the extension has an associated persistent listener and an extension can only create a persistent listener using a given api if it has permission to use that api. This bug is about the case when an extension is updated and the new version either drops the permission or migrates it from mandatory to optional. In the first case, we should have update handling code that clears any persistent listener state for apis that the extension is dropping permissions for. In the latter case, the permission should be migrated so the extension should retain the permission. The fact that this isn't happening suggests that we're not running the update handler when following the steps the original reporter used.

Ideally, both of these issues would get addressed and tested, but they both seem uncommon so its probably not a high priority.

Comment 13

[Shane Caraveo (:mixedpuppy)]

I want to investigate further, if a persistent proxy listener breaks due to moving to optional permission, this is a higher severity issue (which is how we marked it).

Comment 14

[Tim Spurway [:tspurway]]

S1 or S2 bugs need an assignee - could you find someone for this bug?

Comment 15

[Shane Caraveo (:mixedpuppy)]

Attachment: Bug 1637059 fix persistent listeners when updating permissions

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/92a8af8f6853
fix persistent listeners when updating permissions r=rpl

Comment 17

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/92a8af8f6853