Jump to content

Build Mismatch Error in the Chrome Browser Extension


Ryan Coyle

Recommended Posts

Hi All,

 

We are getting a build Mismatch Error in the Chrome Browser Extension, I know this is from the push today for the extension and the api update so you need to update the extension.

 

I seen there was a couple of topics created for this but I haven't seen a resolution.

 

Do you recommend doing the following to stop this chrome browser extension automatic update?

 

on Windows: C:\Users\<USERNAME>\AppData\Local\Google\Chrome\User Data\Default\Extensions\<EXTENSION-ID>\<VERSION>\manifest.json (find out the extensions ID by enabling developer mode in the extension settings page)
on Ubuntu for Chromium: ${HOME}/.config/chromium/Default/Preferences

In this file set "update_url" property to something invalid like https://localhost 

 

If not could we request an email in advance so we know when these updates will happen so we can let everyone know that we need to update the application?

 

Best Regards

Ryan

Link to comment
Share on other sites

Hello Ryan,

 

On the 19th of August, we emailed all customers letting them know of an upcoming release of our Chrome browser extension. Chrome, unlike Firefox, automatically upgrades all extensions within an hour of their release – Google do not provide an option to turn of these automatic updates unfortunately.

 

For the new browser extension to work, Passwordstate needs to be upgraded to at least Build 8782, and our most current build is 8792.  If your extension is not working, then please use one of the methods in this document to upgrade Passwordstate and it will start working again: https://www.clickstudios.com.au/downloads/version9/Upgrade_Instructions.pdf


We did try and give our customers as much notice as we could giving them the opportunity to upgrade Passwordstate during the beta phase, or at least get their change control processes underway.

 

If you would like to submit a feature request to Google, asking for an option to prevent automatic upgrades of extensions, you can log that on their community forum here - https://support.google.com/chrome/community?hl=en 

Regards

Click Studios

Link to comment
Share on other sites

I put forth a a feature request which was already archived with a similar response.  I would say that my suggestion to have a "Latest" and "Previous" version of the plugin available in the stores could have used more consideration Clickstudios.  I see in the extension stores where stable and beta versions of plugins are available for many.  I don't see a fundamental difference here for my suggestion but Clickstudios said they don't believe the stores allow this.  Here's a link to the other thread which I can't reply to

https://www.clickstudios.com.au/community/index.php?/topic/2849-browser-extension-multiple-versions/

 

 

Link to comment
Share on other sites

Hi cwaters,

With your reference to "stable and beta versions", do they allow more than one stable - can you point us to where it says this? And if they do allow multiple stable versions, how would you select which version in Chrome you wish to upgrade to?

Regards

Click Studios

Link to comment
Share on other sites

Below is a random example from the chrome store.  Basically, they are 2 separate extensions.  You can find a lot of examples by searching for "beta" in the the store, and then redo the search to use the base extension name of one you find.  In many cases, you'll see examples like below.  Full disclosure that I haven't found anything that says you can/or cannot do this in the store but it seems like a quite a few devs do this.  I assume when they are done with beta, the move the code to the non-beta plugin reference.  I suggest something similar could be done when you release the latest version, you move the previous version to "-previous" extension.  

 

To be clear, I'm just making suggestions and likely don't have full understanding of the processes involve.  That said, as a customer, this has the potential to be a very large problem for me so I'm hoping to have something relatively easy for an end user (or 1000) to do if we for some reason can't complete our internal upgrades before a new version of the extension comes out even if it's a temporary, somewhat kludgy work around of (please install the -previous plugin from the store until we complete our internal testing).  I see a lot of references to folks asking the same question about how to disable auto-update for extensions in chrome with not much traction.

 

I do appreciate the support and discussion.

 

@Ryan Coyle sorry to hijack your thread.

 

image.thumb.png.f3b0d3ba9073452fad41f9af4ce46030.png

 

Link to comment
Share on other sites

Hi cwaters,

Rarely do we offer Beta's for our extensions, and we provide these to customers to load outside of the store if they wish to test it. I really don't think you can have multiple stable versions in the store, and having betas in here would not help we do not believe - as soon as we release an update to the stable version, it will be pushed out to all browsers.

All we can recommend is customer log feature requests for Chrome, to give you the option of not "auto-updating" extensions - Firefox provide this, and we're surprised Google do not offer this.

Regards

Click Studios

Link to comment
Share on other sites

I think you're focused on the word beta and not the intent.  I'm not suggesting you release a beta version in the store.  The beta moniker is just a naming convention that demonstrates that these developers have more than one plugin in the store for the same thing.   I can choose to run the beta or the stable.  I have the option to control the version in that sense.  In the same way if there were 2 different Passwordstate extensions in the store (you could name them anything you wanted), I would have the option to use the current Passwordstate plugin, or the previous.  It's just a convention.  I find references for the feature to be added for chrome going back to at least 2010.  If 9 years of requests with no change means anything, it seems like that will be a loosing battle.

 

If it's not really feasible for you or you just don't like the idea, I get it.  I'm not trying to push too hard, I'm just hoping I was able to convey the idea properly.  Thanks again.

Link to comment
Share on other sites

Okay, yes we understand.

 

For this to work, everyone of your users would need to uninstall and re-install extension versions when they are released, and you maybe get build inconsistencies if your Admins upgrade Passwordstate, but not the extensions. So we're not sure which approach is the best user experience.

 

What about my suggestion for deploying the extensions via group policy - this will give you exactly what you need?


Thanks for your suggestions though.

Regards

Click Studios

Link to comment
Share on other sites

I agree, the extension swapping isn't ideal, but it would provide a structured and repeatable process for a user to follow if we end up in that situation that would apply equally to all users, regardless of OS.  The alternative being they loose the auto-fill functionality until the platform catches up.

 

The group policy only works on windows, which still leaves out the Mac users (like myself) which we estimate to be about 40% of our user population.

 

Thanks again.

 

Link to comment
Share on other sites

Thanks Chris, but we're not convinced our customer base would prefer that option - we would expect upgrading a single instance of Passwordstate, is a lot less effort than all users having to manually keep downloading new versions of the extensions.

 

Appreciate you thinking of alternatives, and we've struggled with this for a few years - we just wish Google could implement one simple feature.

Regards

Click Studios

Link to comment
Share on other sites

The issue of the Build Number being hard-coded to a particular version of PasswordState is frustrating.   Unfortunately for me, we have a change-management process (that includes rigorous testing) that takes about 3 months to get any new versions into Production.    I just upgraded to 8765 last week!

 

Is there any reason why the Chrome plug-in (extension) itself can't be developed in such a way that it is backwards compatible to support previous version of PasswordState ?   Then it wouldn't matter if Google automatically pushes the extension updates automatically or not.

 

p.s.  I thought I had read something that mentioned that the plug-in dependency to a particular version of PasswordState was being removed, I must have misinterpreted it.

 

Thanks... Scott

 

Link to comment
Share on other sites

Hi Scott,

Unfortunately this is necessary some times - whenever we have a dependency change between the browser extensions and the API in Passwordstate, this is when a forced upgrade is required. If we did not do this, then the extensions would break.

 

We apologize about this, and we can only ask customers to request Google to add a feature where you can turn off automatic updates of extensions.

Regards

Click Studios

Link to comment
Share on other sites

Hi All,

 

I found a post that mentions how to prevent Chrome from automatically updating a specific extension.  It is a little bit of a hack, but would allow you to control WHEN that extension gets upgraded.

 

The solution is to download the desired extension, unzip it and then open the file call "manifest.json".  Modify the "update_url" entry to a bogus URL (https://localhost e.g.).  Finally manually install the extension by going to "chrome://extensions" (and pointing to the location where your modified version resides).

 

I have followed these steps to install an older version of the PasswordState extension (I found on https://crx.dam.io/) and got Chrome to work with PasswordState version 8765.  

 

Hope this helps someone else.

 

Thanks... Scott

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...