I have a Firefox add-on (not distributed via AOD) that was supposed to be active (in that version) only with Firefox up to version 50, cf. This snippet is from my install.rdf:
<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<em:minVersion>35.0</em:minVersion>
<em:maxVersion>50.0</em:maxVersion>
</Description>
</em:targetApplication>
I intended that, when a user updates to Firefox 51, this add-on would be automatically disabled (at least until the add-on is updated as well). However, I noticed that this was not the case: The add-on was still active, even after Firefox restart (which had happened during the update anyway).
Is there something wrong with the versioning I did?
The maxVersion property is ignored unless you also set strictCompatibility:
<em:strictCompatibility>true</em:strictCompatibility>
MDN says the following about 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.
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).
I have updated the targetApplication section of the Install Manifests page on MDN to state that strictCompatibility is required for maxVersion not to be ignored. While this interaction was stated in the strictCompatibility section, the above quoted text is not something that would be found by someone only checking what is needed for maxVersion.
I suspect that this situation came about because of the evolution of the instal.rdf file and how handling of maxVersion evolved over time. Unfortunately, it has resulted in a situation where a property, maxVersion is required, but ignored.
The equivalent of this in a WebExtension is the "applications": {"strict_max_version": "50.*",. The strict_max_version value is enforced for WebExtensions.
Related
I know most projects have minimum versions defined in bower.json for a lot of libraries.
Something I don't understand is that would this be risky that if something updates and have break-changes or bugs, it will affect your application without you knowing it? What is the design thinking behind this?
Thanks!
We have just faced that exact issue on a project I am on, and the solution was to change our bower.json file to target fixed versions.
Specifically, we were targeting angularjs ^1.4.8. In AngularJS v1.6,
$location now uses '!' as the default hash-prefix for hash-bang URLs,
instead of the empty string
For better or for worse (mostly for worse) we had some hard-coded urls in a different application that pointed to this project that broke once bower automatically installed AngularJS 1.6 as part of our automated build process.
The solution was to simply lock down our versions rather than relying on the latest bug fix (i.e prefixing version numbers with ~) or minor build (i.e. prefixing version numbers with ^).
I think the reason that package managers like bower and npm default to dynamic versions is that they rely on semantic versioning, and in theory you should only encounter breaking changes when the major version number changes. Semver uses a major, minor, bugfix pattern. When the bugfix value is incremented it indicates that one or more backwards-compatible bugs have been resolved. When the minor version is incremented it indicates that new backwards-compatible functionality has been added. When the major version is incremented it indicates that new, breaking changes have been introduced.
The problem with this is that firstly, it relies on the package developer to respect the semver rules when they make changes to their packages, and secondly, even when semver is respected it can still lead to problems (as in the example I provided above).
I have an MVC application that uses .NET 4.5. I debug it locally and then I publish it to a remote server. The local copy has validation messages in polish, but the remote one has them in english. I've added <globalization culture="pl-PL" uiCulture="pl-PL" /> hoping it will fix the issue, but outside of switching inputs/displays to localized date and float format, nothing changed.
After that I have manually set in IIS' site setting .NET Globalization both Culture and UI Culture to Polish (Poland) (pl-PL) (both of those were set to neutral for some reason) and made sure that Enable Client Based Culture is set to false. That didn't help either (even after restarting the site).
I've seen this problem mentioned a number of times on the internet, but with no working solutions. Nonetheless, one of the threads that I found about the problem suggested that .NET 4.5 is missing the proper language pack. This would seem like an easy problem to fix, yet I have found it impossible to install any language pack on my remote server.
The remote server is running on Windows Server 2012 (seems to be the english version). When I try to install .NET 4.5 language pack I get an error message saying that .NET 4.5 is already installed.
I also found language pack for .NET 4.5.1, but this one also greets me with an error. This time it's a different error though, it says that my system language is incompatible with the language pack's language and I need to either switch my OS to different language or install a language pack. I checked control panel if it is perhaps possible to switch the OS language, but as expected I can't really do that. As for language packs for Windows Server 2012, there is one, but it isn't available for mere mortals. It's only available for members of Microsoft Partner Network program.
Has anyone had the same problem and resolved it or can anyone give me some clues as to what I'm doing wrong here?
Since the fix was preformed by someone else, I cannot describe the exact process, but I'm reposting the general instructions as an answer.
Contrary to what I believed, it appears that it is possible to change the language of Windows Server 2012 in control panel, it's just the option wasn't very obvious to me. Switching this option makes the system do a big patch which might leave you with no .Net runtimes (and possibly other libraries, system tools). Although you might be forced to reinstall those, thankfully you should be able to do so in the language of your choice. When I have time to test it further, I'll post more info as an answer.
For now, if you have a similar problem,
Try going to "Control panel"
Open "Clock, Language, and Region" section
And then the "Language" subsection
Within this section make sure the language, that you want your .Net (and validation messages) to be in, is there.
If it's not, just add it and follow to the next step:
Click on the "options" hyperlink(like) button (on the right of your language row)
Wait for the "Windows display language" section to load (previously I didn't bother to do so and missed the next option as a result)
Pick the "Download and install language pack" option and follow with the installation (it might take a while)
After doing this, it should be possible to install the correct language pack for your .Net.
I'm looking for the tool for accessibility check (the system I'm working on should comply with WCAG2AA).
At the moment we use a code sniffer from squiz labs, which we manually run against our pages.
I would like to take it a step further and have it as a part of TFS gated checkin.
I'm aware this is not as trivial (we use ASP.NET MVC) and will require a browser engine to generate html as part of the same process. There also might be situations when a suppression would have to be added, etc.
Would be grateful if someone could point me in the right direction or maybe there is already a tool (in that case probably combination of tools), which I'm not aware of.
Accessibility checks can't be entirely made by automatic tools (it needs a human to decide if these headings make sense in a page for example), but it's still a great help for half of the tests you've to run.
I'm aware of:
Tanaguru, an open source solution that you can install (Java Tomcat thing) or run as a service. It'll check against your source code (before any DOM modification) many tests from Accessiweb reference list, an understandable (pun intended) implementation of WCAG2.0. The silver level is equivalent to AA level of conformance.
For Tanaguru service, you can provide a test login and password if your server is private and for the standalone code, being open source you can add it to your development process the way you want.
You can test Tanaguru here: http://my.tanaguru.com/?lang=en
WAVE Toolbar will run against code in your browser. This is a Firefox extension, beware that http://wave.webaim.org/ will check HTML code sent from server, not in the browser (the difference is about JS modifying the DOM)
Opquast is both a checklist about quality (accessibility and many other things unrelated, check it at least once it's worth it ;) and a paid service: Opquast reporting. You can run your pages against the Opquast checklist or Accessibility first steps and second steps (this is not WCAG 2.0, it's about the errors that are so obvious you should have repaired before going further with accessibility improvements).
Opquast reporting will export results as PDF, DOC/ODT as well as CSV so you can use it with your own automated test environment.
EDIT 2014: Opquast Desktop is a Firefox extension that'll test pages in your browser (there were a few quirks with Win8, be patient if it's still the case and they aren't on AMO because Mozilla will change their requirements overnight... but knowing personnally and having worked for the awesome team that is behind Opquast, I trust them)
Tenon.io by K. Groves is a new service I barely tested till now, but it's worth checking it
Related article: http://webaim.org/articles/freetools/ (quite old if it doesn't speak of WCAG 2.0, but formats and such are still an interesting read)
While testing the downgrade functionality of one of our WiX-built MSIs, I have noticed something odd.
I have allowed downgrades in the MajorUpgrade element and I have scheduled that element to be afterInstallInitialize (but I have tried it thoroughly with afterInstallValidate and I experience the same problem; we can't have it after that action, but I thought I'd test it).
Many of the files (e.g. the DLLs in our Service's bin folder) are of a higher version, with each release; therefore, the version we are downgrading to includes files of a lower version. Yet all of those files are installed fine, during the downgrade, apart from the Service EXE files; further, the Services are also not installed in Windows.
Considering all of the above, after spending two days on this problem, and after much searching, I appear to be at a loss.
I have tried two things that seem to provide some hope:
1) I have tried setting the REINSTALLMODE property to amus. This ensures that the EXE files are installed, along with the Windows Services. But most things I read about that property warn against using it, and I even have to surpress ICE40, in order to get my package to build, when setting that property. This all concerns me, as I am not sure what negative effects could be missed, if I use this property in my MSI files.
2) When I remove the KeyPath attribute from the File elements that mark up the Service EXE files and place that attribute on the Component element instead, the Service EXE files are installed onto the system during the downgrade, but the Services are still not installed in Windows. After looking into this, it seems that the KeyPath attribute must be on the File element, if I'd like Services to be installed. So it seems to me as if this idea will not help.
Any help or advice would be very much appreciated. We really could do with providing downgrade functionality.
Thank you all for your time.
MSI is essentially opposed to the idea of downgrades. Once a file is on the machine, MSI tries very hard to keep the latest version of the file around as, among other reasons, downgrading the file can re-introduce a security vulnerability. I'd suggest not directly supporting downgrades; instead, you can show a message that tells the user to uninstall the higher version first.
My solution was to use Burn to provide the 'downgrade' functionality using a custom bootstrapper application.
The bootstrapper detects, downloads, and then installs the new version. In the case of a downgrade it performs an uninstall prior to the install. However, this requires that you execute the bootstrapper of the currently installed version to get the ability to uninstall.
You then also need to worry about any state that will be removed as a consequence of uninstalling, this needs to be preserved the same way as you would during an upgrade.
Using Wix, to allow downgrading and still have the Windows Service install properly on downgrade, use the following combination:
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
<MajorUpgrade Schedule="afterInstallInitialize" AllowDowngrades="yes" />
I was also using WixSharp to generate the .wxs file and used this code to do so:
// https://learn.microsoft.com/en-us/windows/win32/msi/reinstallmode
// a = Force all files to be reinstalled, regardless of checksum or version.
// m = Rewrite all required registry entries from the Registry Table that go to the HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT registry hive. Rewrite all information from the Class Table, Verb Table, PublishComponent Table, ProgID Table, MIME Table, Icon Table, Extension Table, and AppID Table regardless of machine or user assignment.Reinstall all qualified components.When reinstalling an application, this option runs the RegisterTypeLibraries and InstallODBC actions.
// u = Rewrite all required registry entries from the Registry Table that go to theHKEY_CURRENT_USER or HKEY_USERS registry hive.
// s = Reinstall all shortcuts and re-cache all icons overwriting any existing shortcuts and icons.
project.AddXml("Wix/Product", "<Property Id=\"REINSTALLMODE\" Value=\"amus\" />");
// Allow downgrading versions
// https://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
project.AddXml("Wix/Product", "<MajorUpgrade Schedule=\"afterInstallInitialize\" AllowDowngrades=\"yes\" />");
See also:
https://learn.microsoft.com/en-us/windows/win32/msi/reinstallmode
https://wixtoolset.org/documentation/manual/v3/xsd/wix/msiproperty.html
https://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
Background info:
Over the past week, I have been messing around with Chrome extensions and had no problem creating my extension. Great, Chrome rocks for making the development process very easy to learn, and, well... just easy!
Now I have it in my mind that I'd like to create this extension for as many browsers as I can, so I decided on Firefox next.
What a mess! There documentation has done nothing but give me a headache and waste my time so far, VERY convoluted and just generally unorganized.
I have managed to locate a code sample for a simple extension that I think I can use as a starting point and have begun messing around with - fine...
I have learned that this sample extension will not work with anything less than Firefox 4, as it uses the bootstrap technique to make the extension installable without a browser restart. Ughhhhhh....
Now we arrive at my questions:
Is it possible to develop an extension for Firefox 7 that will work with previous versions of Firefox? I don't even care about anything prior to Firefox 4, if that's the cutoff point for restart-less installations. It would be nice to know that what I am spending all this time making will work consistently and for more than a week when the user is prompted to upgrade next.
How about the reverse? Can I create an extension that is compatible with Firefox 3.5 through Firefox 7? I realize it would require a restart to install, but that would be acceptable if it resulted in a working extension regardless of the version.
Can anyone with experience on this stuff share a bit of what I'm getting myself into here? It seems like this is a nightmare of a platform to develop on, and that I will be constantly fixing my extension.
One last piece of relevant information:
The extension I am developing is purely javascript based - this stuff should work (I think?) because it's dependent on just one feature "content scripts" that really shouldn't be changing in implementation between versions at this point... right?
So what exactly am I missing? How do you create easily manageable Firefox extensions that will work in all versions of the browser?
Thanks everyone! :)
You have to distinguish between "traditional" extensions and extensions built with the Add-on SDK. The former are far more powerful given that they have direct access to all APIs the browser uses - but that's also the reason why they are more complicated to write and why the documentation is rather unordered (there are simply very many things that you could do, far more than you could with Chrome). They are also more likely to break as the browser changes. The Add-on SDK on the other hand gives you a limited API much like Chrome. The Add-on SDK currently supports everything from Firefox 4 onwards (yes, because of restartless installation), with the promise that browser changes will merely require your add-on to be recompiled with a newer version of the Add-on SDK. In fact, that recompiling will likely happen automatically in future for add-ons hosted on addons.mozilla.org. On to your questions:
Is it possible to develop an extension for Firefox 7 that will work with previous versions of Firefox?
Sure it is. The Add-on SDK currently marks your add-on as compatible with anything between Firefox 4 Beta 7 and Firefox 8 Alpha 1. Even as traditional add-ons go - starting with Firefox 4 the differences between particular browser versions are rather small, most things work in all of them. You can also stay compatible with Firefox 3.x but depending on what you do it might require some effort. Important information:
Firefox 4 for developers
Firefox 5 for developers
Firefox 6 for developers
Firefox 7 for developers
How about the reverse? Can I create an extension that is compatible with Firefox 3.5 through Firefox 7?
It doesn't matter which way you go. I wouldn't recommend spending much time on Firefox 3.x support however. With Firefox 3.5 no longer supported the only relevant version is Firefox 3.6. According to the statistics of my add-ons roughly 18% of the Firefox users continue using it. In the next few months this percentage will get significantly smaller, especially when Mozilla announces end-of-life for this branch. So for a new add-on supporting it is usually not justified.
Can anyone with experience on this stuff share a bit of what I'm getting myself into here?
Depends on how complicated your add-on will be. Given that you are developing an equivalent to a Chrome extension, you will most likely be using the Add-on SDK which means that there won't be any compatibility problems. As traditional add-ons go, simple add-ons that don't rely on some obscure implementation details also typically don't have any trouble staying compatible (I have two add-ons that didn't need a single adjustment since Firefox 3.5). Add-ons that go deep down into the system are more problematic of course.