Skip to content
This repository has been archived by the owner on Jan 17, 2023. It is now read-only.

Test pilot web site not recognizing Firefox 63 #3989

Open
holmbuar opened this issue Nov 18, 2018 · 7 comments
Open

Test pilot web site not recognizing Firefox 63 #3989

holmbuar opened this issue Nov 18, 2018 · 7 comments

Comments

@holmbuar
Copy link

STR:

in Ubuntu 18.04.1 all updated and with Firefox 63.0.

  1. Sign in to Firefox account
  2. Open https://testpilot.firefox.com/
  3. Try finding install link with Firefox tracker cookie block enabled
  4. Disabling content blocking for test pilot site. Retry

Expected result:

  1. Being able to install Test Pilot by clicking "install Test Pilot" as described in 1.

Actual result:

  1. Get message "Test Pilot requires Firefox 63 or higher" above link to upgrade Firefox.
  2. No sign of a "install test pilot" link.
  3. Unable to join test pilot program
@holmbuar
Copy link
Author

holmbuar commented Nov 19, 2018

I solved it. After a tip in another Test Pilot issue I looked up about:config in the search bar. There I found privacy.resistFingerprinting and set it to false. Problem solved.

Still there is the issue about standard Firefox browser not giving access to a Firefox feature.

@holmbuar holmbuar reopened this Nov 19, 2018
@AfroThundr3007730
Copy link

I solved it. After a tip in another Test Pilot issue I looked up about:config in the search bar. There I found privacy.resistFingerprinting and set it to false. Problem solved.

Still there is the issue about standard Firefox browser not giving access to a Firefox feature.

Indeed. There really should be a way to override the useragent check and install the extension directly. Toggling the privacy.resistFingerprinting pref off just for the site is slightly annoying.

@SoftVision-PaulOiegas
Copy link

Please keep in mind that privacy.resistFingerprinting is not a default setting for the Firefox Browser. It's an optional setting that fakes your user agent for trackcking reasons, and that only the user or another add-on switches to true.
Also, this will happen with any add-on from AMO that does not support the version faked by this pref. So no, it's not just this site, it's every website that does not have backward compatibility with older Firefox versions and almost every add-on that Firefox provides.

@AfroThundr3007730
Copy link

I understand that, but AMO has (or used to anyway) a "download anyway" link when it detected an incompatible browser, to allow the user to pull down the extension. If I'm spoofing an older UA, Firefox would then install the addon, or if I was actually using Edge or something, I could still pull the XPI and sideload it into Firefox. I just think the site could do with a similar link for users who know what they're doing (and don't really want to build it from the repo).

@SoftVision-PaulOiegas
Copy link

Yes, it used to, but it was removed in the new UI. Probably to not encourage users to install obsolete add-ons or add-ons on obsolete environments.

However, I understand what you say, but it's not up to me (QA here). Sadly, as far as I know, the pref is rarely used by end users, so I don't think the development team will change the implementation since it's not a priority. But, we'll see their opinion on this.

@SoftVision-PaulOiegas
Copy link

SoftVision-PaulOiegas commented Dec 17, 2018

Still there is the issue about standard Firefox browser not giving access to a Firefox feature.

@torlarse I'm not sure we can consider this an issue since that pref fakes the browser user agent (simulates older Firefox version). Every Firefox add-on is conditioned by version, because some of them need APIs that weren't implemented from the start. It's the same case here, Test Pilot works only on Fx63 and up since one of the latest experiments released needs an API implemented only in Firefox 63.

The only way would be to somehow bypass this restriction if the privacy.resistFingerprinting is detected. But not sure if this is possible and will not guarantee that the user even has the right version of browser with this pref set to true. Which could lead us into more trouble, like having bad feedback from users that have the pref set on older browsers than 63 and are having major issues with the experiments installed.

@AfroThundr3007730
Copy link

I can certainly see how it can be a nightmare trying to circumvent a feature designed specifically to block exactly what you'd have to do: identify the actual browser version being used.

I still think that somewhere on the page (doesn't have to be prominent) the download anyway link should be present. I want to push to add this back to AMO as well, so I don't have to resort to UA spoofing to pull down an extension.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants