Bug 1420633 - Plugin packaging guidelines && plugin white-listing
Summary: Plugin packaging guidelines && plugin white-listing
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-09 06:46 UTC by Pavel Raiskup
Modified: 2017-02-20 12:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-20 12:52:04 UTC
Type: Bug


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.