I'm not sure if this is the right place to ask this. I've googled this and not really finding the results. I'm using ES6 modules and import/export and load my initial javascript using module type
<script type="module" src="/app.js"></script>
In Chrome its on by default. In firefox you have to enable it in about:config
The problem is I cant have users manually enabling this flag for it to work. Is there a future where this will be on by default in Firefox? At CanIUse, it says that in version 60, its on by default. But every version of Firefox I've downloaded is only version 59.00 (Windows). I would like to avoid babel if possible.
Is there a future where this will be on by default in Firefox?
Yes.
At CanIUse, it says that in version 60, its on by default. But every version of Firefox I've downloaded is only version 59.00 (Windows).
You can download the nightly build here.
I would like to avoid Babel if possible.
Well you cannot avoid if you want to support older browsers that do not (yet) support this feature.
Related
I see each cfx tools always produce xpi with its own minVersion and maxVersion. However, those are limited to the versions which the SDK is compatible with, e.g. SDK 1.14 only for FF 21 - 25.0a1 , SDK 1.17 only for FF 26 - 30. My questions are:
Do I need to package my extension with new SDK everytime new version comes out ?
How do I maintain and update my extension in the future? Does Addon Developer Hub provides a way to submit the same extension for multiple SDK versions ? I tried to look around but couldn't find a way to submit multiple versions.
I want to make FF 21 as the minimum version, since that's the version which has SDK built-in. My extension currently compiles with both SDK 1.14 and SDK 1.17 with only cosmetic(syntax) adjustment.
The developer hub lets you choose which versions of Firefox the add-on is compatible with. This is just a GUI for setting the minVersion and maxVersion in the install.rdf. As long as you don't use modules or methods that require Firefox 22+, it shouldn't matter which version of the SDK you use, as the version of the SDK being run is determined by the version on your user's browser.
It's hard to find module specific compatibility (you can always go to the docs for the specific module and look at the edit history), but have a look at the SDK API Lifecycle to understand which modules can be used. Some notable example are:
The new UI modules require FF29 and some of their features require FF30.
The widget module is deprecated from FF 29 onwards, being replaced by the above.
One way to handle the above for backward compatibility is to do the following:
const { version } = require('sdk/system/xul-app');
if (version < 29) var widget = require("sdk/widget").Widget({...});
else var button = require("sdk/ui/button/action")({...});
So, to be clear:
It doesn't matter which version of the SDK you use unless you want to use new modules.
No, you shouldn't make multiple versions of your add-on. If you want to use new modules for new browsers, follow the code example above.
It's true that you must use valid existing application versions but you generally don't need to repackage your addons, unless of course a change in the SDK directly affects your addons.
The reason for this is that by default the max target version is not going to be checked.
From the install manifest documentation:
strictCompatibility
A Boolean value indicating if the add-on should be enabled when the version of the application is greater than its max version. By default, the value of this property is false meaning that the compatibility checking will not be performed against the max version.
<em:strictCompatibility>true</em:strictCompatibility>
Usually, there is no need to restrict the compatibility: not all new releases will break your extension and, if it is hosted on AMO, you'll get notice several weeks in advance if a potential risk has been detected. Moreover, an extension being disabled, even for a short period, leads to a bad experience for the user. About the only time you should need to set this if your add-on does things that are likely to be broken by Firefox updates. You do not need to set this flag if your add-on has a binary component, since add-ons with binary components are always subject to strict compatibility checking (because binary components need to be rebuilt for every major application release anyway).
There is also is a recommendation for choosing version ranges.
minVersion and maxVersion should specify the range of versions of the application you have tested with. In particular you should never specify a maxVersion that is larger than the currently available version of the application since you do not know what API and UI changes are just around the corner. With compatibility updating it is not necessary to release a whole new version of the extension just to increase its maxVersion.
Technically you can use wildcards, but the documentation mentions several times that AMO verifies and possibly rejects addons with incorrect versions.
I had a situation where a user saw an error on her browser which is Firefox. It might be an older version. Is there a way to test multiple versions of Firefox without downloading a bunch of them?
You can use Utili Mozilla Firefox collection if you want to test your site in different versions of Firefox. It's really convenient - a lot of versions in one pack.
http://utilu.com/UtiluMFC/
(I'm not associated with this company)
cheers
I have a folder /browsers with custom versions of browsers, e.g. firefox, chrome, opera.
Then launch the different version when you need to test a specific version rather than launching the default one from your Applications.
*e.g. just rename the installed .app.
Chromium.app rename to e.g. Chromium_19.app need to disable auto-updates
Firefox.app rename to Firefox_38.app
firefox releases
Chrome releases
Opera releases
Multi Safari
Yes you can do this. I have gone through multiple links to find its solution. For example you want to install firefox 4.0 but want to keep 3.6 as well then you need to install Firefox 4.0 using the Custom Installation option, in a uniquely named folder — like /Program Files/Firefox 4.0/ — don't let 4.0 run after the installation procedure is complete.
Create a new profile exclusively for the 4.0 beta version and create a desktop shortcut with -P "profile" appended to the target to launch that profile.
Helpful links will be link1 and link2.
During the search I have also found one software utilu that may be useful, but clearly speaking I have not tried that yet, will try later.
there sites like these http://browsershots.org/. They let you test browsers without downloading.
If you're on OSX using Homebrew, you can install via brew cask:
brew tap goldcaddy77/firefox
brew cask install firefox-46
More info can be found at the git repo homebrew-firefox
I created a simple extension based on an existing one, but when I try to test it and add to Firefox manually I get this general error message:
<Extension Name> could not be installed because it is not compatible with Firefox <x.x.x.x>
How can I troubleshoot this?
I even tried setting maxVersion to a high value in install.rdf.
<em:maxVersion>150</em:maxVersion>
If you have verified that you have the correct minVersion and maxVersion, the other thing that can cause this is an invalid updateURL.
The Firefox bug about this is https://bugzilla.mozilla.org/show_bug.cgi?id=740378
If you are planning to host your add-on on addons.mozilla.org, you do not need an updateURL and if you are in the process of developing an add-on, there should be no updateURL in your install.rdf at all.
If minVersion and maxVersion are correct but your extension still doesn't install then these values are probably overridden. In addition to the values in install.rdf Firefox will also look up the update URL of your extension and get updated compatibility information from there. This information takes priority over whatever you specify in install.rdf.
If you specify an updateURL explicitly then you should update the information in the file it points to and clear the browser cache. If you don't specify an updateURL then by default it points to addons.mozilla.org. If an extension with the same ID and version number is found on addons.mozilla.org then its compatibility information is taken over. If that's the case then changing the version number in install.rdf to something unknown to addons.mozilla.org should be sufficient (obviously, you should also change extension ID of the extension hosted on addons.mozilla.org isn't yours).
Plus there is the bug mentioned by Mike Kaply of course - bad error message if an insecure updateURL is specified and no updateKey.
Your max version should look something like:
<em:maxVersion>17.*</em:maxVersion>
That indicates the max version of Firefox that supports the extension. Firefox 150 is a long way off! ;-)
Do you have the source code posted anywhere? I'd be glad to take a look. I've written a couple of Firefox extensions now, so I'm sure I can help.
First, check https://support.mozilla.org/en-US/kb/unable-install-add-ons-extensions-or-themes to see if any of those reasons apply.
With the release of Firefox 57 (14 Nov 2017), developers can no longer build "legacy" add-on .xpi files locally and load them in Firefox, only add-ons built using the webextensions API will load.
Hope this helps :)
I'm new to Firefox extension development, friendly speaking it's first day, I had followed the following article in order to start with Firefox extension development: How to develop a Firefox extension.
If I download the example from above given link's tutorial and try to install, it is installed perfectly but, when I update that example (just updating its name to the new extension name, where it is necessary in all files), and then install, I get the following message: "X could not be installed because it is not compatible with Firefox 15.0.1." (where X is the name of my extension).
Strange behavior same code one is installing fine and other one giving error.
Any idea where it is going wrong and what is causing this?
The problem is that you forgot to adjust the compatibility range in install.rdf so em:maxVersion is still saying 3.1b2 (meaning Firefox 3.1b2 - a rather old version). You should change that into 15.* if you want to support the current stable Firefox version or 16.* if you want to support the current beta versions. You can also change em:minVersion into something more meaningful: I doubt that you will verify whether your extension still works with Firefox 2.0.
As to why the extension installs if you don't change the extension ID, this is more complicated. First of all, there is a soft override mechanism for the compatibility ranges which allows extension authors to change the compatible version range without releasing a new version. In this particular case Firefox will check for extension updates by requesting this address or a similar one. The update server tells it that version 1.0 is still current but adjusts maxVersion to Firefox 8.0 - this value will override whatever is specified in install.rdf.
But that's not the end of the story. The compatibility check mechanism was changed significantly in Firefox 10, the default assumption is now that the add-on is compatible with newer versions even if that isn't specified explicitly anywhere. The requirements are that the extension doesn't opt out of lax compatibility checking, doesn't contain binary components and is compatible with at least Firefox 4. The original extension is compatible with Firefox 8 thanks to the soft override, with a different extension ID it is only compatible with Firefox 3.1b2 however (it isn't hosted on addons.mozilla.org so the update server doesn't know about it) which means that the lax compatibility checking doesn't apply to it.
For reference: the behavior described in the previous paragraph is controlled by the extensions.strictCompatibility, extensions.minCompatibleAppVersion and extensions.minCompatiblePlatformVersion preferences.
I wrote a firefox plugin using C++ and used the <EMBED> to load it to html.
In javascript I got the embedded plugin by using document.getElementByID,
but when I tried to call a plugin function, the function was undefined. Moreover,
plugins constructors did not run while loading the page.
The same html file and plugin seems to work on some computers, while it doesnt work on others.
Does anyone have an idea what might by wrong?
How can I debug such an issue?
Can you reproduce it on your computer at first? If not, then try to figure out what systems, browsers, architecture, versions, they are using.
I recall, there are many GECKOSDK's, and each one has a specific version it works for. https://developer.mozilla.org/en/gecko_sdk For example, different SDK's for Firefox 1.5-2.0, FireFox 3.0, Firefox 3.5, and Firefox 3.5
For different browers, make sure you are exposing the right DLL Exports, browsers can vary: http://git.webvm.net/?p=npsimple is a good starting point. You can use firebreath.googlecode.com too as an alternative.
My suggestion would be to use an object tag instead of <embed>. In my experience, doesn't seem to work as reliably.
If I had more information on how your plugin is structured (are you using XPCOM or npruntime?), I might be able to help more.