1572404 - [mozprofile] install addon with browser_specific_settings

Status: RESOLVED FIXED

(Testing :: Mozbase, defect)

Description

[Tarek Ziadé (:tarek)]

webextensions now uses browser_specific_settings instead of application in the manifest file. mozprofile can't detect in that case the gecko id and ends up generating a new uuid for the addon, making it temporary.

The fix seems trivial in AddonManager.addon_details :

$ hg di testing/mozbase/mozprofile/mozprofile/addons.py
diff --git a/testing/mozbase/mozprofile/mozprofile/addons.py b/testing/mozbase/mozprofile/mozprofile/addons.py
--- a/testing/mozbase/mozprofile/mozprofile/addons.py
+++ b/testing/mozbase/mozprofile/mozprofile/addons.py
@@ -282,17 +282,20 @@ class AddonManager(object):
			reraise(AddonFormatError, AddonFormatError(str(e)), sys.exc_info()[2])

		if is_webext:
			details['version'] = manifest['version']
			details['name'] = manifest['name']
			try:
				details['id'] = manifest['applications']['gecko']['id']
			except KeyError:
-                details['id'] = cls._gen_iid(addon_path)
+                try:
+                    details['id'] = manifest['browser_specific_settings']['gecko']['id']
+                except KeyError:
+                    details['id'] = cls._gen_iid(addon_path)
			details['unpack'] = False
		else:
			try:
				doc = minidom.parseString(manifest)

				# Get the namespaces abbreviations
				em = get_namespace_id(doc, 'http://www.mozilla.org/2004/em-rdf#')
				rdf = get_namespace_id(doc, 'http://www.w3.org/1999/02/22-rdf-syntax-ns#')

If that change sounds good I'll push a patch along with a test

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Note that the code above for accessing manifest['applications']['gecko']['id'] is in a block which only gets executed for web extensions. I wonder when the change from application to browser_specific_settings happened, and if we would still have to support the former location. Personally I doubt so, and it might be good to simply change the already existing line.

Andrew, could you give more details for the above? Thanks.

Comment 2

[Tarek Ziadé (:tarek)]

Relevant bug 1262005

see https://bugzilla.mozilla.org/show_bug.cgi?id=1262005#c9

Comment 3

[Andrew Swan [:aswan]]

browser_specific_settings was the name proposed for the cross-browser browser extensions spec:
https://browserext.github.io/browserext/#list-of-keys

Firefox implements that manifest key (but it will accept either applications or browser_specific_settings for compatibility) but the w3c spec never really went anywhere.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

So I would suggest that we also should support both locations of the extension id. Tarek feel free to add that, and an unit test too.

Comment 5

[Tarek Ziadé (:tarek)]

yeah ok. for the record it's the key used by uBlock - which is currently not installable as a non-temporary webextension via mozprofile

Comment 6

[Tarek Ziadé (:tarek)]

Attachment: Bug 1572404 - [mozprofile] install addon with browser_specific_settings r?whimboo

webextensions now uses "browser_specific_settings" instead of "applications" in
the manifest file. This patch make mozprofile look for both places.

Comment 7

[Tarek Ziadé (:tarek)]

try build https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f0f8044837f9dd82b963a20e22829587c1aebb4

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/59e241707fab
[mozprofile] install addon with browser_specific_settings r=whimboo

Comment 9

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/59e241707fab