As you know Firefox extensions can get broken when newer versions of FF are released, i.e. Firefox makes changes to extension requirements.
Is there a list/resource/forum board etc, that describes what these changes are?
Especially since many of the "getting started" tutorials were written along time ago. now it is hard to know which requirements have changed and which are still the same.
Each significant update is listed in the release notes for developers at https://developer.mozilla.org/en-US/Firefox/Releases. This includes information for web and add-on developers.
The best way to stay up-to-date is to follow the blog at https://blog.mozilla.org/addons/, which frequently publishes about changes affecting Add-on compatibility, AMO statistics and so on.
Related
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.
I am working on a XUL desktop application, where I use the browser tag and load a URL in that tag within the desktop application.
However, some websites display as old format and according to Mozilla, XUL is deprecated and will not be useable at the end of 2017. I want to build the application with the latest technology: WebExtensions.
I have searched many examples on the usage of WebExtensions, but all are working within the browser. Can I make a standalone desktop application just like XUL, but using WebExtensions?
If yes, then please give me some hints on how to get started.
If no, is any alternative for the same requirement available?
Webextensions are fairly limited in their scope. Even if there was an application runtime utilising them, you probably wouldn't get much use out of them due to the restrictive isolation from the host system.
Strictly speaking not webextensions, albeit very similar:
The Electron framework/runtime*
Someone at Mozilla is also working on an alternative dubbed "Positron"** though that software's future is uncertain and there is a chance he might abandon it for an entirely new, highly simplified project (at least that's what I gathered from my conversation with him on Github).
*http://electron.atom.io/
**https://github.com/mozilla/positron
I'm aware this isn't exactly a programming question, but it directly impacts our developers and the code we're assigned to write. If there's another SO-like forum where this could be better posted, please let me know and I'll take the question down from here & post it there.
Our work environment is a couple of developers creating (20-30%) and maintaining (lion's share) legacy software for factory production floor and test workers to use to calibrate or test the equipment the company sells. We've implemented a very simple Google form based bug reporting page, but we're already running into problems of scale (approx 40:1 them:us and lots of old-old buggy software that we didn't write). The company has tried using Bugzilla before my arrival with little success, the factory folks were apparently intimidated by it and wouldn't use it. However, they seem to like the simple Google form and the wizard-like steps to file a bug or request a feature. We're currently manually cutting & pasting their bug/feature requests from the Google form spreadsheet into Trac, and manually tracking the bugs/feature requests on a white board with magnetic bug cards. We're only a few weeks into this system and it's already showing it fragility and lack of scalability.
Ideally we'd have a Windows >= XP web or desktop client that would provide:
Simplified bug reporting, a Wizard like approach seems to work well
Customizable for our software packages (like drop downs for each)
Bugzilla or Trac integration
Standard bug tracking features developers and management can use
I've found the winners of the "Make Bugzilla Pretty" contest, but coming from a pure software house where we just used straight Bugzilla out of the box, I'm unclear on how to configure and install these skins. Obviously I can figure this out but don't want to go down that path if it's not going to solve our basic problem which is non-technical people reporting bugs.
TaskCompiler, found on the Bugzilla wiki site seemed like a candidate because it talks to both Bugzilla & Trac, but their sales page is offline and the site hasn't been updated since 2012 and I'm unsure as to their viability.
I'm certain we're not the first production facility to run into problems like this, I'm looking for recommendations to help solve both our scalability as well as-ease-of-use problem.
Another thought that occurs to me is a GAS script to push our current Google forms based bug reports into Trac or Bugzilla.
Edit: The decision between Bugzilla/Trac seems to have been made for us. I'm exploring options for using Trac here if you want to follow along.
As the question states, I am preparing to deploy my first couple modules on the Magento Connect store and want to make sure I am targeting the best versions. Testing on 1.3 is proving to be a bit of a pain, and if only a few people use that version I would rather spend the time making the modules better!
Google hasn't helped as yet, though I think the keywords I use are getting picked up as other more specific technical questions (Google Base, for example).
Does this information exist? What about your personal experience? For me, I have only encountered installations below 1.5 Community (1.10 Enterprise) for upgrade projects. I haven't personally encountered a client that is on 1.4 and plans to stay on 1.4.
Thanks!
Tim
There are a signification amount of people who have older versions and wont upgrade because of the complexity and the amount of modification they have done to their stores.
Most people right now who are on community version seem to be on 1.5 or 1.6, but if you want to test older versions just download from the archive install locally and see if it works for the older versions.
Here is a link to the downloadable versions of magento, in case you decide to test on those older versions:
http://www.magentocommerce.com/download - click released archived tab at the top
I want to develop Safari plugin using xCode, What API should I use? Someone can give me some documents or sample codes ,Thanks very much!
The answer is rather complicated i'm afraid.
Unfortunately, Safari the web browser does not have a plugin API. That means you technically cannot extend Safari's user interface or features using plugins.
However, WebKit the web rendering engine (which powers Safari and many other browsers/apps) does have a plugin API (actually it has 2) which allows you to create plugins for rendering web content inside webkit webviews.
You can find documentation on developing WebKit plugins in Apple's docs here. (PDF Link!)
Also note: Safari's lack of a true plugin API has not stopped lots of developers from developing various pieces of software which they call "Safari plugins" even tho they are technically not Safari plugins. They are usually something called an "Input Manager" which are widely viewed as rather questionable pieces of software. Input Managers always seem to be on the cusp of becoming unsupported or broken by Apple. It's not really clear whether Input Managers are kosher with Apple or not.
Then again, several "Safari plugin" Input Managers are quite popular, so....
Input Managers are a whole other topic. I'm sure if you google it you can find a lot of information on them. However, personally I would advise against developing an Input Manager due to their questionable status in the Mac software world and their constant danger of becoming unsupported or badly broken.
Update: A few years after I originally answered this question, Apple did provide a sort of plug-in API for the Safari browser itself. However, they are called "Extensions", not plug-ins.
See the Apple Safari Extension Programming Guide for details.
Check out Rentzsch's ClickToFlash, it's a plug-in that is fairly well documented, along with neat source code.