Argument passed to the callback for `browser.runtime.sendNativeMessage` should not be a JSON-encoded string but a deserialized JSON object.

Issue #13055670 • Assigned to Steven K.


Aug 2, 2017
This issue is public.
Found in
  • Microsoft Edge
Found in build #
Reported by 1 person

Sign in to watch or report this issue.

Steps to reproduce

Argument of the callback for browser.runtime.sendNativeMessage should be a deserialized JSON object, but a JSON-encoded string is passed as the argument.

Let’s assume that I’m developing an extension for Edge, which uses Native Messaging and communicates with an UWP app.

background.js in the extension calls browser.runtime.sendNativeMessage as follows:

browser.runtime.sendNativeMessage("NativeMessagingApp", { key: "value" }, function(response) {
    console.log(typeof(response));  // (*1)
    console.log(response);          // (*2)

In the above example, response should be a deserialized JSON object, but it is a string when the following UWP app sends a response.

// In App.xaml.cs
var json_serializer = new JavaScriptSerializer();
var response = new ValueSet();
response.Add("message", json_serializer.Serialize(new { result = true, data = "abcde" }));
await args.Request.SendResponseAsync(response);

In this case, background.js shows these outputs:

  • (*1) shows string.
  • (*2) shows {"result":true,"data","abcde"}.

On the other hand, I think that the following outputs are expected because response is an object, { result: true, data: “abcde” }.

  • (*1) shows object.
  • (*2) shows [object Object].

Both Firefox and Chrome behave like this.

Could you kindly check whether this is a bug or not?


0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Steven K.”

    • Hi,

      I believe what you are seeing is by design.  There are some differences between the way Edge and Chrome handle sendNativeMessage() responses.  This link has details on the differences.  I believe the section specific to your question is the “Communication protocol” section.

      Let me know if this answers your question,


    • Hi

      Thank you so much for the reply.
      But the article you mentioned does not answer my question.

      The article defines the way to handle the parameter in UWP (Edge) or in native messaging host exe (Chrome),
      but it does not refer to the difference of the way to handle the parameter in JavaScript source code.

      My question is the following.
      Currently, the format/type of the argument of the callback of sendNativeMessage is different.
      Is this by design?

      Because of this difference, JavaScript source code of the extension for Edge is not compatible with the extension for Chrome.
      Of course, it’s acceptable that the handling in the UWP for Edge is different from the handling in the native extension host exe for Chrome,
      but JavaScript source for each extension should be compatible.

      We have to add the following workaround to support the current implementation of Edge.

      browser.runtime.sendNativeMessage("NameOfNativeMessagingHost", { "key": "data" }, function(response) {
          // The following line is necessary to support Edge...
          if (typeof(response) == "string") response = JSON.parse(response);
         // ...

      I guess that this is a bug because of the following reason.

      • the second argument for sendNativeMessage, { "key": "data" }, is not stringified data, but is a raw object.
      • On the other hand, the returned value, response, is not a raw object, but stringified data.
      • i.e. They are not symmetric in Edge although they are symmetric in Chrome and Firefox.

      If this is by design, the article you mentioned should be modified to describe the difference of the type of response argument.


    You need to sign in to your Microsoft account to add a comment.

    Sign in