We’re developing a CEP extension for Premiere Pro. One of our features requires a specific native panel (Program window, project window or timeline window etc.) to have focus(tiny blue line) for a menu command to be enabled.
Since clicking any button in our CEP panel transfers focus to the panel’s webview, we need a way to programmatically return focus to a native Premiere panel.
We’ve tested the following approaches(almost i guess ahah) all failed:
ExtendScript / QE DOM:
No app.executeCommand(), app.getCommandId(), or any command dispatch method (these exist in After Effects but not Premiere)
Fully enumerated QE DOM (qe, qe.project, qe.project.getActiveSequence()) , no command execution or focus methods found
qe.executeConsoleCommand() with .kys command names returns false
ScriptUI Window(‘palette’) not supported in Premiere
CEP:
Photoshop has com.adobe.PhotoshopLoseFocus CSEvent to release panel focus back to the host. Tested com.adobe.PremiereProLoseFocus and variants, Premiere does not respond to any of them
csInterface.closeExtension() hides the panel but does NOT return focus to any native panel
registerKeyEventsInterest() intercepts keys in the panel, cannot send keys to native panels
window.blur() / document.activeElement.blur(), DOM-level only, no effect on native panel focus
preventDefault() on mousedown, does not prevent native-level focus transfer
UXP (Premiere v25.6):
No focus management API
No command dispatch (batchPlay is Photoshop-only)
Caption API is minimal (getCaptionTrackCount, getCaptionTrack only)
macOS Accessibility / AppleScript:
Premiere exposes only 2 top-level AX elements: AXLayoutArea (0 children) and AXMenuBar
No panels, track headers, or internal UI elements are accessible
perform action “AXPress” on disabled menu items executes without error but has no effect
Keystrokes sent via osascript (from both CEP Node.js and external processes) always route to the CEP webview
CGEventPostToPid cannot target specific panels within an application
Other:
Premiere MCP Server (269 tools) — same ExtendScript/QE limitations
Pymiere, PremiereRemote — same limitations
Premiere Pro appears to be the only major Adobe application with no command dispatch API from any scripting layer. After Effects has app.executeCommand(), Illustrator has app.executeMenuCommand(), Photoshop has batchPlay(), InDesign has app.menuActions. Premiere has nothing equivalent
The only known working approach is a C++ Control Surface Plugin (as proven by PrControl), but that’s a significant development effort(i guess)
Is there any method(documented or undocumented) to either:
Set panel focus programmatically from CEP/ExtendScript/UXP?
Dispatch internal Premiere commands (e.g. from .kys command names) from script?
Congratulations. It appears you have explored just about every possibility and workaround in existence for Premiere on focusing windows.
Your assessment is correct. Premiere does lack a lot of the APIs for executing commands and focusing windows that other apps like Photoshop and After Effects have.
If the command you’re looking for is listed in the Control Surface SDK, then you’re in luck, you can automate these commands by building a C++ Control Surface plugin. Only limitation here is that the user has to enable the Control Surface in their preferences in order for this to work.
If the command your looking for is not listed in the Control Surface plugin, then you’re stuck with automating keystrokes on the OS level unfortunately which isn’t great.
@bbb_999 Once you guys wrap feature parity with UXP and start adding new features, a similar API like After Effects has for executeCommandId() to fill in the API gaps would really help in situations like this.
For a variety of reasons, Premiere is unlikely to create that “be more like After Effects” new layer of commandID handling, which Justin (rightly) proposes, any time soon.
We would rather figure out ways to unblock your specific case, before we’re all driving hover cars.
Thank you @justin2taylor and @bbb_999 , really appreciate the responses and here are some specifics that can help you understand the case better.
So our CEP extension needs to trigger menu commands that require Timeline panel focus specifically commands under the “Graphics and Titles” menu.
the problem: the moment a user clicks any button in our CEP panel, focus transfers to the webview and those menu items become grayed out. We have no way to return focus to the Timeline panel programmatically.
for example we’ve confirmed the internal command name from the .kys file (cmd.graphics.upgrade.caption.to.graphic), and it works perfectly via keyboard shortcut when Timeline has focus manually, so the command itself isn’t the issue, it’s the focus transfer.
What would unblock us is any of:
A way to release CEP panel focus back to the last active native panel (like Photoshop’s com.adobe.PhotoshopLoseFocus but for Premiere)
A way to set focus to a specific native panel from CEP/ExtendScript/UXP
A way to execute internal commands without the panel focus requirement.
Thanks @bbb_999 ,so yeah i tested the activeSequence approach. Setting it (even to the same sequence) executes without error, but it only changes which sequence is loaded in the Timeline. it doesn’t transfer panel focus. The menu item stays grayed out.
i’ve pushed it a bit further: created a temp sequence via newSequence(), which switched the Timeline to that sequence, then switched back to the original via openSequence(), then deleted the temp. This actually restored Timeline panel focus, the sequence switch forces Premiere to re-activate the Timeline panel.
But: here is the catch.. caption selection is lost during this switch. Aand SyntheticCaption track items don’t expose setSelected() (regular video TrackItem objects do), and there’s no captionTracks collection on the Sequence object to enumerate and re-select them. So even though we got Timeline focus back, the captions are no longer selected, and the menu item remains grayed out.(so again same problem if we got the focus we lose the selection, and we cant select the items again)
Is there a simpler way to just set panel focus from ExtendScript/CEP? Something like app.setFocusedPanel(“timeline”), or any mechanism
that transfers focus from a CEP panel back to a native panel without side effects? and also is there a way to select clips-items in caption tracks just like video or audio track?
Hello Bruce, man thank you very much for pointing me in the right direction with trackItem.setSelected(). i’ve built a working pipeline for my feature and It works end-to-end. So reaaly appreciate it.
Our next challenge: We need to style Graphics Clips via ExtendScript.
I’ve dumped the component tree and found AE.ADBE Text exposes Source Text (plain string), Scale, Opacity, Position, but no font, fontSize, fillColor, stroke, or shadow etc. properties.
Is there a way to programmatically set text appearance on Graphics Clips?
For example, passing a JSON structure with font family, size, and color to setValue(), similar to how MOGRT text properties work via getMGTComponent()?
Or is there an alternative API path we’re missing?
I love it when my untested suggestions are actually helpful!
Not today, though you’re not alone in wanting that.
Our current priority = parity, so “make it possible to do with .mogrts via UXP, what I used to do via ExtendScript”. Expanding API access to all text layers would need to happen later.
ahh sad to hear that, i really thought you were the only key that could unlock this for me haha
couple days ago i discovered that no subtitle tool out there has an export option with graphic titles.. most of them are using mogrts. which made me realize, if we could have this feature it would be much easier for users to update a typo or something from the script. so much easier to manipulate based on what the user wants.
and as u know there was no direct way to create graphics clips programmatically
so i thought of a bit of a long workaround pipeline.. what if we first export the srt> then import and add it to the timeline>then upgrade them to graphics> and then set the subtitle specifics based on user’s choice.. anyway
i was very hopeful tbh until seeing your message but no worries, it was a good run for me at this point
