Chrome - Checking companion app returned: Access to the specified native messaging host is forbidden.

[DavidBE]

I mostly use Firefox, and on that VDH and the CoApp are now working fine (especially since moving to a new laptop last week that is much more powerful and faster than my 7+ year old one). But I also keep Chrome installed and updated, and use it from time to time. Today I noticed that the long awaited VDH 7 for Chrome had appeared, so I upgraded my Chrome 67 to it - VDH for Chrome 7.3.3.1.

The problem is that on the settings page it says "Companion App not installed", and then "Checking companion app returned: Access to the specified native messaging host is forbidden." When I do have the CoApp installed - version 1.2.2 - and working fine with the with the VDH in Firefox. As a separate program I surely don't have to install it again for Chrome, do I, when it was already installed (and found and working) for Firefox?

Windows 10 64-bit

[DavidBE]

Oh - there's a new CoApp 1.2.3. Installing that, both the Chrome and Firefox VDH 7s report finding it.

Problem solved , but a question remains - why didn't the Firefox VDH tell me there was a CoApp update? Surely it should?

[mig]

I am surprised VDH 7.3.3.1 for Chrome did not request coapp 1.2.3.

One of the very few differences between coapp 1.2.2 and 1.2.3, is that 1.2.3 allow native messaging with VDH for Chrome id.

So basically, install coapp 1.2.3 from https://www.downloadhelper.net/install-coapp and it will work for both Chrome and Firefox.

[DavidBE]

As above, I found the new CoApp 1.2.3, installed it and everything appears to be OK now (although i haven't done any actual downloading). But VDH for Chrome did NOT ask for CoApp 1.2.3 - all it said was what I put as this thread title, copied from the settings page. And VDH for Firefox did not say there was a CoApp update on its setting page either, just that it had found the 1.2.2. 

[mig]

I am going to check why VDH Chrome does not request minimum coapp 1.2.3 version. I can see the code that is supposed to do so.

The reason why VDH for Firefox does not tell you there is a new coapp version is that this would imply the add-on calling back our servers to ask what is the latest version, and we don't like that nor do privacy-concerned users. It could be interpreted as an occasion to monitor our users, which we don't do.

So, instead, whenever we push a new version of the add-on, we either request the installation of a new version of the coapp (when a previous version could have incompatibilities) or we just inform the user that a more recent version is available. But in both cases, those versions are specified statically in the add-on code.

[mig]

By the way, we just pushed the new Chrome version to only 10% of the users, waiting for feedback to make it available for everyone. So any other issue you may see, you are very very welcome to let us know. Thanks.

[DavidBE]

Well, it didn't turn up as an update for me on its own. I happened to go to the extension page in the store, saw the new version listed there, uninstalled the version 2 I had from my Chrome, then installed again from the store to get the version 7 - so i guess I wasn't one of the chosen 10% :)

Just did an mp4 download with it. Slightly irritating having a page pop up explaining about the two modes of download and asking me to choose given that i had already configured it to always use the CoApp, and other settings to be the same as I have them in Firefox ... but I suppose it's fair enough given that many new Chrome users of it won't have already been Firefox users and known to configure it.

Problem:

It did the download OK, but afterwards when I tried the functions in the menu to open the directory containing the file and also the one to play the local file, they both just produced errors (although it did play the file in its own player). The error after clicking to open the directory was :

Failed opening file directory

Incorrect value of args option

and the error on clicking to play the local file also  had the bit about incorrect args. The file was downloaded fine to where it was supposed to be with the name I gave it, though.

In case it is relevant, I changed the name from the one VDH offered (the video is one of many that change each week on a page that always has the same name; for any video on that page VDH always just offers the same page name as a file name, so I change the offered name every time I download from there).

By the way - it would be good if, when changing the file name in the CoApp on saving, VDH itself would then show the new name.

[mig]

Ok, thanks.

As you guessed, the browser/coapp download processing settings are dependent on the add-on user profile. So, the choice you made with the Firefox version is unknown to the Chrome context.

I heard about the "Incorrect value of args option" issue on Mac, but the fact you see the same thing on Windows gives a newer perspective. I will look into this.

Regarding the file naming issue, did you try using the smartnaming feature ? This might solve your problem in an elegant way.

[DavidBE]

I don't often use the Open Directory and Open Media functions so I just thought I'd better check. I get the same failures and the same "Incorrect value of args option" in Firefox with the Firefox VDH 7.3.1.

[DavidBE]

On Friday, 22 June 2018 17:35:41 UTC+1, mig wrote:

As you guessed, the browser/coapp download processing settings are dependent on the add-on user profile. So, the choice you made with the Firefox version is unknown to the Chrome context.

No, I meant that after installing the Chrome version in Chrome,  installing the CoApp update, and checking that VDH in Chrome could now find it, I then went to the configuration IN CHROME and set it like I had it configured in Firefox as I never thought it would configure itself like that. So IN CHROME I opened the settings, and configured it to always use the CoApp for downloads (and the window option for the File Dialog) and saved the changed configuration. Then, later, I went to test it by using it in Chrome to do a download, and that was when it was a bit irritating to have the page pop open telling me about the download method options given that I had already set them in Chrome. Still - as long as it doesn't keep on doing it ...

[mig]

That's weird. I just checked (setting download processor to coapp and requesting a download) and it worked as expected: no question, download started with coapp.

Are you sure you did not switch the user between when you set the parameter and when you requested the download ? On Chrome, there is this concept of "user profile" which is more accessible than on Firefox. User profiles have separate settings.

[DavidBE]

Quite sure. I only have the one user on the Chrome on my new laptop. Well, it hasn't done it again on further downloads, so whatever it was only affected first use.

On the other matter, I fired up my old laptop to see if it made any difference to the Open Directory and Open local file bug, maybe because of the Windows version. It didn't. Both fail with the same Incorrect value of args option error on both my old Windows 7 laptop Firefox VDH 7.3.2a6, and on my new Windows 10 laptop Firefox VDH 7.3.1, and 7.3.2a6 (I'd forgotten I hadn't updated to the beta version on the new laptop) plus the new Chrome VDH as mentioned earlier.

On the plus front, after Firefox VDH updated to 7.3.2a6 on my old laptop (from the previous beta version) it did tell me I needed to update the CoApp from 1.2.2 to 1.2.3, rather than the error message that's the title of this thread that I got in Chrome.