Node Enabled by Default in 2017.1?

[sberic]

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:

1. --enable-nodejs - According to the documentation, this is disabled by default.
   • [Side Note: the CEP Cookbook PDF contains this Adobe-internal link for "Customize CEF Command Line Parameters".]
2. --mixed-context - According to the documentation, this is disabled by default.

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?

[Bruce Bullis]

Mixed Context Mode

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.

[sberic]

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?

[Bruce Bullis]

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.

[sberic]

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:

1. Quit Premiere Pro.
2. Modify the manifest.xml file.
3. Open Premiere Pro.
4. Open the panel.
5. Attach a remote debugger with Chrome.

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:

1. --enable-nodejs: Enable Node.js APIs in extensions. Supported since CEP 6.1.
2. --mixed-context: Enable the "mixed context" mode. Supported since CEP 7.0.

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.

[Bruce Bullis]

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>

[sberic]

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.

[Bruce Bullis]

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.

[sberic]

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.

[Bruce Bullis]

I've escalated the issue with the CEP team; thank you for your careful and thorough testing!

[sberic]

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:

1. The Node context appears to be enabled by default in Premiere Pro 2017.1 (possibly earlier?).
2. Double dashes ("--") in commented out nodes within the manifest.xml file cause Panel Extensions to fail to be recognized correctly.
3. The documentation is unclear as to whether or not enabling --mixed-context implies --enable-nodejs, or whether it is also necessary for proper functioning in CEP 7 environments.

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.

[sberic · Accepted solution]

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.

TL;DR

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.

Details - Node Wasn't Enabled

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.

The Environment

We are developing our panel with the following mixture of web technologies. The important ones are listed here:

• TypeScript​ - Strongly typed language that compiles into JavaScript. Compilation is handled by:
• webpack - " module bundler for modern JavaScript applications".

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:

• Node-WebKit v0.12.1 - NW.js is "an app runtime based on Chromium and node.js." This includes the following parts:
  • IO.js 1.2.0 - This is the version of "Node" available in CEP 6.1 and 7.0. IO.js was a fork of Node that has since been merged back into mainline Node.
  • Chromium v41.0.2272.104 - This is the equivalent version of Chromium made available in the Node-WebKit environment.

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.

Webpack Configuration

At the heart of the issue was a mismatch between the webpack default configuration and the actual target environment.

Webpack Defaults

By default, webpack assumes the following:

• You are building for the browser.
• You expect certain node API polyfills.

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.

Proper Webpack 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!

The Mixed Context Flag

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.

Useful Information About the Mixed Context

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.

Summary

The answers to the questions raised in this thread are as follows:

1. Is NodeJS actually enabled by default in Premiere Pro 2017.1? No: watch out for shims/polyfills, possibly automatically added by build systems.
2. Is the fact that "Double hyphens in an XML comment in the Manifest file cause a panel to fail to load" a bug? No: the XML spec specifies that double hyphens ("--") are not allowed within comments.
3. Is the --mixed-context flag dependent upon the --enable-nodejs flag? Yes. Setting --mixed-context does not also enable the Node context.

I hope this information is useful to others!