Jpm creates install.rdf with compatible versions range starting with 38.
If created addon which works on 38, is forcefully installed on Firefox 37.0 it fails (there are no obvious related errors in the browser console, plugin installation just has no effect except for addon entry on about:addons).
Can I still use jpm to create addons for older Firefox versions?
Is cfx indeed deprecated if its replacement can't create an addon even for beta channel of updates?
Should I continue to look for a bug in my addon which worked fine on 38 and on 37 (being built with cfx)?
no, unless you use an older version ( v.0.0.23 or below I think )
deprecation means we won't fix any bugs and are encouraging people to check out jpm - not that you cannot use it. Until Firefox 38 is released it is completely reasonable to use cfx to package extensions intended to be used by Firefox users.
I have no idea - you haven't really provided enough information about the bug.
Related
So I've been having an issue getting my Protractor/Jasmine tests running in FireFox. I've been aware of the version issue from FireFox that doesn't support selenium angular/bootstrap etc etc and that has been my issue to date.
I was informed to try geckodriver but really can't find any good resources on how to set it up using protractor and jasmine. Or even which driver is the appropriate one to use.
Recently I've tried the following to get FF back up and running (all resulted with no luck):
Downgraded FireFox to as low as 33.x.x while keeping
Protractor/Jasmine at current versions (4.0.5 and 2.51 respectively).
Downgraded Protractor to as low as 3.0.0 while keeping FF at current version (47.0.1)
Downgraded both Protractor and FF to the lowest above versions.
Used Latest Version of FF 47.0.1 with lesser versions of Protractor.
Used Latest Version of FF 47.0.1 with latest version of Protractor 4.0.5
Used directConnect: true and directConnet: false
So I guess now I have one of two questions:
1. Could somebody post a protractor config snippet using the geckodriver / or direct me to a walk-through of this.
2. Inform me of a work around or a working solution (versions of both webdrivers/protractor/jasmine, etc).
If you need to see errors or my config file or anything at all please just simply comment and I'll be happy to revise.
There was a period of time around Firefox v46 and Selenium v2.5x where things were incompatible due to changes to the firefox web-driver. The issues were quickly addressed by the community.
The issue with Protractor lies with the webdriver-manager being a bit out of date with the updates. As per discussions on github, they are aware of this, and a fix is coming.
The workaround in the meantime is to manually update the outdated pieces.
Here's how you'd do it, run
webdriver-manager update
This will give you the paths to all the components the webdriver-manager handles for you.
Navigate to the selenium-server-standalone.jar file (protractor/node_modules/webdriver-manager/selenium/selenium-server-standalone-2.53.1.jar in my case) and replace this with the latest selenium standalone jar (anything v3+ should be good). Make sure to retain the exact filename as the previous jar file. (link: http://www.seleniumhq.org/download/)
Repeat the process to get the latest Gecko web-driver. Uncompress and replace the current version. (link: https://github.com/mozilla/geckodriver/releases)
Now run your tests through protractor and you should be good with the latest version of Firefox.
Good luck and happy testing :)
After seeing that this is a problem with Firefox 35, I installed 34 and ran bundle exec rspec and my tests ran perfectly. But when I tried running it again, it somehow opened the newer version of Firefox as I get the following error again when I run my test suite:
Selenium::WebDriver::Error::JavascriptError: arguments[0] is undefined
Is there a way to guarantee that I don't have Firefox 35 installed that Selenium is somehow finding and opening? I know that Firefox 34 is the version of the Firefox in my Applications directory, but I am not certain there isn't a replica copy of a newer firefox that Selenium is grabbing when launchy is used.
This is a known issue with the current release of selenium.
As #janders223 points out in a comment on another question, the temporary workaround for a Ruby project is to use the dev version of the selenium-webdriver gem.
Modify your Gemfile to specify the latest dev version (as of this writing):
gem 'selenium-webdriver', '>=2.45.0.dev3'
Then run bundle install.
So, this is incredibly basic, but I found that when I had installed Firefox 34 via the dmg listed here, because I had naïvely just dragged and dropped the Firefox icon into the Applications folder clicking "Yes, I would like to overwrite the extant application" I hadn't ensured all of the newer files of Firefox 35 weren't available for Selenium to use, which Selenium availed itself of without me knowing which version it was choosing.
I simply uninstalled Firefox completely from my the mac by dragging it into the Trash, & reinstalled the Firefox 34 dmg.
N.B. Also if you run into this issue, when you download Firefox 34, you have to go to Firefox >Preferences>Advanced , click the Update tab, and choose "Check for updates, but let me choose whether to install them" or "Never check for updates" to prevent Firefox from automatically updating to Firefox 35 and therefore messing with your Selenium test suite the next time you run them again.
This problem also appearing in python selenium package nowdays. it is possible, that "arguments" appearing in code eventually. It can be solved simply by announsing all arguments at start in different var variables.
Approved answer showing this technique.
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 was reading the cfx tool documentation, about how to create an addon and make it autoupdade automaticaly. Unfortunately when I compile my addon to an xpi file with this line:
cfx xpi --update-link "http://mypage.com/firefox/latest"
--update-url "http://mypage.com/firefox/update_rdf"
I always get complains that the resulting xpi file is incompatible with Firefox 12.0. When I remove the --update-link and --update-url arguments the xpi file works. Am I missing something?
I saw this answer but unfortunately that solutions didn't work for me.
Two things you should do:
Make sure you are using the latest version of the Add-on SDK. Add-on SDK 1.7 declares the add-ons as compatible with Firefox 12 and 13, previous versions didn't.
Make sure to upload the generated update.rdf file to http://mypage.com/firefox/update_rdf, you probably have an older file there. This file also contains compatibility information for the extension and Firefox trusts this information more than install.rdf inside the extension (this is useful to mark an extension as compatible with a newer Firefox version without actually updating the extension package).