Bug 1420633

Summary:	Plugin packaging guidelines && plugin white-listing
Product:	[Fedora] Fedora	Reporter:	Pavel Raiskup <praiskup>
Component:	firefox	Assignee:	Gecko Maintainer <gecko-bugs-nobody>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	gecko-bugs-nobody, jhorak, kengert, pjasicek, stransky
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-02-20 12:52:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pavel Raiskup 2017-02-09 06:46:34 UTC

Background story:
===
The good/bad thing about Firefox in Fedora is that we have really the latest
greatest Firefox release.  This is breaking upstream-provided vimperator from
time to time (upstream is not that fast as we are).

Usually some hack/workaround is enough, but I have a problem now with :tabopen
in vimperator 3.15 (solved by 3.16) which is badly broken against Firefox 51.
This issue requires patching (and at the time of reporting, we have Firefox 51
for a pretty long time in Fedora -- but vimperator upstream doesn't provide
  official updated extension).

So here I am, I'm sufficiently determined to package vimperator myself, but it
is hard to find info "howto package firefox plugin".
===

Could we have guidelines?

Also, there's a bureaucracy problem:  Firefox refuses to automatically load
installed plugin from /usr/lib64/firefox/browser/extensions.  Could we please
change that?  That directory is root-owned, and as long as we trust Fedora
packagers, we should trust that plugins (as a downstream packager, I don't
want/can't request Mozilla for signature of package build) ...  or at least it
would be nice if we could "white-list" the installed plugin explicitly from
extension's spec file.  Or what is the way around this?

Comment 1 Martin Stransky 2017-02-09 08:21:07 UTC

Hello, you can install your system extensions to /usr/lib64/mozilla/extensions/ (and use firefox ID subdir here). It's a location for system-wide extensions and should be enabled by default.

You can also check rpm for existing packaged extensions - mozilla-noscript rpm package for instance.

Another thing is that Firefox is moving to WebExtensions fast and XUL extensions may be disabled sooner or later - AFAIK current plan is end of 2017. I'd recommend to check if vimperator is going to switch to WebExtension first to package it in Fedora.

Comment 2 Pavel Raiskup 2017-02-09 12:59:02 UTC

Cool, it sounds like there's a way to package properly ATM.

> Another thing is that Firefox is moving to WebExtensions fast and XUL
> extensions may be disabled sooner or later - AFAIK current plan is end of
> 2017. I'd recommend to check if vimperator is going to switch to
> WebExtension first to package it in Fedora.

Sorry for the naive question, but does this mean that downstream packaging
of Firefox's plugins won't be possible in future (with WebExtension)?

Otherwise I think I'm not blocked to package vimperator just now, right?
Because if Firefox switched to new plugin format, vimperator is going to
be migrated... (I think there's motivation if there's ~30 000 users
far).  Or what's behind your note?

Comment 3 Martin Stransky 2017-02-20 12:25:54 UTC

(In reply to Pavel Raiskup from comment #2)
> Cool, it sounds like there's a way to package properly ATM.

Sure.

> > Another thing is that Firefox is moving to WebExtensions fast and XUL
> > extensions may be disabled sooner or later - AFAIK current plan is end of
> > 2017. I'd recommend to check if vimperator is going to switch to
> > WebExtension first to package it in Fedora.
> 
> Sorry for the naive question, but does this mean that downstream packaging
> of Firefox's plugins won't be possible in future (with WebExtension)?

I expect it will be possible to package WebExtension based addons.

> Otherwise I think I'm not blocked to package vimperator just now, right?

Yes, you can package any extension you want. I'm not sure such package is useful (I think direct install via Firefox to Firefox profile from AMO is better) but that's really your decision.

> Because if Firefox switched to new plugin format, vimperator is going to
> be migrated... (I think there's motivation if there's ~30 000 users
> far).  Or what's behind your note?

If the vimperator is not going to be migrated (I have no idea what's their plans) your package may be obsolete by end of this year.

Comment 4 Pavel Raiskup 2017-02-20 12:52:04 UTC

(In reply to Martin Stransky from comment #3)
> If the vimperator is not going to be migrated (I have no idea what's
> their plans) your package may be obsolete by end of this year.

Thanks.  I've googled a bit for this few days ago .. and it seems that the
new extension system is a bit less powerful (according to forum rumors)
to implement vimperator as is ...  so it was a bit unclear to me what is
going to happen with vimperator and with firefox projects;  one would
expect that vimperator is important plugin enough for whole firefox, but
apparently it is not;  similarly ~30k users of vimperator probably doesn't
100% mean that it is going to survive this firefox's transition.

Maybe it all just means should try to migrate to different plugin
(or browser).

Thanks a lot for your support, Martin.  I'm not interested now in the
plug-in package guidelines so feel free to reopen if it is on your radar.