I want to write scripts for firefox. It seems that firefox has different terms, like add-on, extensions, plugins. and I have a feeling they're not all the same. Can you sum up the difference between in a few words?
Add-on: essentially anything that can be installed into the browser. This includes for example extensions, themes, plugins, dictionaries, language packs, search engines.
Extension: a package extending browser functionality, the extension format used by Firefox works in Gecko-based browsers only. Extensions typically use XUL and CSS for their user interface as well as JavaScript for dynamic actions. They have full access to XPCOM and can provide their own XPCOM components as well. Recently the Add-on SDK has been added as an alternative way to generate simple extensions, it uses HTML instead of XUL but limits the ways in which the browser's user interface can be extended significantly. As of Firefox 57, all extensions have to be based on the WebExtensions API.
Plugin: means NPAPI plugins that are supported by all browsers but Internet Explorer (the latter uses the proprietary ActiveX technology instead). Such plugins are binary libraries that are invoked if a website uses an <embed> or <object> tag with a type that is handled by the plugin. The plugin can either draw some content for the tag (windowed plugins) or stay in background and simply provide an API for the webpage's JavaScript code to use (windowless plugins). Typical examples are Flash or Silverlight. Support for plugins is being phased out, as of 2018 Flash is the only plugin still supported to some degree.
Augmenting the useful answer above, I found this high-level summary helpful:
Extensions differ slightly from plug-ins. Plug-ins usually have a narrow set of abilities. [..] Since plug-ins and extensions both increase the utility of the original application, Mozilla uses the term "add-on" as an inclusive category of augmentation modules that consists of plug-ins, themes, and search engines.
(from http://en.wikipedia.org/wiki/Plug-in_(computing))
According to Firefox:
Extensions
Extensions add new features to Firefox or modify existing ones. There are extensions that allow you to block advertisements, download videos from websites, integrate Firefox with websites like Facebook or Twitter and add features included in other browsers, such as translator.
Plugins
Plugins add support for all kinds of Internet content. These usually include patented formats like Flash that are used for video, audio, online games, presentations and more. Plugins are created and distributed by other companies.
add-ons
They are - Extensions, Plugnis, Themes, Search engines and Dictionaries & Language Packs.
Source: Firefox - https://support.mozilla.org/en-US/kb/find-and-install-add-ons-add-features-to-firefox
Extending the Augmentation above
Extension(s) is ment to extend the functionality of software
where a plug-in is ment to solve a problem of the software (to be able to do something it wasent designed to do already).
both types extends the program abilitys,
... and i guess this is why it can be so comfusing.
An Extension can be (and often are) a(n) option from the company that made the software (Usually cost money),
a plug-in can be from the company that made the software or a third party to add abilities to the software.
Related
Firefox provides XPCOM API interface for writing add-on classes in C++ and allow third-party web applications to access them. I'm wondering - is there any other way of achieving these benefits (i.e. write an add-on in C++ and provide a JavaScript interface, so any JavaScript app can use this interface and eventually C++ class functionality)?
Yes, it is possible to write XPCOM components in C++ (or Javascript for that matter) and expose them to websites. You would register them in the JavaScript-global-property, JavaScript-global-constructor, etc. category or categories.
This stuff is generally not documented very well, if at all. If you'd like to know more about it, then read the code (e.g. on mxr).
But doing so is strongly discouraged for a lot of reasons:
It is very hard to ensure such things are actually secure and make it work reliable.
It is hard to control what website may actually use the new API. JavaScript-global-property and friends will be available to all websites!
Your add-on would be introducing new names into the global javascript namespace, which might clash with web site code. (Because of this, many new WebAPIs aren't introduced directly into the global namespace, but are made a property of navigator).
Due to these reasons, the addons.mozilla.org site will only accept add-ons using this mechanism as an exception to the rule and only when the author demonstrates that the use is required and without real alternatives.
MDN has a couple of articles regarding webpage-to-extension communication and vice versa you could use instead, e.g. "Interaction between privileged and non-privileged pages".
Also, it is discouraged to ship binary XPCOM components within extensions:
You'd need to re-compile your binaries against each Gecko version (every six weeks), because binary components are version tagged since Firefox 4.
Binary APIs/ABIs between (point) releases are not as stable as you would hope. Actually APIs/ABIs where inadvertently broken late in the game quite often, causing lots of unnecessary crashes for a lot of users, e.g. bug 828296.
The platform developers officially said binary components in extensions are a hassle.
Instead, you should try to use Javascript where possible, and/or create a normal binary library (.so, .dll, .dylib) with a C-API/ABI and use js-ctypes. You could implement your XPCOM components in javascript, which would then call into your library with js-ctypes.
AFAIK most add-ons switched to js-ctypes by now.
I am developing (yet another) password manager add-on for Firefox. My add-on needs to:
Add two context menu items to each password field.
Open a dialog box or floating panel when the menu item is selected.
Access a specific method of a specific XPCOM component.
Fill the password field.
Include a preferences window.
Be compatible with Firefox 4.0.
Preferably, also:
Run on Firefox 3.5 and 3.6.
Some users don't update to the latest version.
Firefox 4.0 won't run on a PowerPC Mac.
Install without a restart on Firefox 4.0.
Allow for localization.
I have tried the Add-on SDK (formerly known as Jetpack), and it makes it very easy to start developing. However, I find that HTML cannot easily create "native looking" dialog boxes and that the SDK is rather heavyweight. (It takes many kilobytes to build a simple extension; that includes an XPCOM component!)
What are the advantages and disadvantages of using the Add-on SDK to develop my Firefox extension? Is it ready for "serious" extension development?
Advantages:
Jetpack API exposes high level APIs for most of the things you mentioned:
Add two context menu items
floating panel
API for password manager
Jetpack based add-ons are restart-less.
Jetpack based add-ons are future proof in a sense that high level APIs will remain unchanged
for the coming versions of FF.
You may be able to use some community developed modules for APIs that are not exposed by SDK.
If this is not the last extension you're planning to build there is a potential for code reuse,
by building third party modules as ones mentioned in 4 (see docs for details)
Support for mobile FF is coming in post 1.0 version of Addon-SDK which may mean that your
extension can be made compatible with mobile version of FF with minimal to zero effort.
Jetpack comes with build-in unit testing framework.
Has a better security model, which will ease add-on review process.
Jetpack support commonjs modules / packages that which means that some of the code can be borrowed
from other projects like nodejs for example.
Disadvantages:
Jetpack no longer supports FF<4.
Does not yet have support for localization.
Has no API for building preference panels, but can be developed as third party module and shared
with rest of the community.
Add-on will contain code with layers of abstractions, that will increase size of add-on (there is
ongoing work that will reduce xpi size by excluding files that are not used by add-on).
Does it require knowledge of C/C++ ?
Going to their developers suggests they are purely based on XML/XUL/Javascript.
Want to confirm before I decide to write one.
Chrome extensions are HTML, CSS, and JavaScript. Firefox extensions can be written with native, platform-specific C++ code, but the vast majority are XUL and JavaScript (and some XBL for the more advanced extensions).
Probably the most unusual aspect of Firefox extension code compared to web-oriented JavaScript is that Firefox uses XPCOM to organize its components internally. But it is a stretch to call familiarity with QueryInterface a "skill set."
Extensions in general (Firefox, Chrome, Safari) are all done using HTML + CSS + JS, and you can take advantage of HTML5 features which is pretty cool!
But, if you want to add C++, you can do that as well using NPAPI (Plugins). You can develop a NPAPI plugin and package it up with your extension. Remember, once you expose NPAPI, your extension will be tagged non secure because you just exposed your extension to native code. In the near future PPAPI will be a sandboxed way doing plugins.
So use HTML, JS, CSS (You can even make an abstraction layer to develop them all at once, since they are same technology, just the front end and APIs integration differs. So do not use C++ (NPAPI) unless there is absolutely no other way.
Has anyone ever embedded the firefox web browser technology in their own [unmanaged] C/C++ GUI application in the same way that IE can be embedded as a COM object? (I would like to do this on Linux, not Windows). Are there "better" alternatives to firefox? I'm open to anything as long as I can use it with non-GPL code. My needs are fairly basic; I only need fundamental HTML parsing and display of static local files, but I'd take advantage of more sophisticated technology, if I can get it. I'd like to be able to use JavaScript, but I can get by without it.
First you need to differentiate between HTML engine and JavaScript Engine.
Firefoxs HTML rendering engine is called Gecko. And here is a guide about Embedding Gecko in your application.
Firefoxs JavaScript engine is called SpiderMonkey and here is How to Embed SpiderMonkey in your C application
Check out webkitgtk. It's not Gecko, but Webkit based. It basically provides a web browser widget that can be used in GTK+ applications. If you want to embed mozilla, there are things in the mercurial repositories for Mozilla repository that let you do it, but it didn't seem heavily supported last I checked.
as stated by Mozilla
Embedding of Gecko is no longer supported
so have a look on either previous mentioned Chromium Embedded Framework or WebKit. Alternatively, you can follow Mozilla's new project https://servo.org/.
You will find some more up to date information on Is it possible to Embed Gecko or Webkit in a Windows Form just like a WebView?
It is possible to use parts of Firefox (such as the Gecko renderer) in other apps. There are various approaches to this, including wxWebConnect, a web browser control for wxWidgets. See also Embedding Gecko
Another popular solution is WebKit. Again, there are various ways you can use this, including QtWebKit (a wrapper for the Qt toolkit) and webkitgtk (already mentioned by SB).
Have a look at CEF (Chromium Embedded Framework). It is very similar to WebKit and it also has built-in HTML and JavaScript engines embedded but has better WebGL and HTML5 Canvas support. It is released under BSD license.
Programming Languages, Open source libraries and standards adopted to make Firefox works.
It's a large, long lived project, so it's got far too many to list. Especially when you consider ancillary technologies - for example, the Elkhound parser combined with their JavaScript engine creates Dehydra, used to perform static analysis and transform source code, used to bring the old XPCOM stuff up to more recent standards and update dependencies on JavaScript calls.
At the broadest level, the runtime consists of mostly C++ components, configured by XUL interface description language and scripted with JavaScript. IIRC, some of the JS engine code from Adobe is C rather than C++, as are some of the lower level networking libraries. Over recent years, some UI functions have moved from C++ into JS. Then there are the build support and debugging code, which can be Python, perl, make scripts, and so on.
Its all in here :-)
https://developer.mozilla.org/En