Closed Bug 1572404 Opened 2 years ago Closed 2 years ago

[mozprofile] install addon with browser_specific_settings

Categories

(Testing :: Mozbase, defect)

Version 3
defect
Not set
normal

Tracking

(firefox70 fixed)

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: tarek, Assigned: tarek)

References

Details

Attachments

(1 file)

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

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.

Flags: needinfo?(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.

Flags: needinfo?(aswan)

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.

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

Blocks: 1562870

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

Pushed by tziade@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/59e241707fab
[mozprofile] install addon with browser_specific_settings r=whimboo
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
You need to log in before you can comment on or make changes to this bug.