Copy link to clipboard
Copied
We've begun to take advantage of the Node integration in a Premiere Pro Panel. Based on the documentation, it seems as though CEP 7 supports the following two flags for the CEFCommandLine:
Before attempting to use any Node APIs, I enabled both of those in the manifest.xml for our panel and restarted Premiere Pro (2017.1). Everything worked great.
The documentation does not specify if the above two flags are interdependent or not. To test, I decided to remove both flags to ensure that I would get an "undefined" or some other error in our console output. Instead, I was surprised to find that the APIs worked without issue! It appears as though I'm currently able to use the Node integration without specifying any special CEFCommandLine flags!
What am I missing here?
The --enable-nodejs flag does work as expected! This post will describe the situation that I encountered, how I resolved it, and hopefully help anyone else who attempts to use similar technologies.
I was unaware that our build system was automatically adding a polyfill based on the default environment settings. I was clued into this fact when attempts to use the File System APIs failed. Correct configuration of the build system resolved the issue and specifying the --enable-nodejs flag sudde
...Copy link to clipboard
Copied
CEP 7.0 provided a new "mixed context" Node.js mode, which is disabled by default. Unlike the default "separate context" mode where a "required" node module is in a separate JavaScript context, a "required" node module and the JavaScript code that "requires" it are in the same context in the new "mixed context" mode, eliminating all the inconveniences in the old "separate context" mode.
To enabled it, add command line parameter "--mixed-context" to your extension manifest.
Copy link to clipboard
Copied
Bruce Bullis wrote
To enabled it, add command line parameter "--mixed-context" to your extension manifest.
So I am entirely aware of that. Unfortunately, that does not speak to the experience that I am having. Specifically, I am able to use the Node APIs without those command line parameters set in my extension manifest. The question is: Is this a bug or is something else going on?
As I mentioned in the initial writeup, I did have those flags both set at one point in the manifest. Removing them did not cause the Node APIs to fail as expected.
The second question I implied but will now state here specifically is: what dependencies, if any, do those flags have on each other? E.g. does specifying --mixed-context also automatically enable the node context, or is it effectively a no-op without the other flag also being set?
Copy link to clipboard
Copied
PPro 11.0.2 integrated CEP6, in which (I think) --mixed-context was necessary.
PPro 11.1 integrates CEP7, in which (I think, and your testing seems to support) --mixed-context is not necessary.
I've asked CEP to chime in.
Copy link to clipboard
Copied
Interesting. I feel like somehow I'm failing to communicate my situation. Let me try again:
If I do this in my manifest.xml file:
<!--<CEFCommandLine>
<Parameter>- -enable-nodejs</Parameter>
<Parameter>- -mixed-context</Parameter>
</CEFCommandLine>-->
and this in my JavaScript file:
console.log(os.tmpdir());
The remote debugging console will contain this:
/tmp
NOTE 1: You will notice that a space had been added between the double dash ("--") for the flags within the commented out parameter tags. This is necessary because Premiere Pro fails to correctly parse XML when it encounters the "--" string within an XML block comment.
NOTE 2: Allowing either or both of those flags does not change the console output. I would expect it to read "undefined" or print a syntax error if the Node APIs truly could not be accessed.
NOTE 3: I follow these steps to test settings changes in the manifest.xml file:
Bruce Bullis wrote
PPro 11.0.2 integrated CEP6, in which (I think) --mixed-context was necessary.
PPro 11.1 integrates CEP7, in which (I think, and your testing seems to support) --mixed-context is not necessary.
This is not what the CEP 7.0 HTML Extension Cookbook says. The table on page 47 includes this:
What my testing shows is that neither of those flags is necessary, even though the documentation suggests that they are required to make use of the Node APIs.
What my testing seems to support is that the Node APIs are enabled by default, which is disconcerting given this comment in the documentation (page 50):
Due to security consideration, node.js APIs are disabled by default (prior to CEP 6.1, they were enabled by default) both on the extension level and IFrame level.
Copy link to clipboard
Copied
What CSXS version* does your panel's manifest require? PProPanel still requests CEP6
* CSXS naming is an artifact of the days when all panels were built in Flex. CSXS version --> CEP version.
<RequiredRuntimeList> | |||
<RequiredRuntime Name="CSXS" Version="6.0" /> | |||
</RequiredRuntimeList> |
Copy link to clipboard
Copied
Bruce Bullis wrote
What CSXS version does your panel's manifest require? PProPanel still requests CEP6
Until today it was this:
<RequiredRuntime Name="CSXS" Version="6.0" />
When I initially went to enable the --mixed-content flag, I adjusted it to
<RequiredRuntime Name="CSXS" Version="7.0" />
There has been no change in being able to make use of Node APIs with the aforementioned parameters commented out.
Copy link to clipboard
Copied
I haven't heard about the "PPro doesn't parse double-dashes correctly' issue before...
So, to confirm (and alert my CEP colleagues): Even while requesting CEP(CSXS)6.0, you saw no change in behavior, whether or not you set either of those runtime flags; in all cases, you were able to use mixed content? [That's the part I'm trying to differentiate.]
I will confirm, but if IIRC the original source of 'security issues' concern = Adobe-wide concerns about the (then) current version of Node.js, since resolved.
Copy link to clipboard
Copied
Bruce Bullis wrote
I haven't heard about the "PPro doesn't parse double-dashes correctly' issue before...
It was surprising to me when I first ran into it a while ago. Based on my experiences, this is most definitely a bug. Perhaps try adding and commenting out one of the flags we're discussing to your own manifest.xml to verify?
I would be willing to bet that this is a problem with all panel-extension supporting CC apps...
Bruce Bullis wrote
So, to confirm (and alert my CEP colleagues): Even while requesting CEP(CSXS)6.0, you saw no change in behavior, whether or not you set either of those runtime flags; in all cases, you were able to use mixed content? [That's the part I'm trying to differentiate.]
The only behavior I've tested is that I showed above with the os.tmpdir() call. I do not believe that it requires the mixed context to work. I'm honestly not positive what a mixed-context test would actually look like. If you provide some JavaScript that does make use of the mixed-context, I will happily check if it works or fails based on the setting of the flags.
No, what's surprising is that Node appears to be always-on in Premiere Pro 2017.1, which is exactly the opposite of what all documentation describes.
Bruce Bullis wrote
I will confirm, but if IIRC the original source of 'security issues' concern = Adobe-wide concerns about the (then) current version of Node.js, since resolved.
It strikes me, then, that the documentation is lying. Is it possible that the Node APIs are enabled by default? I imagine that the CEP team could point you to the exact spot in the code where it initializes as on or off by default...
I do not have an earlier version of Premiere Pro installed on my machine to test whether earlier versions behaved differently.
Copy link to clipboard
Copied
I've escalated the issue with the CEP team; thank you for your careful and thorough testing!
Copy link to clipboard
Copied
Bruce Bullis wrote
I've escalated the issue with the CEP team; thank you for your careful and thorough testing!
Which of the issues, specifically? There's three in this thread that I can see now:
In fact, with respect to #2 above, there's actually a log that contains the error. In macOS, the file at this location:
~/Library/Logs/CSXS/CEP7-PPRO.log
contains this error:
2017-05-17 15:45:28:786 : INFO PlugPlug version : 7.0.0.30
2017-05-17 15:45:28:787 : INFO LogLevel : 1
2017-05-17 15:45:28:787 : ERROR XPATH Entity: line 28:
2017-05-17 15:45:28:787 : ERROR XPATH parser
2017-05-17 15:45:28:787 : ERROR XPATH error :
2017-05-17 15:45:28:787 : ERROR XPATH Double hyphen within comment: <!--<CEFCommandLine>
<Parameter>
2017-05-17 15:45:28:787 : ERROR XPATH <Parameter>--enable-nodejs</Parameter>
2017-05-17 15:45:28:787 : ERROR XPATH ^
A quick googling for that error text leads to the XML spec with this note:
For compatibility, the string " -- " (double-hyphen) must not occur within comments.
So #2 is not a bug. It is simply an annoying side-effect of wanting to comment-out nodes containing double-hyphenated flags.
Copy link to clipboard
Copied
The --enable-nodejs flag does work as expected! This post will describe the situation that I encountered, how I resolved it, and hopefully help anyone else who attempts to use similar technologies.
I was unaware that our build system was automatically adding a polyfill based on the default environment settings. I was clued into this fact when attempts to use the File System APIs failed. Correct configuration of the build system resolved the issue and specifying the --enable-nodejs flag suddenly became necessary.
As discussed in previous posts, Node APIs appeared to work without setting the --enable-nodejs flag. Everything seemed to work swimmingly until I attempted to use the File System APIs. At this point, our build system began to fail to compile the project, claiming that 'fs' could not be resolved.
We are developing our panel with the following mixture of web technologies. The important ones are listed here:
Beyond this, it is extremely important to understand the development environment for Adobe Panel Extensions. The CEP HTML Extension Cookbook outlines the pertinent parts on page 5, specifically the Chromium Embedded Framework. The implementation details are as follows:
The major takeaway here is that when you run code in this environment, you are running in Node-WebKit, not just Chromium Embedded Framework. The Node APIs and context are simply disabled until you specify --enable-nodejs.
At the heart of the issue was a mismatch between the webpack default configuration and the actual target environment.
By default, webpack assumes the following:
More specifically, when targeting the browser with default settings, webpack uses the node-libs-browser package to provide certain polyfills to your app. It fulfills the dependencies with this code, making certain functionality available to the browser environment. An important default setting for webpack is described here:
By default, Webpack will polyfill each library if there is a known polyfill or do nothing if there is not one.
In the case of the os library, a polyfill existed and was used. In the case of fs, no polyfill is available and was therefore left disabled. This is what caused us to initially assume that the Node APIs were enabled by default: tricked by the polyfill!
It turns out that the default configuration should be absolutely fine for panels that do not make use of the Node context. Don't use the Node APIs and no polyfill will occur. Simple enough. To be safe, however, you could intentionally disable node libraries using webpack's node configuration.
Webpack defaults to building for the browser because the target configuration setting defaults to the "web" option. Luckily, one of the options available for the target setting is "node-webkit", which has the following description:
Compile for usage in WebKit and uses JSONP for chunk loading. Allows importing of built-in Node.js modules and nw.gui (experimental)
Experimental though it may be, setting the target to "node-webkit" enables webpack to properly resolve Node APIs as expected. Once this target was set in our environment, the our panel stopped loading as it could not load the Node libraries. This forced us to use the --enable-nodejs flag as described in the documentation. No more unnecessary (and confusing!) automatic polyfills and full access to the APIs!
After we resolved the issue with the Node setup, we were able to properly test the interdependency of the --enable-nodejs and --mixed-context flags. It turns out that the --mixed-context flag does not automatically imply that the NodeJS context should be enabled. In other words, it appears to have no affect on the environment unless Node is enabled by using the --enable-nodejs flag. Another question answered.
Adobe's documentation only really describes how to enable the mixed context. It does not, however, warn you of the potential issues you may encounter once it's enabled! These details (and more) are outlined in the nw.js documentation.
The answers to the questions raised in this thread are as follows:
I hope this information is useful to others!