Keystrokes in custom panel don't stay in the panel -- affecting your timeline instead

[Premiopolis]

So imagine a custom panel with an <input> or <textarea> field.  You're typing along, everything is fine.

A bunch of regular A-Z 0-9 keystrokes, they all work just fine as expected

But... suppose you want to nudge the cursor through the text you're typing: left/right arrows.

Frequently (though not always) instead of the cursor moving left and right, the Timeline panel's playhead might nudge forward and backwards.

It's a little more dramatic with Cut and and Paste Cmd-X, Cmd-V, where instead of cutting and pasting in the <input> element it's happening to your sequence -- literally removing / adding edits to your sequence instead of text in the panel.  For those who like living dangerous that's good adrenaline, but it can be a death blow to a deliver deadline.

Here's what's going on:

Clicking on the HTML / body area of a custom panel doesn't automatically activate (create the blue outline around) the panel itself.  In other words, you can interact with a custom panel without activating, leaving some other panel still active.

Note: The panel can be manually, forcibly activated by clicking the tab area at the top of the panel, but until that moment the panel operates in a kind of in-between state where some keystrokes interact with the panel, others with whatever other panel in Premiere remains highlighted.

This is not standard behavior in any other Premiere panel.  If you click anywhere in a Timeline, Program, Project, Mixer or any other panel, by default the panel is fully activated.

To recreate this issue:

Load any custom panel.

Then click on any other panel in the project to activate it (outlined in blue)

Then click on the custom panel, not the tab area at the top, but the main area where the content is.

Notice that it does not activate (highlight in blue).

Keystrokes subsequently typed will affect the still-highlighted panel.

Looking toward a solution

Is there a command, either in JS or JSX that might be employed to force panel activation?

The closest thing I found so far is a 2018 post hoping for such a command, but it wasn't looking promising.

Per Bruce B it was put in as feature request B-125639 with the suggestion to check back after NAB and ask "Hey, whatever happened to API feature request B-125639?"  I'm thinking it might finally be post NAB 2018 and ok to follow up on that question.

[R Neil Haugen]

What are you referring to by a "custom panel" ... one created by perhaps a scripting operation?

As I can't replicate this with any panel 'native' to Premiere, not even the Red Giant Universe plugins when opened as a panel ...

Neil

[Bruce Bullis]

custom panel = CEP-based panel, hosted in an Adobe point product. The Red Giant Universe Dashboard is an example. 

[Premiopolis]

Also = Custom Extensions you can download here: https://exchange.adobe.com/my-exchange.html

Here's a link introducing it way way back in 2013 (older than I realized)

If I can sing their praises: A lot of things that you wish an editing system can do can be made to happen with custom extensions.  Connecting an external data-based logging system to augment the Project panel, integrating transcriptions, exporting reports, automating transcodes and exports, naming convention assistance -- endless.

To replicate with a 3rd party extension -- one I didn't build -- I used "Property Explorer" (thanks Sir Editor who suggested it) but there are plenty more.

[Bruce Bullis]

You're always welcome to ask questions. 
As you've guessed, no progress has been made toward B-125639. 

As a design principle, Adobe's applications rely on user interaction to activate panels. [We're selfish about activation.]

It's likely that Adobe won't fix this CEP issue, prioritizing instead our move to supporting UXP extensions, which have a very different host UI interaction model. 

Sorry to not be more helpful, with the enquiry.

[Premiopolis]

> Sorry to not be more helpful, with the enquiry.

Always helpful.  Thanks.  I'll make it work.

RE UXP extensions... What actually is (or will be) UXP extensions?

In an earlier post you distinguished it from New World Scripting.

What is the difference between the two?

For that matter why UXP  and New World vs Classic Custom Panels?

Will UXP be an upgrade of custom panel scripting -- based on JS, or is it something entirely new?

[Bruce Bullis]

New World = calling existing ExtendScript engine, through the "new plumbing" through which we also call the modern, V8-based scripting engine we'll use for UXP. 

Not an intended change, but the New World doesn't perform default type coercion (to string), so you have to pass in the right param type. 

UXP = Whole New Thing™. Adobe XD is the only application shipping a UXP-based API, but that will change soon. 

https://adobexdplatform.com/plugin-docs/

One key difference: In UXP, instead of a JavaScript (CEP) layer and ExtendScript (host app scripting) layer, there's just one (JavaScript) layer.

[Premiopolis]

The countless hours devoted to figuring out how to properly pass data back and forth between front end and back end  (or JS layers anyway)-- and now you're saying that skillset is just goes into the dustbin of history?  Very much looking forward to that.

What about existing extensions built on the 2-layer (JS/JSX) architecture?

Will they need to be converted to single layer?

Will UXP use the same API or allow for easy migration, or is it an entirely new API requiring considerable code conversion?

[Bruce Bullis]

> What about existing extensions built on the 2-layer (JS/JSX) architecture?

Existing CEP extensions will continue to be supported, until many months after UXP extensions (which the UXP team insist on calling 'plug-ins' even though they are demonstrably not plug-ins, which are by definition compiled, but are rather interpreted extensions) start being supported. 

> Will they need to be converted to single layer?

UXP plug-in versions of existing CEP extensions, will need to be written. 🙂 As soon as PPro builds containing support for third party UXP extensions plug-ins become available, we'll spread the news far and wide. 

> Will UXP use the same API or allow for easy migration, or is it an entirely new API requiring considerable code conversion?

The plan is for the current ExtendScript API to be available to UXP...plug-ins.