Javascript bridge error on set method from JS

FNC TMS FNC UI Pack
1

Hello I have an error on the JS side when I try send something to the delphi side using the bridge.

This is bridge implementation

	 try {
	    const parameters = { type, payload };
	    const obj = window?.chrome?.webview?.hostObjects?.sync?.MyBridge;
	    if (obj) {
	      obj.ObjectMessage = JSON.stringify(parameters);
	    }
	  } catch (error) {
	    logger.error(error);
	  }
	};

TypeError
'set' on proxy: trap returned falsish for property 'ObjectMessage'

I want to send a JSON objct to the delphi side.

I'm using
Delphi 10.3.3 or 10.4 (but I would really love it to work on both)
MS Edge Version 88.0.705.50 (Official build) (64-bit)
FNC Core 3.2.2.2
Control: is TFNCWebBrowser

thank you very much.

2

Hi,

The JSON needs to be valid:

const parameters = {"type": "payload"};
3

Hello sorry the function header was missing

import logger from "./logger";

export const dispatchToBridge = ({ type, payload }) => {
  try {
    const parameters = JSON.stringify({ type, payload });
    logger.log(`dispatchToBridge`, type, parameters);
    const obj = window?.chrome?.webview?.hostObjects?.sync?.MyBridge;
    if (obj) {
      obj.ObjectMessage = parameters;
    }
  } catch (error) {
    logger.error(error);
  }
};

type and payload are function parameters they are supposed to be that way.

4

yes, but it's unclear how { type, payload } is supposed to be interpreted. is type and payload a string parameter? Note that valid JSON needs to have a name and value (value can also be something other than a string ofcourse):

{"Name": "Value"}

I have tested by using JSON.stringify({"Name": "Value"}); here before sending it and this is working as expected. I suggest to start with a simple method to call the bridge ObjectMessage and build up from there. If the issue persists, please send us a simple sample demonstrating the error.

5

for example I send

{ type, payload }

==

{"type":"USER_LOGOUT","payload":{"user":{"id":"c1013f15-d0e8"},"reason":"btn_press"}}

I will try to give a solid reproduce.

thanks

6

@Pieter_Scheldeman I just received a private message from another user @Judas_Benjamin.

he is having the same error like us.

the strange thing is, he can not reply on this thread.
do I have to change some settings for others to reply?

and as an update we are still having the same error, we are debugging but without any success. I will keep investigating piece by piece like you said.

thanks.

7

Hi,

Did you already start from scratch building up with a simple example sending through JSON? This might give you an insight on what exactly is different with your real application.

8

Hi,
We did, if we send static string like you did the error is gone, but when passing the runtime params like this

{ type, payload }
==
{"type":"USER_LOGOUT","payload":{"user":{"id":"c1013f15-d0e8"},"reason":"btn_press"}}

we always have it. the bridge is sent successfully to the delphi side and we receive all the data but our logging system is still reporting that we had an error at that point.

9

I suppose this is because the json is not a string but an object and therefore does not match the type of the ObjectMessage property which is also string.

10

@Pieter_Scheldeman this is what @Judas_Benjamin's is having

I just saw that, thanks!

I feel like I can only post in the categories of the components I bought... and I am just evaluating the TTMSFNCWebBrowser as a replacement for the VCL TWebBrowser in Edge mode (for which the deployment is a joke...).

I will investigate the problem a little more and send you my observations.

In a few words:

  • I am using a Vue.js environment
  • My call is close to yours (I don't use the TTMSFNCWebBrowser.GetBridgeCommunicationLayer, I just call window.chrome.webview.hostObjects.sync.MyBridgeName from Javascript)
  • I get the same Javascript error: TypeError: 'set' on proxy: trap returned falsish for property 'ObjectMessage'
    Here we can see that setter should return au boolean value.
  • I have no error by scrupulously following the documentation example (who uses the TTMSFNCWebBrowser.LoadHTML, I don't know if it matters).

Windows 10 64-bit
Edge Chromium 88.0.705.68
Delphi 10.4
TTMSFNCWebBrowser 1.1.3.1 (trial version)

And like you, on Delphi side, I get the correct value in the ObjectMessage setter.
The error is just on Javascript side, in the setter return.

I hope this helps

11

Maybe it is related to using the same bridge tech on a webserver instead of plain HTML/JavaScript. We'll try and see if it is related to this difference.

1 Like
12

Hi we have further investigated this here and it seems that the error is thrown because the setter implementation on the proxy object is not returning true. It appears to be a requirement. We will monitor closely to what Microsoft will do as this is internal Edge Chromium code. We also noticed that the sync version is the reason why this error is thrown. Removing the sync version (going to async), no longer throws the exception. Note that the property will be set, but the code that happens at the client will happen asynchronously. So to avoid the error you can use the updated code:

import logger from "./logger";

export const dispatchToBridge = ({ type, payload }) => {
  try {
    const parameters = JSON.stringify({ type, payload });
    logger.log(`dispatchToBridge`, type, parameters);
    const obj = window?.chrome?.webview?.hostObjects?.MyBridge;
    if (obj) {
      obj.ObjectMessage = parameters;
    }
  } catch (error) {
    logger.error(error);
  }
};

Note that as it is going from sync to async: any code that happens after obj.ObjectMessage = parameters; will be executed directly independent of what happens at the client. I guess that for performance and to avoid the web application from hanging it is better to switch to async anyway.

1 Like
13

Thank you very much for your response.

I will update you with the results.

14

After the change you proposed we confirm that the problem is solved.

Thank you very much.

1 Like
15

Thank you for confirming.

16

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.