zikaari / crx-bridge Goto Github PK

Instead of unlocking all sub-frames in a tab, Bridge.enableExternalMessaging should allow limiting this just to window.

use case:

// content_script.js
if (window.location.hostname === 'localhost') {
    Bridge.enableExternalMessaging(nsps, ['window'])
}

In my MV3 extension, I've tried to send a dummy message from a content script to the
background service worker and I get the following error from the extension

Uncaught Error: Unable to detect runtime context i.e crx-bridge can't figure out what to do

which seems to me that it can't even find the background "namespace". I'm not using the "window" so wouldn't that
work out of the box?

P.S Thanks for this excellent package!

Thanks so much for this tool! It's awesome and saves me a lot of time.

I am trying to develop extensions cross-browsers.

With webextension-polyfill we can have a single entry for different browsers(Chrome, Firefox, Opera). For example

import browser from 'webextension-polyfill'

browser.runtime.sendMessage(...)

// will become this in Chrome:
// chrome.runtime.sendMessage(...)

// will become this in Firefox:
// firefox.runtime.sendMessage(...)

Wondering if you are interested in supporting this feature. I would also love to make PR.

Thanks :)

If content-script or devtools are not ready (loaded), messages sent to them get queued up and get delivered when ready.

This does not happen when destination is something like devtools:frame or window, since getting to these is accomplished using window.postMessage and not chrome ports.

I can't send messages to and from popup.js via crx-bridge, can I?

The idea sparked up as a direct result of issue #7. This issue popped up Firefox support was added through webextension-polyfill. Basically, there's some code that can't be loaded into the window context.

The fix? - let's just not have that code run in the window context then!

Having separate modules for each runtime context not only fixes the issue mentioned above, but it actually has some sick benefits (explained later), first, this is what it would look like:

// any script injected by a content script
import Bridge from 'crx-bridge/window';

// within content scripts
import Bridge from 'crx-bridge/content';

// within devtools
import Bridge from 'crx-bridge/devtools';

// and finally, background pages
import Bridge from 'crx-bridge/background';

Now, on to the benefits:

• Lightweight - the window context doesn't care about the webextension API's, and the background doesn't care about postMessage. While there's no concept of "loading time" in an extension, parsing time reduction is still welcome.
• Strict, more precise "localized" typings - because each module has its own designated scope, instead of a general crx-bridge scope, types can be contained as well. For example, setNamespace inside any other context besides the window script is a noop, and allowWindowMessaging is only applicable in a content script.
• More readable - The moment you see import Bridge from 'crx-bridge/background', you know that this file is meant to run in the background page. With just import Bridge from 'crx-bridge', not so much.
• Strict errors during development - The moment import Bridge from 'crx-bridge/window' statement runs within a content script, an error is thrown to let you know that you're mixing up things. This strict behavior keeps the previous bullet point about readability reinforced at all times.

cc @smeijer @antfu @pakholeung37 @marik-d

I'm using crx-bridge in a new project.

However, I can't receive a response when I use sendMessage in a window opened by the code below.

browser.windows.create({
  focused: true,
  url: `notification.html`,
  type: 'popup',
})

It is the same even if I called allowWindowMessaging in content-script and setNamespace in the created window.

Did I miss something?

Error: This script should only be loaded in a browser extension.

Errors is thrown from webextension-polyfill when trying to import bridge in the window context.

Using Chrome Version 86.0.4240.111

The v3 manifest for chrome extensions imposes service worker instead of a background script. Does crx bridge deal with this?