chrome.runtime not defined by default - any way to FORCE it to be?

[Tim Bessie]

Hi all!

So we have a Chrome extension out in the wild and users are starting to see errors because chrome.runtime is not defined.  According to this document, this was done in Chrome v106.  They give a workaround (enabling a Chrome flag or setting a policy):

https://support.google.com/chrome/a/answer/7679408#chrRun106

However, does anyone know if there's any PROGRAMMATIC way to cause chrome.runtime to be populated?  I don't want to force users to have to enable flags (which might go away).

Meanwhile, I'm changing our code to no longer expect chrome.runtime to be defined.  But it would be nice if we could have it always available.

- tim

[Jackie Han]

In your manifest.json, add an "externally_connectable" field.

"externally_connectable": {
  "matches": ["https://*.example.com/*"]
}

Then chrome.runtime is available on that website.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/8610a67b-50ad-4490-b39b-a0de466e2b7dn%40chromium.org.

[Tim Bessie]

Thanks Jackie!  However, in the manifest we already have:

"externally_connectable": {
    "matches": [
        "*://127.0.0.1/*",
        "*://127.0.0.1:*/*",
        "*://*.mydomain.com/*",
        "*://*.mydomain.com:*/*"
    ]
}

... and it's not working, but only as of v106.  The link I provided claims that chrome.runtime - as of v106 - just ISN'T AVAILABLE AT ALL unless a plugin is loaded at that point.  It doesn't mention anything about changing the manifest to make it available.  Did you test your claim?

- Tim

[Jackie Han]

I tested it on my site and localhost. It works on Chrome 106.

  "externally_connectable": {
    "matches": [

      "*://127.0.0.1:*/*",
      "https://mysite.dev/*"
    ]
  }

[Tim Bessie]

Huh - is your app in the Chrome store? I tried repackaging mine and it won't load anymore, saying it wasn't found in the Chrome store...

- Tim

[Jackie Han]

I tested with a local unpacked extension.

[Tim Bessie]

Can you try it packed and see what happens?

- Tim

[Jackie Han]

I packed that local extension with and without "externally_connectable", both are not enabled in Chrome on macOS. Is there anything wrong? I remember Chrome only supports self-package on Linux.

[Tim Bessie]

Ok, allow me to clarify…

I created this extension years ago.

Back then, I packed it myself in Windows (didn't put it in the Chrome store) and made it available to users.

Users have been able to load it by hand and use it in both Windows and macOS ever since.

Occasionally we've had to repack it as Chrome package format changed, but other than that, it's worked fine.

Also, chrome.runtime has been available the whole time.

Recently, when installing the existing .crx file in current versions of chrome, we get a warning message saying that the manifest format has changed, and that the old format will be invalidated in the future.  But the extension still loads.

However, since Chrome v106, chrome.runtime has no longer been set (and we display an alert at this time, which has been annoying users).

I tried using the newer manifest format and repacking the extension. However, when I do this, the extension no longer is loaded (because it is not in the Chrome store).

As mentioned in the link I mentioned, chrome.runtime being available in a packed extension changed in v106. As far as I know, this has nothing to do with the recent changes to self-packing rules, but is a separate issue.

My goal - as in the title of this thread - is, is there a way to force chrome.runtime to be set programmatically, without using the workaround the link about the v106 changes mentions.  And I want this in a PACKED extension (self or not).

Does that clarify things?

- Tim

[Jackie Han]

These are two different things.

1. My answer is about "chrome.runtime". It is a recent change for all extensions on all platforms.

2. As others said. Self packed extensions are disable on Windows and Mac now. So it can't work.

[Tim Bessie]

Well yes, i know they're two different things. I was giving you the whole story for context.

I said "packed" in general for the future of this extension, not self packed.

That's why I asked if you had tested this in a packed extension.  You were telling me that chrome.runtine WAS set for you in an unpacked extension, but I'm asking you to test apples with apples - is chrome.runtime available in a packed extension now?

I'm confused because first you said "works for me" re: chrome.runtime, but then just now you said it DOESN'T work.  You seem to be contradicting yourself.

- Tim

[Tim Bessie]

I've been confined to mobile for the more recent part of this conversion.

I'll review it and comment further when home.

- Tim

[Jackie Han]

Let's review the conversation.

You: is your app in the Chrome store?
Me: I tested with a local unpacked extension. 

This means I told you I only write a simple local extension as Dev mode. Of course, I can't upload a new extension to Web store just for testing. If it works as local dev mode, I think it can work on Chrome Web Store.

[hrg...@gmail.com]

Users have been able to load it by hand and use it in both Windows and macOS ever since.

This contradicts everything I've seen, read and tested myself for years. I'm unable to load a local CRX file on Windows on any Chrome version after Chrome 70.

May I ask please... what Chromium variant are you using? Chrome? Edge? Brave? Opera? etc...

What release channel? Stable? Beta? Canary?

[Tim Bessie]

Ok, back at my desk.  Less frustrating experience to answer here. :-)

