evalScript broken in CEP 11 / templates install with legacy dependencies

[vonnnassau]

I am a quite lost after moving to CEP 11. I got the hang of CEP 10 / Bombino and Vue and signed a handful of pretty awesome lifesavers.

Now I read about CORS, but still don’t get it. Where it’s about return values/callbacks, I would just like to send functions with parameters to my host AEFT.

Trying to create a new Bombino project. The createEventChain.js is there, index-dev.html looks good already.

// this used to work, just some function with some vars. Now AE hangs without any log.
let msg = {
          someVar: this.myVar,
};
let result = await evalScript(
`myFunction('${JSON.stringify(msg)}')`
);

// this works, just adding some layer in AE
let result = await evalScript(`
  (function() {
    var myComp = app.project.activeItem;
    var shapeLayer = myComp.layers.addShape();
  }())
`)

Is this how it’s supposed to work now? Or was this always the idea? As I said, I'm lost, spending hours to find the way, but not sure if I even understand what the right way is. Can anyone tell me what the right direction is? Many thanks.

[Inventsable]

Sorry for the confusion per CEP 11. I've been away from home but adding this to the manifest might solve the CEP 11/CORS issue entirely and let you revert back to evalScript from the cluecumber package instead of the newer, workaround one:

<CEFCommandLine>
+ <Parameter>--disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure,NetworkService</Parameter>
+ <Parameter>--disable-site-isolation-trials</Parameter>
  <Parameter>--enable-nodejs</Parameter>
  <Parameter>--mixed-context</Parameter>
</CEFCommandLine>

^ Note the two added parameters above, and NetworkService at the end to be compatible with CEP <=10. I've yet to test this, though.

let result = await evalScript(myFunction('${JSON.stringify(msg)}'));

It's hard to say without knowing what myFunction is, because I can't tell if it's an evalScriptError or an error in CEP from looking. It might be that JSON is undefined and not being properly mounted (since that relies on evalScript as well) so when you're trying to parse it in JSX an error is thrown, I'd wrap this in a try/catch to invoke the same function, like:

// in JSX
function runTest(msg) {
  try {
    alert(JSON);
    myFunction(msg);
  } catch(err) {
    alert(err);
  }
}

And then to test in CEP:

let result = await evalScript(`runTest('${JSON.stringify(msg)}')`)

There is a DEBUG parameter at the top of the createEventChain file which, if turned on, will log to the console during the evalScript calls. If you have more trouble, I'd be interested in seeing a screenshot of the console for the above or something close.

^ It might be that workaround doesn't return from parent > child unless the evalScript call itself returns, in which case it's creating a Promise that never resolves. I swear I'd handled that, but if this continues being an issue I'll double-check.

[vonnnassau]

Hello Thom, many thanks for your informative and quick reply.

Excuse me for adding the JSON-part, that was unnecessary so I made a bare minimum version.

From the CEP11-AEFT.log 2021-11-25 21:08:43:039 : DEBUG PlugPlugEvalScriptFn() callback called. EngineId: com.HelloWorld.panel_Engine_Id, Script: testJsx()

From the panel.log 2021-11-25 21:24:38:455 : ERROR Render caught NSInvalidReceivePortException: connection went invalid while waiting for a reply because a mach port died 2021-11-25 21:24:38:456 : ERROR Heartbeat call failed. 2021-11-25 21:24:38:546 : INFO --Exiting…--

I Set const DEBUG = true; But nothing showed up in Chrome / CEF Remote Debugging.

Added the 2 lines to the , changed back and forth from brutalism, workaround and cluecumber without luck.

This is the bare minimum, which let AE hang:

// in vue
import {evalScript} from ‘brutalism’ //‘workaround' or ‘cluecumber’ give me same result

 methods: {
 async TestEval(){
  let result = await evalScript(
  `testJsx()`
  );
}

// in host.jsx
function testJsx(){
    alert("hello world");
}

Sorry if it’s something too obvious, I would really not like to waste your time. But I would love to get this going again.

[vonnnassau]

I doubt the problem is evalScipt but more related to the (lack of a) connection to host.jsx None of the following is being executed after reloading the panel.

// host.jsx
console.log('Host is online');
var myComp = app.project.activeItem;
var shapeLayer = myComp.layers.addShape();
alert("hello world");

[Inventsable]

All templates now include the above Chromium flags with all references to the workaround package now removed. Can you verify if this is still an issue within any new template?

The solution to this is to revert everything back to prior to workaround which admittedly was a temporary solution. We want to disregard anything about CEP 11 CORS changes, delete the references to createEventChain.js in both public/index.html and public/index-dev.html, then make sure you have brutalism@latest so that no components are internally importing evalScript from workaround. At this point, you'd just ensure to import evalScript from brutalism in your current file and verify.

[vonnnassau]

The cefclient console still does not give me the message that the host is online nor opens an alert that I added in host.jsx, so I assume something is still not working there. I usually test in AEFT, but ILST has same behaviour.

Then I test a very basic call to a function in the host.jsx

<Button @click="testClick" label='@click' />

<script>
import { evalScript } from 'brutalism';

export default {

  methods: {
      async testClick(){
         let result = await evalScript(
          `testJSX()`
        );
    },
  }
}
</script>

// in host.jsx:
function testJSX(){
    alert("hello testJSX");
}

which gives me this error in cefclient

[Vue warn]: Error in v-on handler (Promise/async): "[object Object]"

found in

---> <Button> at node_modules/brutalism/components/Button/Button.vue
       <Wrapper> at node_modules/brutalism/components/Wrapper/Wrapper.vue
         <Example> at src/views/Example.vue
           <Panel> at node_modules/brutalism/components/Panel/Panel.vue
             <App> at src/App.vue
               <Root>
warn @ vue.runtime.esm.js?2b0e:619

I'm traveling, so I checked this quickly. Maybe I still miss something obvious. I think I should create a basic extension without bombino to check if it's not my system that's bugging me. Thanks again for all your effort.

[Inventsable]

I know what the issue is, give me a little bit and I'll resolve it and share a repo demonstration by the end of the night.

[Inventsable]

Hi Erik,

I did a lot of testing and believe I have it completely fixed but in any case this was an internal problem (very similar to the other issue actually) and no, you were not doing anything wrong. Very good catch and thanks for detailing the problem because some of the points you made ended up leading me to the exact issue and that saved me a lot of time finding the cause.

I've created a new repo as a test case that should prove this is no longer an issue. I outline a few things, gives instructions on how to migrate any current extension, and demonstrate the whole process. I'd recommend doing a git clone on this repo if not copy/pasting the App.vue file and testing it yourself just so we're using the exact same code and can more easily share examples.

Bombino templates should no longer have this issue, anything generated from now on has more strict callouts for modern versions of dependencies.

[vonnnassau]

Hi Tom,

This repo works for me. Host is online, alerts, it all works.

A freshly generated template also works.

An existing template still silently crashes after npm i brutalism@2.3.2 cep-spy@1.3.4 cluecumber@0.1.1 gehenna@1.1.4 starlette@1.0.7 but I might have done there something unusual in my attempts to resolve this issue myself in the last weeks. I will test this in the next days when I got more time.

Excellent stuff. I'm very happy that this works again and will use it extensively in the upcoming months.

[Inventsable]

Going to close this with an altered title just to make it easier for others to find if they share the same issue. Feel free to re-open this if any one reading can replicate the same behavior and proposed solutions above do not work.