Panels generated on Mac, running on Windows: 1 is recognized. 1 is not.

Report · Mar 22, 2024

Following up on this post

After successfully generating a Custom Adobe Panel on Mac and running it on Windows, a second attempt to do the same failed.

The only difference between the two panels (that I'm aware of) is the panel name.

Both panels are signed, and both include the same .debug specs.

The 2nd panel gets no further than the window opening, which is is more than you get if trying to open a signed panel that has been altered.

The panel opens, and the window size specified in manifest.xml is respected.

But that's it. Blank screen. Even the simplest index.html won't display

<!DOCTYPE html><html><head></head><body style="color:red; background-color:blue;">Hello World</body></html>

So both panels are generated on Mac, both function successfully on Mac
But while one works just fine on Windows, the second does not.

Looking for ideas on how to best trouble-shoot.

Report · Mar 22, 2024

>Both panels are signed, and both include the same .debug specs.

Why would a signed panel ever contain .debug specs? Hopefully, you're done debugging that version of the panel, before you sign it, right?

>...Looking for ideas on how to best trouble-shoot.

Set breakpoints in your panel's OnLoaded() function, step through it and see what specific line of code is failing.

Report · Mar 22, 2024

Why would a signed panel ever contain .debug specs? Hopefully, you're done debugging that version of the panel, before you sign it, right?

The dev workflow signs every panel, regardless of whether it's in dev or a production version.

The process is semi-automated:

Make coding changes, run script which generates the panel, signs it, places it locally in extensions folder. Refresh panel to test.

Production: Run same script, .debug excluded.

RE

| see what specific line of code is failing.

Code doesn't even begin to run. Even an index.html with just text, no JS whatsoever -- even that is a blank panel extension.

Report · Mar 22, 2024

I don't know of any other developer who signs debug builds. 🙂

>Make coding changes, run script which generates the panel, signs it, places it locally in extensions folder. Refresh panel to test.

If PPro is running while you're replacing one signed panel with another, you're changing the panel's contents from when PPro last checked the signature, resulting in undefined behavior.

If you enable the loading of debug panels on your Windows system (and reboot so the Registry changes get honored), does the non-loading panel now show up correctly?

Send me your non-loading panel.

Report · Mar 22, 2024

I don't know of any other developer who signs debug builds. 🙂

It's automated, so I don't have to think about it ( ;

If you enable the loading of debug panels on your Windows system (and reboot so the Registry changes get honored), does the non-loading panel now show up correctly?

I wasn't aware there was a special thing that needed doing to load a debug panel. Method I use for debug is a) include a properly-specified .debug , b) Use Google Chrome. This has been working both on Mac and Windows (except for this troublesome Panel). So I didn't do anything on the Windows machine to enable debug panels, but I did reboot, which didn't get any results.

Send me your non-loading panel.

Sent

Report · Mar 22, 2024

I can reproduce the "same panel that loads on mac, does not on windows" behavior...and I have the loading of debug panels enabled on both platforms.

Something strange I noticed: In the panel's manifest, you're declaring the script path as:

<ScriptPath>./prjx400-Adobe.jsx</ScriptPath>

prjx400-Adobe.jsx is completely empty.

I'm not sure how or why, but on MacOS, it seems to be the case that PPro somehow decides to load the prjx400-Adobe.jsx instead.

The manifest script path should definitely point to a .jsx (ExtendScript) script file; I wonder whether, if you correct that reference (move the alert() call from the .js file to the .jsx file), and re-sign the extension, it might work...?

Report · Mar 22, 2024

Something strange I noticed: In the panel's manifest, you're declaring the script path as:

<ScriptPath>./prjx400-Adobe.jsx</ScriptPath>

Ee gads. That's a mistake that's been there forever. It has never caused a problem, but going forward will make sure it's corrected.

Meanwhile, adding the alert("Test") to the JSX didn't change anything.

Presumably the reason why is it that both the .jsx and .js files don't run if called directly. The .js has to be called by .html (else the window.onload doesn't trigger). And the .jsx (which ordinarily isn't empty) only runs properly when called by csInterface.evalScript() from .js.

Will send you a version of the plugin with the same manifest.xml mistake calling the .jsx, and which has the alert(); in BOTH .js & .jsx, and each on self-identifes as .js vs .jsx

Only the .js gets called.

prjx400-Adobe.jsx is completely empty.

Only because to test this issue no JSX needs to run. Just simplifies things.

Here's the interesting news: Problem resolved!

It wasn't the .jsx in the manifest.xml

It was the fact of having a space in the panel name on Windows. It's not a problem on Mac, but ported to Windows it fails to load in Premiere.

Report · Mar 22, 2024

Nice troubleshooting! Thanks for sharing the solution.

Report · Mar 22, 2024

Thanks as always for your insights.

My note above suggesting that having the manifest.xml point to the .jsx file in the <ScriptPath></ScriptPath> was a mistake was itself a mistake. It is actually supposed to point to the .jsx, correct? Replacing it with the path to the .js file caused the panel to stop working entirely. It's been a long time since I built the manifest.xml and forgot what what that was all about.

Adobe Community

Panels generated on Mac, running on Windows: 1 is recognized. 1 is not.

1 Correct answer