Your extension works for me in Canary.

Thanks for the quick response.

Are you not seeing the errors in the console?

See attached screenshot.

Deleted: canary-errors.png 145 KB

	canary-errors.png 145 KB View Download

To reproduce the error I had to force-enable native extension bindings (disabled by default) via command line:
chrome --enable-features=NativeCrxBindings

Chromium Code Search for the error message in your screenshot reveals it was intentionally added in r533360:
https://chromium.googlesource.com/chromium/src/+/b15f7f04de19b4e835f7be615a1d488876f8d086%5E%21/extensions/renderer/messaging_util.cc

Looking at the docs, I agree that this is the correct implementation.  However, I decided to report the issue as I know of a library that uses blank to connect at the moment.  I am also going to send a PR to the library to fix it, but there could also be other libraries/code bases in production that is calling runtime.connect and runtime.sendMessage this way, and they will break once this version is released.

 Issue 823590  has been merged into this issue.

 Issue 823585  has been merged into this issue.

Able to reproduce this issue on latest canary 67.0.3375.0 and latest beta 66.0.3359.33 using Mac 10.13.3, Windows 10 and Ubuntu 14.04 when enabling enable-features=NativeCrxBindings from commandline.

Good Build: 66.0.3335.0
Bad Build: 66.0.3336.0

You are probably looking for a change made after 533359 (known good), but no later than 533360 (first known bad).
CHANGELOG URL:
  
 https://chromium.googlesource.com/chromium/src/+log/ad47a6acc4904b57a69c518125ab6cf491515fdc..b15f7f04de19b4e835f7be615a1d488876f8d086

Reviewed-on: https://chromium-review.googlesource.com/860755

Suspecting same from changelog.

@rdevlin.cronin: Please confirm the issue and help in re-assigning if it is not related to your change. Adding RB-Stable for M-66. Please change if not the case.

Thanks!

Thanks for bringing this up!

This is interesting - it was a deliberate change to make the checks on ids a little more stringent with native bindings, but the fact that passing a blank id (from a content script or background page) used to work is interesting.  If this is actively being used, it's probably worth maintaining while rolling out native bindings, and then tightening a bit later if we can.

I'll see if I can fix this.

FWIW Firefox WebExtensions API handles the empty id as an optional value just like Chrome did before r533360.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e4eb1d9118b0a1647ef43228075eeb802cece6d8

commit e4eb1d9118b0a1647ef43228075eeb802cece6d8
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Fri Mar 23 14:55:30 2018

[Extensions Bindings] Allow '' to forward to calling extension in messaging

In extension messaging, if the ID is omitted, we treat it as a message
to the extension itself (e.g., from a content script to a background
page).

With JS bindings, we consider anything false-y to be an omitted ID,
which is different than in the rest of the bindings system (where if
an argument is supplied, it is used). Unfortunately, it seems there
are some libraries relying on the current behavior.

Allow '' to be treated as an extension messaging itself for backward
compatibility.  Do not extend this to all false-y values, others of
which would be sufficiently more strange.

Add unittests for the same.

Bug:  823577 

Change-Id: I8c0eaa66da39512af4a85ef11cb3e3979d8d6462
Reviewed-on: https://chromium-review.googlesource.com/973694
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545445}
[modify] https://crrev.com/e4eb1d9118b0a1647ef43228075eeb802cece6d8/extensions/renderer/messaging_util.cc
[modify] https://crrev.com/e4eb1d9118b0a1647ef43228075eeb802cece6d8/extensions/renderer/messaging_util_unittest.cc

This should be fixed with #12, which will be making its way to dev/canary in the next few days.  Feel free to try it out and let me know if you run into any other issues!

[Auto-generated comment by a script] We noticed that this issue is targeted for M-66; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-66 label, otherwise remove Merge-TBD label. Thanks.

This only affects an experiment, which is currently restricted to canary and dev channels.  No need to merge or block releases.