As of Firefox 5, XPCOM components now enforce an exact Module::kVersion match?
Andrew Zitnay
now enforce an exact Module::kVersion match, meaning the only way to
support multiple major versions of Firefox is to build multiple XPCOM
components, one for each major version.
We here at LastPass object strenuously to this decision, and hope that
it might be reconsidered. We try to support as broad a range of
versions of Firefox as possible, and currently support all the way
back to 2.0. However, this decision means we will have to ship our
extension with a separate XPCOM component for Firefox 5, 6, 7, ...
This doesn't seem sustainable, especially considering the new 18-week
schedule. That means almost 3 new major versions a year. Our .xpi
will quickly bloat out to dozens of MB at this rate.
What exactly is the rationale behind this decision?
Drew
Benjamin Smedberg
> I just found out about the fact that as of Firefox 5, XPCOM components
> now enforce an exact Module::kVersion match, meaning the only way to
> support multiple major versions of Firefox is to build multiple XPCOM
> components, one for each major version.
binary stability of XPCOM, and are hoping/planning on making fundamental
changes to the ABI. Also, we have had many problems as normal XPCOM
interfaces change with binary components from addons causing crashes
because they don't check IIDs successfully, or don't notice the changes
in the development cycle at all. This consistent pain point has caused
us to clamp down hard on binary XPCOM components.
> We here at LastPass object strenuously to this decision, and hope that
> it might be reconsidered. We try to support as broad a range of
> versions of Firefox as possible, and currently support all the way
> back to 2.0. However, this decision means we will have to ship our
> extension with a separate XPCOM component for Firefox 5, 6, 7, ...
> This doesn't seem sustainable, especially considering the new 18-week
> schedule. That means almost 3 new major versions a year. Our .xpi
> will quickly bloat out to dozens of MB at this rate.
18 weeks. Since users will be upgraded to the new version automatically,
it should not be necessary to include more than two or three versions of
a binary component. However, many extension don't use binary components
because they are digging into the guts of the mozilla platform, instead,
they just have an existing library that they want to use from script. We
strongly recommend using ctypes to solve this case, instead of binary
XPCOM components.
If you need a binary XPCOM component to solve some problem that cannot
be solved from script, please work with us to make that problem
solveable from script. Especially as we move towards content processes,
you won't be able to dig into the guts of the platform from binary code
at all, and it will be better for everyone if we expose the necessary
APIs via script.
--BDS
Andrew Zitnay
objection to what will in effect break hundreds if not thousands of
extensions in just a few short weeks' time. However, it's clear you
guys have made up your mind, so I won't belabor the point.
ctypes are completely new to me... I haven't done much testing with
them, but I'm guessing we'll be able to convert almost all my XPCOM
functionality to ctypes, although it will be a big hassle. However,
there's one piece I'm not sure ctypes can handle. As a part of our
extension's XPCOM functionality, we kick off a thread that listens for
messages on a named pipe. When it receives such a message, it calls
back into our extension's JavaScript, via nsIObserverService. Am I
correct in thinking there's no real way to do this without XPCOM (i.e.
JavaScript interface, ctypes, etc)? If I'm incorrect, I'd appreciate
it if you'd point me in the right direction.
Drew
David E. Ross
Effectively, Firefox will no longer constitute a stable baseline.
This will stifle the development of new add-ons. Since many (most?)
add-ons are developed by unpaid volunteers in their spare time, it can
easily take longer than the interval between Firefox releases to create
a new add-on.
Furthermore, existing, widely used add-ons might drop out of maintenance
when their developers do not have enough spare time to keep up with an
ever-changing Firefox.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Benjamin Smedberg
> I understand where you're coming from... But I absolutely renew my
> objection to what will in effect break hundreds if not thousands of
> extensions in just a few short weeks' time. However, it's clear you
> guys have made up your mind, so I won't belabor the point.
binaries at all.
We've discussed not supporting binary XPCOM components at all in
extensions, and decided not to do that (yet). We understand that there
are many interesting things you can do to Firefox only with binary
components. But the goal is to do those things as experiments, and then
try to make those same features available to script, so that binaries
are not necessary.
>
> ctypes are completely new to me... I haven't done much testing with
> them, but I'm guessing we'll be able to convert almost all my XPCOM
> functionality to ctypes, although it will be a big hassle. However,
> there's one piece I'm not sure ctypes can handle. As a part of our
> extension's XPCOM functionality, we kick off a thread that listens for
> messages on a named pipe. When it receives such a message, it calls
> back into our extension's JavaScript, via nsIObserverService. Am I
> correct in thinking there's no real way to do this without XPCOM (i.e.
> JavaScript interface, ctypes, etc)? If I'm incorrect, I'd appreciate
> it if you'd point me in the right direction.
This is an interesting question. ctypes is main-thread-only. It's quite
possible to launch a new thread and communicate with it in your DLL. The
question is how you could post an event back to the main thread without
XPCOM. On Windows you could create a hidden window and post a message to
it pretty easily, but it might not be so easy on other platforms.
Definitely file a bug, and we can create an ctypes-accessible API to
post data back to the main thread.
On 6/8/2011 8:17 PM, David E. Ross wrote:
> Effectively, Firefox will no longer constitute a stable baseline.
>
> This will stifle the development of new add-ons. Since many (most?)
> add-ons are developed by unpaid volunteers in their spare time, it can
> easily take longer than the interval between Firefox releases to create
> a new add-on.
>
> Furthermore, existing, widely used add-ons might drop out of maintenance
> when their developers do not have enough spare time to keep up with an
> ever-changing Firefox.
This discussion is currently only about binaries. Since most extensions
don't have binaries, I think your predictions of doom are not warranted.
FIrefox has never had a usable stable baseline of APIs: everything from
XUL structure to JS functions has changed over time, all of which may
require extensions to be reworked for a release. The question now is
about the *pace* of change. With the shorter release cycle, each release
contains fewer changes, and most extensions which don't have XPCOM
binaries will probably not need to be revised for each release. The only
issue here is the pain that we are adding (intentionally) for those
extensions with binary components.
We understand that the rapid release model may make old-style extensions
harder to maintain. It's a tradeoff we have to make in order to get new
features to market and remaing competitive. We actively encourage new
extensions and new extension authors to use the Jetpack SDK, which is a
stable API.
--BDS
bsmedberg
> > ctypes are completely new to me... I haven't done much testing with
> > them, but I'm guessing we'll be able to convert almost all my XPCOM
> > functionality to ctypes, although it will be a big hassle. However,
> > there's one piece I'm not sure ctypes can handle. As a part of our
> > extension's XPCOM functionality, we kick off a thread that listens for
> > messages on a named pipe. When it receives such a message, it calls
> > back into our extension's JavaScript, via nsIObserverService. Am I
> > correct in thinking there's no real way to do this without XPCOM (i.e.
> > JavaScript interface, ctypes, etc)? If I'm incorrect, I'd appreciate
> > it if you'd point me in the right direction.
>
> This is an interesting question. ctypes is main-thread-only. It's quite
Actually, I'm wrong about this. ChromeWorkers already exist
specifically so that you can use ctypes from a worker thread. See
https://developer.mozilla.org/en/DOM/ChromeWorker. This should allow
you to launch the helper thread as a ChromeWorker and make your
blocking call using ctypes in Firefox 4+.
--BDS
Andrew Zitnay
As a final rant, I really wish this news had been made public back before Firefox 4 was released. Perhaps I missed it, or perhaps you guys hadn't decided on this path at that time. However, had I known XPCOM would end up becoming useless to us, I certainly would have spent my time working on ctypes instead of working on the nomozalloc solution, which is essentially pointless now that XPCOM binaries are tied directly to a major Firefox version.
Drew
Benjamin Smedberg
> As a final rant, I really wish this news had been made public back before Firefox 4 was released. Perhaps I missed it, or perhaps you guys hadn't decided on this path at that time.
in the wiki at that time:
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/18f49e75338e4ce0/fab84d94e45a6591?lnk=gst&q=interface+compatibility#fab84d94e45a6591
I should have cc'ed mozilla.dev.extensions at the time, an oversight I
will avoid repeating in the future.
--BDS