My problem was that I hadn't mentioned that this extension currently IS packed, and has worked until v106 (when they made that change to when chrome.runtime is made available), and that we want it to CONTINUE to be packed, even if that means we need to make it available on the Chrome store.

I'm sorry I didn't say all of the above to start with; I had presumed that anyone who would be testing this would be testing with a packed extension (either self-packed, or from the store).  My bad.

So, to summarize - I want to access chrome.runtime in a packed (self or from store) extension without having to use the workaround mentioned in the article, and without any dependence on anything else, but to do it purely programmatically via calls I can make in JavaScript.  Do you know if this is possible?

As for how you tested in Dev mode - I was not aware that one could load an extension without first creating a .crx file; is that what you mean?  If so, unfortunately we're not able to do that as anything but self-loading a single file into Chrome (or going through the store) would be too complex for our users.

- Tim

[Tim Bessie]

Hmm, perhaps there's a misunderstanding?

I created my extension, and from Dev mode on the Extensions tab, I pack my extension into a .crx file, then drag the .crx file into the Extensions tab.

Is that what you're saying I shouldn't be able to do?  As of recently, an extension that I packed using more recent versions of Chrome won't load, but ones I packed using earlier versions of Chrome (not sure when, but most recently a couple of years ago) were able to be enabled in Chrome.

- Tim

[hrg...@gmail.com]

I've just created a CRX file using Chrome 75 and tried loading that file in Chrome 75 and Chrome 104.

It did not work in any of them.

It's entirely mysterious to me how your users are loading CRX files from their hard-drives under Windows. Like I said before, this contradicts everything that's documented as well as every test I have performed.

[Tim Bessie]

I don't know what to say, except this has been working.

If you want, I can double check this, and also email you a copy of the .crx file for you to try out.

- Tim

[Robbi]

It's entirely mysterious to me how your users are loading CRX files from their hard-drives under Windows

Some browser like "FlashPeak Slimjet" or "SRWare Iron" allow the loading of CRX files.

[Tim Bessie]

Oh, sorry, I didn't say what browser I was using.

Just regular old Google Chrome, regular release channel, nothing unusual.

- Tim

[Hr Gwea]

If you want, I can double check this, and also email you a copy of the .crx file for you to try out.

That would be great. Please send me the CRX file to my email. You should be able to see my email address in the "From" field of this message.

Thank you.

 

[Simeon Vincent]

Chiming in quickly from the Chromium side, I'm also surprised to hear that the packed extension worked. To my knowledge, on Mac and Windows Chrome will automatically disable self-signed extensions the first time they try to execute JavaScript. Linux is the only platform that doesn't share this behavior.

The only way that I think of that might explain this behavior is if the CRX file you're distributing was downloaded from the Chrome Web Store. In that case, Chrome could verify that it was signed by the Chrome Web Store and load it normally. Other than that, though, I'm at a loss as to why it only stopped working recently.

Simeon - @dotproto

Chrome Extensions DevRel

[Tim Bessie]

Nope, never went to the web store. Always distributed via email or link to our clients.

- Tim

[Tim Bessie]

So this issue was put aside for a bit; however, now that I've come back to it, I'm still having an issue.  Basically:

1. Our goal is support use of USB Foot Pedal devices

2. In a Chrome App (not an Extension), this could be done by examining HID devices and finding a connected foot pedal using a chrome-specific API object

3. In order for this to work, users need to load the Chrome App we wrote; code in the web app would reference chrome.runtime to communicate with the Chrome App

4. It looks like to access chrome.runtime now from the web app, the Chrome App needs to be loaded from the Chrome Store

5. The Chrome Store is no longer accepting new Chrome App uploads

6. Chrome Extensions don't have access to the chrome-specific HID device API

So Google is requiring a Chrome App be in the store for chrome.runtime to be accessible, and Chrome Apps are the only things having access to the HID device API, and Chrome Apps can no longer be uploaded to the Chrome store (just Extensions, which don't have access to this API).

So what's a person to do?  Google has suggested using a new - EXPERIMENTAL - HID device API, but it's not really ready for prime time.

Has anybody got any idea how we can do what we need to do (main web app has access to chrome.runtime, Extension or Chrome App has access to chrome-specific HID Device API (not the experimental one), and we don't have to upload the Chrome App to the Chrome Store (since that's now impossible))?  This weird combination of new Chrome restrictions has made it impossible for users to use the foot pedal. :-/

- Tim

[Jackie Han]

Google has suggested using a new - EXPERIMENTAL - HID device API,

Yes. Google suggests using WebHID API. I am not familiar with it. Here are some articles:

https://developer.chrome.com/articles/hid/

https://web.dev/hid-examples/

--

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/798ce5de-6c21-4df9-a3c5-c7ab99722621n%40chromium.org.

[Tim Bessie]

@Jackie Han - Yeah, that's what I was referring to.  Looks like it's the only real option going forward.

I was just hoping someone here had some magic in their bag of tricks to get around this. :-/

Kind of annoying that they make use of an older API impossible, without the newer API even being fully ready yet.

- Tim