Does Firefox developer edition support Legacy addon development now? - firefox

It is mentioned that Legacy add-ons are deprecated(here). Though I am trying to make a very minor update to an existing add-on which is working fine on release channel.
I installed the add-on in the FF Developer Edition and found some issues:
document.commandDispatcher.focusedWindow.getSelection().toString()(to
get the selected text) is not returning the selected value with no
error.
The overlay window height and width is set using preferences but it seems to be not reading.

Yes it works for the moment and will probably continue to do so for at least another year at the time of writing. But developer edition runs with e10s enabled, so your addon is probably facing e10s compatibility issues which will also hit the release channel sooner than discontinuation of those addon types.
As immediate workaround you can disable it in about:preferences, in the short term you will have to fix those issues, in the mid and long term you'll have to migrate to newer addon frameworks.

Related

How to develop legacy Firefox add-ons in the future?

Firefox is moving towards the WebExtensions standard which promises improvements in stability, cross-browser compatibility, and more security. At the same time they're gradually dropping support for legacy add-ons (bootstrapped extensions, add-on SDK, etc.).
Unfortunately, the WebExtension APIs are much less powerful than legacy add-ons which by contrast have full control over the browser. I fully understand the motivation for the switch, but the features my add-on provides just can't possibly work with limited capabilities of a WebExtension.
What are my options to continue developing a legacy add-on with as few cutbacks as possible? How do other add-ons that won't work as a pure WebExtension solve this problem? Are there any niche projects dedicated to maintaining some sort of legacy extension "hack", or will I have to heavily modify Firefox myself to get any legacy add-ons installed in the future?
(I'm aware that I won't be able to submit my add-on to AMO or get it signed by Mozilla and that supporting full extensions is a potential security risk. But since my add-on is targeting a tech-savvy audience, I'm not too concerned about moderately complex workarounds.)
As the magic 8 ball says: "Cannot predict now".
The reality is that we don't know yet what is going to be required to continue to run non-WebExtensions based add-ons past the release of Firefox 57. All we know is that Mozilla has stated that for Firefox 57:
Firefox will only run WebExtensions.
AMO will continue to support listing and updating legacy add-ons after the release of 57 in order to have an easier transition. The exact cut-off time for this support hasn’t been determined yet.
It had previously been stated that the restriction to WebExtensions-only would only apply to the Release and Beta channels, so:
It may be possible to continue to run non-WebExtension based add-ons on:
Developer Edition
Nightly
Unbranded Release and Beta (unknown status)
It is currently unclear if these will actually be possibilities. If they will be possibilities, it is unclear for how long it will remain possible for older add-ons to function (both due to changes to Firefox and/or non-WebExtensions being intentionally disabled). The fact that AMO will continue to support listing and updates to non-WebExtension add-ons is an encouraging sign that we will still be able to use them in Firefox releases that are not the main Release and Beta channels.
Other options include:
The Firefox ESR 52 release. The pattern is that this would be supported through the normal release of Firefox 60, or so. Personally, I feel that Mozilla should plan to have an ESR release prior to any major changes in functionality (i.e. have a Firefox 56 ESR), but that does not appear to be how Mozilla does things.
The various forks that have been made of Firefox. Each fork would have to be checked to see what their plans are for this change.
Any new fork made specifically to continue to support non-WebExtension add-ons.
A hack may be determined to re-enable non-WebExtension support, similar to the one that exists to disable checking for add-on signing.
You should keep in mind that the plans are for Firefox to fundamentally change in the future. A significant reason for moving away from the more capable add-on types (non-WebExtensions based extensions along with complete-themes) is to allow Firefox to be changed without the need to consider maintaining compatibility with more capable add-ons which rely on the internals of Firefox for their operation. When, exactly, these breaking changes will be rolled out is unclear.
Personally, I'm in a similar boat. None of my released add-ons are possible to move to WebExtensions. Many of the other add-ons which I use are clearly not possible to move to WebExtensions. Frankly, I'm not looking forward to using Firefox without the capabilities some of those add-ons provide. Thus, I will be continuing to look at what options are available as we get closer to Firefox 57.
However, even if I find no option to use more capable add-ons after Firefox 52 ESR is EOL'ed, I may continue to use Firefox. My primary reason for doing so instead of switching to Chrome would be the fact that Firefox extensions go through a review process, whereas Chrome extensions released though the Chrome store can be very bad from the point of view of both security and privacy.
Regarding your question:
Are there any niche projects dedicated to maintaining some sort of legacy >extension "hack", or will I have to heavily modify Firefox myself to get any >legacy add-ons installed in the future?
Besides the previously said FF52ESR, at least, there are 2 alive projects based in Firefox code that are focused in keeping compatibility with legacy extensions.
Waterfox 56 (updated and compatible with legacy addons and webextensions)
Basilisk 201804 (updated and based in FF52, targeting v55)
On the other hand you have Palemoon 27.x which also is still under support but it is based in pre Australis FF interface, so it will be compatible with old-legacy addons.
Download and install latest Nightly Firefox (https://www.mozilla.org/en-US/firefox/58.0a1/releasenotes) (you can right click on the icon, hit Properties, and then add -no-remote -p to the Target address, as in "C:\Program Files\Nightly\firefox.exe" -no-remote -p which will then enable you to use more than one Profile)
In about:config (paste in address bar and hit Enter key) look for extensions.legacy.enabled and right click and toggle it to true in.
Download "anyway" the latest development version of TMP, (https://addons.mozilla.org/en-US/firefox/addon/tab-mix-plus/versions/0.5.0.5pre.171027a1) to your download folder (since Nighlty will not install it normally), then under File go to Open File and navigate to that file (with the /xpi extension) in your download folder, and install it, and restart Nightly.
Unlikely that this will work with the standard Firefox 57+ release, but TMP developer is working on the require rewrite. May God help him.

Firefox 35 - Flash no longer a default plugin?

I just installed Firefox on a new computer running Windows 8.1.
I usually use Chrome but recently I've been redesigning my website and today I tried loading it on multiple browsers to see if there were any problems.
It's a Flash games site with lots of flash ads. So when I went to my site in the new Firefox browser, I was surprised to see a lot of "plugin needed" boxes.
I tried loads of sites, and it became apparent that flash was not installed in the firefox browser at all. No Flash was loading.
Bizarrely, the grey box telling me I needed a plugin didn't give me any hint as to what plugin I needed, provided no link, and even blocked the fail-safe link to adobe that is displayed if flashplayer is not installed when using swfobject.js.
I tried searching for the flash player update in the firefox add-ons - nothing.
I tried searching on google and downloaded the general flash player update (http://get.adobe.com/flashplayer/) - installed it and nothing changed.
Eventually after 20 minutes of searching, I found this obscure page on Adobe:
http://www.adobe.com/products/flashplayer/distribution3.html
I downloaded and ran the exe for 'Plugin-based browsers' and this worked.
It appears the latest version of Firefox has deliberately not included Flash Player, which is utterly mad if that's really true.
However, I can't find any discussion or documentation that this is the case. But then why wasn't it included in my version?
Does anybody know anything about this?
Firefox has never included Flash, you always need to go to http://get.adobe.com/flashplayer and download the Flash Plugin on your first install of Firefox. Make sure that you turn on autoupdate for Flash by using the Flash cpanel app in your Windows Control Panel. Then check regularly to make sure Flash is still autoupdating. It can have a bad habit of failing.
It's only recently that Microsoft includes Flash and only on IE on Windows 8+ as a copy of Google's attempt to increase Flash security by including it in Chrome some time back. IE gets its Flash updates through Windows Update when Microsoft gets the patches applied.
Google is the 800lb gorilla that gets what it wants and twisted Adobe's arm to force them to supply Flash code so they can do their own updates via their Pepper Flash module which updates when Chrome autoupdates.
While Mozilla will warn you that Flash is out of date, they do not have the monetary clout like huge corporations (Microsoft, Google) to force Adobe to give them source code so they can fix Adobe's security sieve as it happens.
Mozilla has chosen to promote HTML5 and open DRM to hurry the eventual demise of a piece of Macromedia Legacy web extensions that has been plaguing us with serious zero day exploits (Jan-Feb 2015 most recent) that often appear back-to-back and often get 2 try patch releases in the hope that it gets fixed.
And in that same timeframe, often Chrome and Windows 8 versions of IE have a similar lag to bug fix, though a lot quicker than Adobe.
Get in the habit manually checking Chrome's version, Chrome can suffer update failure despite its automatic update feature.

How to handle different versions of a Firefox Addon in different Firefox versions

I've programmed an addon for Firefox. In the "backend view" of the Firefox addon store I now see the message, that my addon is no longer compatible to Firefox starting from version 30.0 (see screenshot1).
A quick look into the new API told me what to change and so I did.
But how can I make shure, that useres with a Firefox 29.0 or older will still get the "old" version of the addon, and users surfing on Firefox 30.0 and newer get my updated addon?
Does the shop backend makes that choice? Because when uploading new addons I can set the supported versions of Firefox (see screenshot2).
And how to increase the addons id? Now it is set to 1.0.0. Should I go with 1.0.1 or should I leave some "space" for updates to the "old" version and start with 2.0.0?
I'm confused. Could anybody please help me? Thanks in advance!
Bye
Niels
Sometimes these incompatibility notices are false alarms (this seems especially the case with version 30) and sometimes the resolve spontaneously because Mozilla runs batch tests or the like. If the compatibility issue is with (say) widgets vs. ActionButtons, there are ways to accommodate both levels of FF version support with try...catch structures.
This is what an AMO developer answered via mail:
AMO should offer the right version depending on the browser version
you're using. In the worst case, users can click on the All Versions
link and see past versions that can be installed.
So I uploaded my updated extension and set the browser-compatibility to Firefox 30.0 and higher.
You can include separate code for different FF versions if you want Chrome registration - appversion
Here is an example from GreaseMonkey chrome.manifest:
overlay chrome://browser/content/scratchpad.xul chrome://greasemonkey/content/scratchpad-overlay.xul appversion<23.0
overlay chrome://browser/content/devtools/scratchpad.xul chrome://greasemonkey/content/scratchpad-overlay.xul appversion>=23.0

Watir-webdriver: Safari

I've recently started using watir-webdriver and so far am a big fan. However I need to be able to test Safari too, and I don't have access to a mac to be able to use Safari-Watir.
Does anyone know a good alternative to use for testing Safari on a windows machine? (In Ruby of course)
Thanks
(important, see UPDATE below)
the Selenium Webdriver folks are apparently waiting for something from Apple in order to support safari. I would not hold your breath.
Apple does have a version of Safari for the PC, I'm not sure how good the current version is, the initial releases were.. um, well, lets just say they had issues (lots of issues)
Personally (mostly for security reasons) I would not run it nor recommend anyone use it for any purpose other than downloading Chrome or Firefox. But unfortunately a lot of apple users use it because it's what came with their systems, which means to the extent apple users are part of your target market, you have to test on it.
For the moment that means you'll need to use Safariwatir, which has not as far as I can tell had an update for a year or more.
the current state of support on both the Selenium/Webdriver side and the Safariwatir side was discussed recently in this thread in the watir general group on google
UPDATE
Webdriver now has Safari support, which makes direct support of safari (I think on a mac only at this point) possible. See http://watirmelon.com/2012/04/17/using-watir-webdriver-with-safari-at-last/ for more info.. still a bit DYI but I'm sure it will get more accessable soon.
Mike, seems this is available now. Alister Scott wrote up some instructions on his blog Using Watir-Webdriver with Safari At Last
Unfortunately this still a bit DYI because you have to build your own safari extension, which requires getting certificates and such from apple, and I'm not sure if you can create the right environment to build that stuff on anything other than a mac.

Are there any standard one-click install/lauch mechanisms for the web?

The reason I ask is mostly due to how Google Chrome installation works once you click the "Accept and install" button from Firefox. After you click the installation is started directly and when it's completed Chrome itself starts up.
Firefox does not show any "Save" or "Confirm" dialogs after you click the Install button (on Chrome install web page).
Now, is this standard behaviour? Or might it be due to having an old version of Chrome already on the computer (Note: The new version was still installed from Firefox).
Seems a bit risky to me, all you have to do is fool the user to click something and then you can do whatever you want on his machine, or? Personally I thought things like this only worked with IE/ActiveX.
Looking at the code of the chrome download page, they seem to be using three mechanisms:
Standard download
OneClick (using the google updater plugin)
ClickOnce (using the .NET Framework assistant plugin)
ClickOnce is widely available due to the pervasiveness of .NET 3.5 SP 1 (in which it is bundled).
This is absolutely not standard behaviour. It looks like it is some kind of extension in Firefox. This will not work in Opera, IE or Safari. For those they might use different methods. For IE maybe ActiveX. The rest just downloads a small setup file.
Microsoft has a propritary solution which is always included in their development programs, called ClickOnce. It needs .NET Framework. .NET Framework installs a Firefox extension for ClickOnce, and for everything else you can just run the setup.exe.
Google's updater is standard and open source, (called Omaha) but there are no open source server implementations as yet. It can be found here.
The way I understand it working is that when you download a file you trigger the updater with an ID and it takes care of the installation and maintenance of the program.
(speculative) I suspect the old installation or rather its updater took over at that point. As for the risk: If the Chrome guys did their homework (and I suspect they have), then Chrome will check for signatures on the file, etc. before running anything. That's standard behavior for updaters (sane ones, at least) and prevents abuse at that point.

Resources