Another strange thing is that the maxVersion of the add-on as reported by the Mozilla add-on page might be different (newer) then the maxVersion that is actually set in the install.rdf of the add-on.
If you take a look at the FHC add-on page on mozilla right now it clearly states that version 1.4.0.6 works with FF version 22.0 - 50.* but when you download the extension and take a look at the install.rdf file the maxVersion is actually set to 49.0. Yet, while using FF 50.0 on my computer at the moment, the formhistorycontrol add-on is not disabled.
This is what mozilla says about updates:
Compatibility Updates
During the automatic update checks, applications look for both new versions and updated compatibility information about the currently installed version of an add-on. This means that if your update manifest contains an entry for the currently installed version of the add-on, and the entry'stargetApplicationentry specifies a larger maxVersion then the application will use this value instead of that specified in the add-on'sinstall.rdf. This can cause add-ons that are disabled for being incompatible to become enabled and add-ons that would normally not install to be installed.
So although the maxVersion is set to 49.0 at the moment, the automatic update check discovered the fact that the max version is actually set to 50.0 by mozilla (which you can verify easily by looking at the add-ons page using chrome for example).
This all leads to the fact that if you use a beta version beyond 50.* the add-on would be disabled since its compatibility has not been checked by Mozilla yet and the server-side compatibility bump has not been carried out yet to accommodate for that beta version.
So be careful when using beta versions, add-ons might be automatically disabled because their maxVersion has not been bumped to the lastest Firefox beta version. And using a beta version, you should know how to deal with these issues.
6 comments:
Also addon can be disabled because it incompatible with e10s (multiprocess), so will be good to improve multiprocess compatibility in next versions.
As much as I like to further develop the FHC add-on, the upcoming changes by mozilla make it very difficult, if not impossible, to keep this add-on compatible with future versions of Firefox.
The changes needed to make FHC e10s compatible are surely possible and probably not very hard to do (although it does probably take many, many hours of work to implement),
but the changes needed to make it WebExtensions compatible and maintain it's current features are almost certainly impossible.
The API's supported by WebExtensions do not include an API for accessing the formhistory which is the base for one of the core features of this add-on.
Furthermore this add-on relies heavily on XUL for the GUI and that is also gone under WebExtensions, so the complete GUI and all its interactions have to be rewritten from scratch.
According to the timeline of mozilla, it looks like WebExtensions are becoming the standard for add-on development in Firefox and will be the only type of add-on supported in Firefox by the end of 2017. (see https://wiki.mozilla.org/Add-ons/developer/communication)
All things considering I have to conclude that this Form History Control add-on has come end-of-life.
Showing formhistory data gathered by the browser itself (for auto-completion) was originally the main purpose of this add-on and it seems like this data will no longer be available to add-ons, so hopefully at some point in time this will be built into the browser itself by Mozilla. Maybe, if I can find the time and inspiration, I will start building a new add-on that supports (re)storing formhistory data from textfields and editor-fields since this new feature has often been very useful for me too.
Stephan Mahieu, thanks for detailed description!
Seems that Firefox move all API for extension from XUL to WebExtensions. So now will be good time to describe the problem and create feature request for developers: create functional in WebExtensions API for working with form history.
Can you create issue in Mozilla bug tracker and describe in technical language which functional you use now and it unavailable in e10s or in WebExtensions API?
I check now Lazarus: Form Recovery extension https://addons.mozilla.org/ru/firefox/addon/lazarus-form-recovery/ on Firefox 53 with e10s enabled and it works well - it save form history and can recover it.
But Form History Control not save anything.
Maybe you can look at the code and got some ideas how this works?
Also Textarea Cache https://addons.mozilla.org/en-US/firefox/addon/textarea-cache/ extensions saves form data normally in Firefox 53 with e10s
Tested this with FF Beta (52.0b3), FF Aurora/Developer (53.0a2) and Nightly (54.0a1). All editions except Nightly seem to work fine using the default FF settings.
At the moment FF still ships with Shims that help add-ons with compatibility so they keep functioning even when e10s is enabled (see: https://wiki.mozilla.org/Electrolysis#Add-ons_Schedule). As long as these Shims are present, my add-on should be okay. According to the Schedule this is the case up to at least version 53.
When the Shims are no longer provided, Form History Control and add-ons like Lazarus and Textarea Cache will definitely stop functioning when not adapted to e10s.
Regarding the Formhistory support in the new webextension-API: there was already a request to add it to the API a long time ago and, if I remember correctly, it was denied due to the fact that the API should be generic across all browsers and it was for instance not present in the Chrome-API. And that is the least of my worries, since moving from XUL to html would take the most amount of work.
Post a Comment