P: Keyboard input routing of floating dialogs depends on prior SDK calls

Environment

• Adobe Lightroom Classic 15.4
• Lightroom SDK
• Windows 11
• Standalone reproducer plugin attached

Summary

A floating dialog opened via presentFloatingDialog() does not consistently receive keyboard input.

The same floating dialog implementation exhibits two different behaviors depending on the SDK calls executed immediately before the dialog is created.

In one case, keyboard input is routed to the floating dialog immediately after opening.

In the other case, keyboard input remains with Lightroom, allowing Lightroom keyboard shortcuts to continue working while the floating dialog is visible.

A complete standalone reproducer plugin is attached.
 

Steps to Reproduce

1. Install the attached reproducer plugin via File > Plug-in Manager > Add.
2. Run via File > Plug-in Extras > Floating Dialog Keyboard Input Reproduction.
3. Choose one of the two test configurations:
   • Plugin dialog receives keyboard input
   • Lightroom receives keyboard input
4. Press the Tab key.

A complete standalone reproducer plugin is attached.
 

Expected Result

The keyboard input behavior of a floating dialog should be deterministic.

Ideally, plugin authors should be able to specify whether a floating dialog receives keyboard input after opening or whether keyboard input remains with Lightroom.
 

Actual Result

The keyboard input behavior depends on the SDK calls executed immediately before presentFloatingDialog().

Using the attached reproducer:

• In one configuration, the floating dialog receives keyboard input. Pressing Tab cycles between the dialog buttons.
• In the other configuration, Lightroom receives keyboard input. Pressing Tab toggles Lightroom's side panels instead.

The floating dialog implementation itself is identical in both cases.
 

Additional Information

The reproducer demonstrates that keyboard input behavior can be influenced by executing the following sequence immediately before calling presentFloatingDialog():

• create a short-lived LrFunctionContext
• show a modal progress dialog
• execute catalog:getPublishServices()
• yield repeatedly while the progress dialog remains open
• close the progress dialog
• call presentFloatingDialog()

The exact purpose of this sequence is unknown. It merely demonstrates that keyboard input routing depends on prior SDK activity.

On macOS, the same reproducer exhibits no observable difference between the two configurations.
 

Impact

Plugins using floating dialogs cannot reliably control whether keyboard input should be captured by the dialog or remain with Lightroom.

Both behaviors are useful in different workflows.

For example:

• A dialog intended for keyboard interaction should receive keyboard input immediately after opening.
• A monitoring dialog that automatically updates in response to Lightroom events may intentionally leave keyboard input with Lightroom so that normal Lightroom shortcuts continue to work.

The current SDK provides no documented mechanism for selecting the desired behavior.
 

Enhancement Request

Consider extending LrDialogs.presentFloatingDialog() with an optional parameter allowing plugin authors to specify the desired keyboard input behavior after opening, for example:

• Floating dialog receives keyboard input.
• Lightroom retains keyboard input.

This would provide a documented and deterministic mechanism instead of relying on implementation-dependent behavior.

Attachments

Standalone reproducer plugin FloatingDialogKeyboardInput.lrplugin

Link to a screen recording displaying the described behavior:

https://www.dropbox.com/scl/fi/ytcz96vucntp4biz4s5d9/FloatingDialogKeyboardInput.mp4?rlkey=apwt8cpxfnd6pragd9alaz8ko&dl=0