I am new to Firefox and Chrome extension development.
I have downloaded and tested helloworld sample extension in both FF and Chrome in development mode.
Followed the following steps to work properly in FF and chrome,
In FF
Extracted the sample extension, and added one file in /mozilla/firefox/dev_user/helloworld#mozilla.doslash.org and given extracted folder path.
My FF version is 12.0 and I changed the<em:maxVersion> to 12.0.* in install.rdf file.
Restarted FF and tested, it worked fine.
In Chrome:
Extracted the sample extension
Choose Tools > Extensions
Checked Developer mode
Click the Load unpacked extension button
Dialog appears and selected extracted sample extension folder path
Extension is added and works perfectly.
Now I would like to know how to package these extensions? I mean on clicking the package that extension should install directly in the browser instead of following the above steps.
It's generally not a good idea to ask four questions at once. Let's try to answer all your questions:
How do I package a Firefox extension?
You follow the official documentation (a Firefox XPI package is simply a ZIP archive).
How do I package a Chrome extension?
You follow the official documentation.
How do I make sure a Firefox extension can be installed from a website?
That question is already answered elsewhere.
How do I make sure a Chrome extension can be installed from a website?
You cannot. Current Chrome versions make it very complicated to install extensions from third-party sites. Your best bet is to upload your extension to the Chrome Web Store (as a ZIP archive of extension files, not a proper package - Chrome Web Store creates the package for you). Once the extension is in the Chrome Web Store you can use inline installation to simplify installation from the website associated with your extension.
Related
Developer A created a Chrome extension in a Mac environment. Built, tested, published and working for all end consumers.
Developer B cloned the repo used to create the extension, built it in a Windows environment and the Chrome extension fails when posting data to an external API. The same is true when building the extension in a WSL2/Ubuntu environment.
Basic Troubleshooting
Verified developers are using identitical npm and node versions
Verified the zipped extension, built in a Mac environment, works when tested locally in a Windows environment
Odd Behavior of Extension Built in Windows
A popup created by the extension contains an error not present in the 'good' version.
popup.js:2 Uncaught SyntaxError: Invalid or unexpected token
And the offending line:
let payload = {}; // Object to hold data payload
Extension retrieves configuration data from a secure external API
Extension does not post data to a secure external API and does not report any API connectivity errors
Have any of you encountered this? If so, penny for your thoughts.
Update: VSC claimed the file was in UTF8 and, to be thorough, I re-saved the file as straight UTF8. The issue persists. (Thank you for the suggestion, wOxxOm)
We brought another developer into the mix and found the problem.
Turns out npm build isn't sufficient. Our process required npm run start in order to create a working deployable extension.
I will expand my answer if I invest the time into determining why this is.
Thanks again.
I have written a python program to download YouTube videos. I want to add it as an extension to browser, but I have read that browser doesn't run python scripts. So how can I deploy it? Can I convert it into a software which when installed can be added as a plug-in to the browser? Or is there any other way of doing it?
I assume you are aware of the chrome extension/plugin development, If not, please go through online tutorials, Fast forward...
Adding Python to the Chrome extension
We have two options to add Python into a chrome extension:
Method 1: Include
Brython
in an iframe (requires server)
To run Python in the browser you have several options including Brython and emcascripten.
Method 2: Compile Python to Javascript using
Rapydscript
(best, serverless, pure extension.)
There are several tools to compile Python to Javascript. Rapydscript works fine, Pyjs does not work well with chrome.
Further, you can do your research.
I am using VueJS to develop for a Chrome extension. I can use the Vue extension for debugging my Vue code, when not developing for Chrome extension. However, I am not able to see the Vue extension tab when debugging my Chrome extension when inspecting in the chrome-extension with chrome developer tool. Thanks!
Unfortunately, it's impossible to use vue devtools in extensions at the moment because extension pages are served over chrome-extension://
It is a known issue, link: https://github.com/vuejs/vue-devtools/issues/120
First,use Vue devtools in Chrome ext Development environment is enabled.
Experience
These days I'm developing a Chrome browser plugin.I found that __VUE_DEVTOOLS_GLOBAL_HOOK__ undefined.
Although not a big problem, but I want to solve it.I have searched a lot of information online.
example:
1.open chrome-extension://<hash>/app.html
2.set Vue.config.devtools to be true
3.grant Vue Devtools ext file access
but all doesn't work.
Solution
As we know, vue-devtools is an essential piece of the Vue ecosystem, but it is currently tied to a web browser.
But now There is a package provides a standalone vue-devtools application, that can be used to debug any Vue app regardless of the environment. Now you can debug your app opened in mobile browser, safari, native script etc. not just desktop chrome or firefox.
This package name is vue-remote-devtools, which is a standalone electron shell to remotely debug Vue apps!
Let's have a try:
Following the README.md steps,
Install the package globally:
npm install -g #vue/devtools
run in your terminal: vue-devtools
you will see a electron app appear like this
3.inject the script tag to your Chrome Extension .html file.
Warning
Due to Chrome's Content Security Policy (CSP) restrictions on plug-ins,Chrome Extension's web request may be blocked.
At this point you need to modify the Chrome Ext configuration file manifest.js.
content_security_policy: "script-src 'self' 'unsafe-eval' http://localhost:8098; object-src 'self'"
Although you can copy content_security_policy to the corresponding file manifest.js, but I still hope you can find out what the CSP is:
What is Content Security Policy (CSP)
Finally
Connect Success！
Ref:
vue-remote-devtools
DevTools for Chrome Extension Development.
What are the practical differences?
Packed are extensions that have been compiled into a downloadable .crx file. These are the files you download and install from such places like the Chrome Web Store.
Unpacked are extensions that are available from your computer. Typically all the source files within a folder when you are developing an extension.
Not much in terms of functionality. Unpacked is used for development. Packed is when you need to distribute it. You cannot run an unpacked extension unless you enable developer mode, so not really practical if you're trying to distribute your app.
Possibly this is related to Using a plugin generated with Firebreath in a Firefox Extension?; however, my question is possibly more specific, so here goes...
I'm working on Linux (Ubuntu 11.04), and I have built a Mozilla/Firefox (Firefox 7) plugin using FireBreath. The resulting plugin on this platform is an "npXXX.so" file, which I got symlinked in ~/.mozilla/plugins. Then, I have coded an extension that uses this plugin - and apart from the symlink, nothing else seems required - all seems to work just smashing :)
So, knowing that "firefox supports installing your plugin via XPI. This is not recommended by the FireBreath team", now I'd still like to package the extension AND the plugin into an XPI file. So, I'm reading a bit on Structure of an installable bundle - MDN, and I can see these two possibilities:
/components/* XPCOM components (*.js, *.dll), and interface files from *.xpt (>=1.7)
...
/plugins/* NPAPI Plugins (>=1.8)
...
binary-component components/linux/mycomponent.so ABI=Linux_x86-gcc3
Now, it says: "The older XPCOM- and LiveConnect-based APIs for plugins should not be used.", so I guess the "/components" directory should not be used (even if it is given as an example in the above page). And I can not find this stated explicitly anywhere, but I'm guessing FireBreath builds NPAPI plugins - so presumably "/plugins" is the way to go. (There is also mention of "/platform", but it clearly says it's been deprecated for Firefox > 3.6).
Ok, so far so good... So I try to copy the plugin file to plugins/linux inside the extension directory:
cp -L ~/.mozilla/plugins/npXXX.so plugins/linux/
... and then insert the following in chrome.manifest:
binary-component plugins/linux/npXXX.so ABI=Linux_x86-gcc4
... then I zip the whole extension directory (the plugin included) as an .xpi, try to install it on a different computer. There, the .xpi succesfully installs, the .so file is indeed unpacked under the profile's extensions/XXX/plugins/linux/ directory - and every cross-platform (javascript) code of the extension works fine; except that the plugin cannot be found.
Now, of course, the user could themselves symlink the extension .so to ~/.mozilla/plugins/; however, I would like to spare the user of that :)
How would I go about this kind of packaging thing - is there a recommended way to do it?
Many thanks in advance for any answers,
Cheers!
Edit: found Shipping a plugin as a Toolkit bundle - MDN which claims only install.rdf , and a plugins/obj.so is needed; then I found Running Quake Live in Firefox 4, 5 and 6 on Linux [fixes inside], referring to a QuakeLivePlugin_433-modded_ff10.xpi, and that one does indeed follow such a simple structure.. If I install that, I get both a Quake extension and a Quake plugin (and that even with Error Console complaining "Could not read chrome manifest file '/path/to/extensions/quakeliveplugin#idsoftware.com/chrome.manifest'.") .... but if I try the same with my FireBreath plugin (e.g. just an install.rdf and plugin in /plugins), only extension gets shown - no plugin (and no reasonable error messages).. Could this be a problem with FireBreath?
Well, I'll post this as an answer - I have just confirmed that FireBreath plugin does in fact work being packaged in the simple "toolkit bundle" way as an .xpi extension.
Basically, I just cleared up my development PC's Firefox profile, and tried to install the .xpi carrying the plugin there - and on the dev PC, the plugin shows in about:plugins and runs just fine (even if it's just unpacked in profile/extensions/EXT/plugins/obj.so, and not in ~/.mozilla/plugins)... In fact, I packaged both the extension and the plugin in separate .xpi's, which were then merged in a single one as recommended in Multiple Item Package - MDN - and that works fine too (upon loading the merged xpi, one gets prompted about installing two extensions - one for the plugin carrying one, and the other for the "plain" extension)...
So the problem was on the other test computer only - and the problem seems to be that I'm using Gnome libraries in the plugin, and while my dev PC is Ubuntu 11.04 - I think this test PC was Ubuntu 10.04 ... So, quite likely, the problem is incompatible Gnome libraries in the plugin build; unfortunately, I don't get many errors back from firefox, even if I do:
NSPR_LOG_MODULES=IPCPlugins:5 NSPR_LOG_FILE=/tmp/plugins.log /path/to/firefox -P myprofile
(... as recommended in Logging Multi-Process Plugins - MDN - however, the /tmp/plugins.log remains empty). The only thing Firefox on the problem machine spits is something like this to stdout:
WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug!
(firefox:6548): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:1149: unable to lookup signal "text-insert" for non instantiatable type `AtkText'
... and I cannot tell if this has something to do with the plugin or not... But I guess at least the packaging part got confirmed as working now :) Cheers!
EDIT: After a while, the Firefox on the test PC did spit out the following (although I would have expected this message to pop up instantly):
LoadPlugin: failed to initialize shared library /path/to/profile/extensions/extXXX/plugins/npXXX.so [/usr/lib/libstdc++.so.6: version ``GLIBCXX_3.4.14' not found (required by /path/to/profile/extensions/extXXX/plugins/npXXX.so)]
... which finally confirms it was a build problem I have had.