It would be really cool, if the extension system is made such that it
is compatible with Firefox extensions. It sounds tough, but it would
save a lot of trouble and would bring chrome up to speed immediately,
no need to write extensions again for chrome.
i think making it compatible with FF extensions would be a very bad
idea.
yes it would be nice if it could be done foolproof, but those
extensions expect being used in a firefox browser.
if you'd try running them in chrome, even after adding FF extension
support, a lot of bugs would come up.
On Sep 3, 10:47 am, "Tosif Ahmed" <tosifaha...@gmail.com> wrote:
> It would be really cool, if the extension system is made such that it
> is compatible with Firefox extensions. It sounds tough, but it would
> save a lot of trouble and would bring chrome up to speed immediately,
> no need to write extensions again for chrome.
> On Wed, Sep 3, 2008 at 1:59 PM, Aaron Boodman <a...@chromium.org> wrote:
On Wed, Sep 3, 2008 at 1:47 AM, Tosif Ahmed <tosifaha...@gmail.com> wrote:
> It would be really cool, if the extension system is made such that it > is compatible with Firefox extensions. It sounds tough, but it would > save a lot of trouble and would bring chrome up to speed immediately, > no need to write extensions again for chrome.
It is not possible to make Firefox-compatible extensions. Most of them rely on a combination of two Mozilla technologies (XUL and XPCOM), neither of which are available in Chromium.
However, I think we have an opportunity to do something new. We can learn from previous systems and hopefully create something that is easier to learn, more powerful, and more robust.
thedicemaster wrote: > i think making it compatible with FF extensions would be a very bad > idea. > yes it would be nice if it could be done foolproof, but those > extensions expect being used in a firefox browser. > if you'd try running them in chrome, even after adding FF extension > support, a lot of bugs would come up.
Firefox plugins have a full set for versioning. Each extension announces in which products it can run (Firefox, Thunderbird, Flock...), and on which version range. Adding Chromium as a supporter app is just a matter of creating a GUI. The author would still need to specify it's supported (and they're better trying it before asserting that).
The problem is that firefox extensions are made based on XUL on 99%+, so having them work also on chrome would be very hard.
Yes, we've seen that Firefox uses XUL+Javascript to make extensions and plugins. But it is really a good thema for us to add for Chrome more new applications into. So if Chrome supports this, it will be wonderful. I think that Google won't close the door to the developers and their community, not just opening its source. I hope Google should open Chrome's APIs as early as possible. :) Then more greate extensions in Firefox could be moved into Chrome if it were possible.
-------------------------------------------------- From: "Den Molib" <den.mo...@gmail.com> Sent: Thursday, September 04, 2008 12:44 AM To: <chromium-dev@googlegroups.com> Subject: Re: Plugins
> thedicemaster wrote: >> i think making it compatible with FF extensions would be a very bad >> idea. >> yes it would be nice if it could be done foolproof, but those >> extensions expect being used in a firefox browser. >> if you'd try running them in chrome, even after adding FF extension >> support, a lot of bugs would come up.
> Firefox plugins have a full set for versioning. Each extension announces > in which products it can run (Firefox, Thunderbird, Flock...), and on > which version range. > Adding Chromium as a supporter app is just a matter of creating a GUI. > The author would still need to specify it's supported (and they're > better trying it before asserting that).
> The problem is that firefox extensions are made based on XUL on 99%+, so > having them work also on chrome would be very hard.
On Thu, Sep 4, 2008 at 5:31 AM, Simon B. <simon.boh...@gmail.com> wrote: > That FAQ doesn't explain what I see at about:plugins > Obviously Chrome detects, and probably uses, all those plugins?
> Important questions: Which interfaces are supported? (NPAPI?) Is there > a version number or capability list that is relevant?
This is a common area of confusion. Chromium fully supports NPAPI plugins, like Adobe Flash and Apple Quicktime. What it doesn't support are browser extensions, like Adblock and Greasemonkey.
I've updated the FAQ. Let me know if it still doesn't make sense.
> I've updated the FAQ. Let me know if it still doesn't make sense.
It makes sense, but doesn't work. Our plugin won't install. We have a
seamonkey/mozilla style install.js and a firefox install.rdf inside
a .xpi file, but the plugin doesn't install and no errors are
displayed and there is nothing in the javascript console. I've
debugged it, and it appears that it is hanging inside
InstallTrigger.enabled() (it never returns).
So the question is: how exactly do you install a Chomium plugin? Do
you use install.rdf or install.js? If you use install.rdf, what is the
application id for Chromium? And your faq says you don't support xpi
files, but that is normally how plugins are packaged, so if we can't
put them in an xpi what do we do?
xpi files are Firefox extensions (not plugins) and don't work in
chrome.
Chrome as no extension mechanism at this time, and the day they will
have one, it seems very clear that the firefox extensions won't work
more than now.
On 4 sep, 18:47, davidj <dav...@groupboard.com> wrote:
> > I've updated the FAQ. Let me know if it still doesn't make sense.
> It makes sense, but doesn't work. Our plugin won't install. We have a
> seamonkey/mozilla style install.js and a firefox install.rdf inside
> a .xpi file, but the plugin doesn't install and no errors are
> displayed and there is nothing in the javascript console. I've
> debugged it, and it appears that it is hanging inside
> InstallTrigger.enabled() (it never returns).
> So the question is: how exactly do you install a Chomium plugin? Do
> you use install.rdf or install.js? If you use install.rdf, what is the
> application id for Chromium? And your faq says you don't support xpi
> files, but that is normally how plugins are packaged, so if we can't
> put them in an xpi what do we do?
I think that Chrome uses different kernal,so that the xpis from firefox can not be used it. Now I believe this. :) -------------------------------------------------- From: "MichelB" <michel.bosse...@gmail.com> Sent: Thursday, September 04, 2008 6:59 PM To: "Chromium-dev" <chromium-dev@googlegroups.com> Subject: Re: Plugins
> Java, Flash, ... are plugins, and work in Chrome.
> xpi files are Firefox extensions (not plugins) and don't work in > chrome. > Chrome as no extension mechanism at this time, and the day they will > have one, it seems very clear that the firefox extensions won't work > more than now.
> On 4 sep, 18:47, davidj <dav...@groupboard.com> wrote: >> > I've updated the FAQ. Let me know if it still doesn't make sense.
>> It makes sense, but doesn't work. Our plugin won't install. We have a >> seamonkey/mozilla style install.js and a firefox install.rdf inside >> a .xpi file, but the plugin doesn't install and no errors are >> displayed and there is nothing in the javascript console. I've >> debugged it, and it appears that it is hanging inside >> InstallTrigger.enabled() (it never returns).
>> So the question is: how exactly do you install a Chomium plugin? Do >> you use install.rdf or install.js? If you use install.rdf, what is the >> application id for Chromium? And your faq says you don't support xpi >> files, but that is normally how plugins are packaged, so if we can't >> put them in an xpi what do we do?
davidj wrote: >> I've updated the FAQ. Let me know if it still doesn't make sense.
> It makes sense, but doesn't work. Our plugin won't install. We have a > seamonkey/mozilla style install.js and a firefox install.rdf inside > a .xpi file, but the plugin doesn't install and no errors are > displayed
Without getting too far into details, I also think you should understand that it's not really feasible to say "Chrome extensions should be backwards compatible with Firefox". There are many architectural reasons that this is a very difficult (intractable?) proposition, not the least of which is the fact that Firefox uses XUL for all of its UI and we don't really have anything remotely resembling XUL. Our extension system is bound to be different. What would be helpful to know is what sorts of functionality you think is required, e.g. what sort of extensions you want to be able to write with such a system.
On Thu, Sep 4, 2008 at 2:11 PM, Den Molib <den.mo...@gmail.com> wrote:
> davidj wrote: > >> I've updated the FAQ. Let me know if it still doesn't make sense.
> > It makes sense, but doesn't work. Our plugin won't install. We have a > > seamonkey/mozilla style install.js and a firefox install.rdf inside > > a .xpi file, but the plugin doesn't install and no errors are > > displayed > *bangs his head against the wall*
> >> I've updated the FAQ. Let me know if it still doesn't make sense.
> > It makes sense, but doesn't work. Our plugin won't install. We have a
> > seamonkey/mozilla style install.js and a firefoxinstall.rdfinside
> > a .xpi file, but the plugin doesn't install and no errors are
> > displayed
> *bangs his head against the wall*
But you can't answer my simple question?
>xpi files are Firefox extensions (not plugins)
Er no. In firefox and mozilla/seamonkey you package plugins into xpi
files. Have you ever actually developed a plugin for firefox?
Just to recap: xpi files are used for plugins and XUL extensions. I
understand that Chromium doesn't support XUL, but does/will it support
xpi for plugin installation? If not, does the user have to manually
copy the files into his plugins directory to install the plugin?
NPAPI plugins can be installed via the google chrome default plugin which looks up the mime type against a known plugin database and based on receiving the consent from the user downloads the file and launches it.
If the plugin is not there in the database, then the user can download it using firefox, or just searching for the plugin online, which should hopefully achieve the result.
On Thu, Sep 4, 2008 at 5:25 PM, davidj <dav...@groupboard.com> wrote:
> > >> I've updated the FAQ. Let me know if it still doesn't make sense.
> > > It makes sense, but doesn't work. Our plugin won't install. We have a > > > seamonkey/mozilla style install.js and a firefoxinstall.rdfinside > > > a .xpi file, but the plugin doesn't install and no errors are > > > displayed
> > *bangs his head against the wall*
> But you can't answer my simple question?
> >xpi files are Firefox extensions (not plugins)
> Er no. In firefox and mozilla/seamonkey you package plugins into xpi > files. Have you ever actually developed a plugin for firefox?
> Just to recap: xpi files are used for plugins and XUL extensions. I > understand that Chromium doesn't support XUL, but does/will it support > xpi for plugin installation? If not, does the user have to manually > copy the files into his plugins directory to install the plugin?
On Sep 4, 6:42 pm, "Ananta Iyengar" <ana...@chromium.org> wrote:
> If the plugin is not there in the database, then the user can download it
> using firefox, or just searching
> for the plugin online, which should hopefully achieve the result.
As there is no way to get your plugin added to the database, that
option is out.
So how exactly does the user install the plugin for Chromium after
downloading it in firefox? Do they have to unzip the xpi and manually
copy the files? Not exactly user friendly...
The other option is for developers to write a .exe plugin installer
specifically for Chromium, which I imagine they will not do until
Chromium gets a significant share of the browser market.
On Thu, Sep 4, 2008 at 6:25 PM, davidj <dav...@groupboard.com> wrote:
> On Sep 4, 6:42 pm, "Ananta Iyengar" <ana...@chromium.org> wrote:
> > If the plugin is not there in the database, then the user can download it > > using firefox, or just searching > > for the plugin online, which should hopefully achieve the result.
> As there is no way to get your plugin added to the database, that > option is out.
> So how exactly does the user install the plugin for Chromium after > downloading it in firefox? Do they have to unzip the xpi and manually > copy the files? Not exactly user friendly...
> The other option is for developers to write a .exe plugin installer > specifically for Chromium, which I imagine they will not do until > Chromium gets a significant share of the browser market.
Actually most of the popular NPAPI plugins like Flash/Shockwave/quicktime/windows media player/Real player, etcdo have exe based installers. AFAIK, based on whatever testing I have done with a fresh FF install with no plugins, mozilla has a plugin finder service which is based on a similar concept, which launches the corresponding installer like flash, etc. Google chrome's behavior is very similar.
Safari also does not support XPI based installs.
-Ananta
On Thu, Sep 4, 2008 at 6:30 PM, Nicolas Sylvain <nsylv...@chromium.org>wrote:
> Chromium supports only NPAPI plugins, not XPI extensions. > Nicolas
> On Thu, Sep 4, 2008 at 6:25 PM, davidj <dav...@groupboard.com> wrote:
>> On Sep 4, 6:42 pm, "Ananta Iyengar" <ana...@chromium.org> wrote:
>> > If the plugin is not there in the database, then the user can download >> it >> > using firefox, or just searching >> > for the plugin online, which should hopefully achieve the result.
>> As there is no way to get your plugin added to the database, that >> option is out.
>> So how exactly does the user install the plugin for Chromium after >> downloading it in firefox? Do they have to unzip the xpi and manually >> copy the files? Not exactly user friendly...
>> The other option is for developers to write a .exe plugin installer >> specifically for Chromium, which I imagine they will not do until >> Chromium gets a significant share of the browser market.
Yes, mozilla/firefox has a plugin finder service, but it is useless
for small developers because they cannot get their plugins listed on
it.
And yes, safari doesn't have xpi installs, but it uses dmg format
which is similar.
xpi is nice because it is cross platform, simple and has been around
for years. Chromium seems to be going back a step by reverting to the
10-year old Netscape 4 type plugin installation.
Anyway, it is just nice to have. Not all developers use .exe installs
for their plugins. It's easier using xpi installs rather than trying
to figure out which browsers are installed and where they're installed
and where the plugins should go. In firefox 2 plugins are installed in
program files but in firefox 3 they're in documents and settings.
davidj, for now you probably have to create an EXE or MSI installer
that copies your plugin to the proper directory. That's quite
difficult, since the user might have more copies of Google Chrome (one
per user, unless theres a already a Chrome Portable existing?) as well
as multiple copies of Chromium, each with it's own "plugins" folder.
XPI and DMG are more or less ZIP-files, with some extra metadata
inside. Some people suggest using the XPI format for _packaging_ also
for Chromium. A decision should be based on what is most practical and
pedagogical. I like XPI, but using XPI could give Chromium the burden
of explaining to users why not all ".XPI files" work.
Inside those packages there can be NPAPI plugins, or XUL (Mozilla-
specific). For Safari I saw SIMBL being used for GreaseKit. Is this a
standard for Safari?
Words.
"Plugin", does that make you think of an interpreter (view/edit/
print/...) for file formats? The existing plugin database for NPAPI
plugins supports this beleif.
"Addon" then, might stand for everything else that you add to the
browser?
"Services". Chrome understands search services. Bookmark services and
others could be supported directly in Chrome, or via an "addon".
The current FAQ entry (by Aaron) looks like this:
Q. How can I develop extensions for Chromium like in Firefox?
A. Chromium doesn't have an extension system yet. This is something
we're interested in adding in a future version. Note that Chromium
does support NPAPI-style "plugins", such as Adobe Flash and Apple
QuickTime.
Just after the FAQ was updated, Aaron had to explain further:
It is not possible to make Firefox-compatible extensions. Most of
them
rely on a combination of two Mozilla technologies (XUL and XPCOM),
neither of which are available in Chromium.
Some of the above might fit into the FAQ?
And thanks Aaron for staying with us here :).
About NPAPI plugins, it seems (by a quick look at some source code)
that they cannot self-activate, i.e. at page load or DOM ready, but
instead function via object embedding and MIME type lists.
It could still be possible to implement some DOM-modifying
functionality as NPAPI plugin which would then be activated or used
via a Bookmarklet. Once the official API gets designed, coded,
debugged and shipped, it should be easy to do the equivalent of such a
bookmarklet. Instant (though ugly-hacked) plugins!
(What I have in mind is the basics parts of greasemonkey / stylish
functionality, which could open up a big collection of javascripts and
style tweaks. Those who need high-contrast, or have local news sites
with horrible layout, could be very thankful.)
Oh, and there's also the ActiveX dead end. An ActiveX shim (used by
Chrome) has class names hinting about DOM access, but eseidel (on the
developer chat) says that the ActiveX shim uses a very small
whitelist. You can't get whitelisted, and anyway ActiveX is hardly a
good way forward. Also I don't think it would be useful for trying a
quick port of some existing IE addons. (What's the API for plugins in
IE? I've built an Outlook plugin (for hashcash) and at the "API"
exposed very few events to activate plugin functionality.)
|
