Skip to main content
Karsten.G
Karsten.G
Known Participant
September 4, 2026
Question

SDK - Floating and modal dialog windows do not shrink to fit smaller content on reopen (save_frame)

  • September 4, 2026
  • 9 replies
  • 47 views

Environment

  • Adobe Lightroom Classic 15.5
  • Lightroom SDK
  • Windows 11 and macOS 26.5
  • Standalone reproducer plugin attached

Summary

A dialog window created with a save_frame parameter does not always shrink to fit smaller content on reopen. When a dialog is closed and reopened with a smaller content view, the window keeps its previous (larger) frame instead of resizing down to match, leaving a strip of unpainted native window chrome along the right and/or bottom edges. Growing the content works correctly in every case tested.

This affects both presentFloatingDialog() and presentModalDialog(), and is platform-dependent:

Dialog type Platform Shrinks window to fit smaller content?
presentFloatingDialog() Windows No — border left
presentFloatingDialog() macOS No — border left
presentModalDialog() Windows Yes — correct
presentModalDialog() macOS No — border left

 

Windows + presentModalDialog() is the only combination found that resizes the window correctly to smaller content in every case tested.
 

Steps to Reproduce

  1. Install the attached reproducer plugin via File > Plug-in Manager > Add.
  2. Run File > Plug-in Extras > Floating Dialog (save_frame) Repro.
  3. A window opens with a red content pane filling it edge-to-edge, plus "Smaller" and "Larger" buttons.
  4. Click Larger a couple of times — each reopened window correctly grows to fit the bigger content (fully red, no border).
  5. Click Smaller — observe whether the reopened window shrinks to match the smaller content (fully red) or leaves a border of native window chrome along the right/bottom edges (part of the window is grey/white, not red).
  6. Repeat steps 2–5 with File > Plug-in Extras > Modal Dialog (save_frame) Repro.
  7. Repeat the whole test on both Windows and macOS.

The floating dialog also has resizable = true set, so as an alternative to step 5 the window edge can be dragged smaller by hand — this reproduces the same border artifact. (presentModalDialog() has no resizable parameter, so this alternative only applies to the floating case.)

A complete standalone reproducer plugin is attached.
 

Expected Result

When a dialog with save_frame is reopened with smaller content, the window frame should shrink to match the new content size on every platform and for both dialog types, the same way presentModalDialog() on Windows already does.
 

Actual Result

The window frame stays at its previous (larger) saved size in three of the four dialog-type/platform combinations tested (see table above). The content pane correctly reflects its new, smaller size, but the window around it does not shrink to match, leaving a visible border of native window background along the right and/or bottom edges. Growing the content back up always resizes the window correctly.


Additional Information

  • The reproducer's floating and modal dialogs use an identical view hierarchy and identical save_frame usage — only the presenting call (presentFloatingDialog() vs. presentModalDialog()) differs, isolating the behavior to the SDK's window-sizing logic rather than to anything in the content view.
  • The reproducer's "Smaller"/"Larger" buttons drive the resize by changing the content's pixel dimensions and reopening the dialog (rather than manual dragging), which matches how a real plugin dialog is normally resized — e.g. a photo/preview view created at specific pixel dimensions — rather than the user dragging an edge.


Impact

This prevents plugin dialogs that vary their content size across separate opens (e.g. a preview or data view that grows or shrinks depending on what's selected) from resizing their window to fit, on nearly every platform/dialog-type combination. Instead, once the window has been enlarged, it stays enlarged even when the plugin author intends a smaller window for smaller content — leaving a visible band of unused window space around the actual content.


Attachments

Standalone reproducer plugin SaveFrameResizeBug.lrplugin
Screenshot: Initial dialog.jpg
Screenshot: Dialog after 2x Larger, then 2x Smaller.jpg

 

 

    9 replies

    johnrellis
    johnrellis
    Legend
    September 4, 2026

    [View this post in your web browser. It contains formatting and images that don't appear in email.]

     

    (presentModalDialog() has no resizable parameter, so this alternative only applies to the floating case.)

     

    `presentModalDialog()` does allow the resizable parameter. Here’s an example:

    local LrDialogs = import "LrDialogs"
    local LrView = import "LrView"
    local f = LrView.osFactory()

    local result = LrDialogs.presentModalDialog {
        title = "Resizable", resizable = true, 
        contents = f:edit_field {value = "Hello\nworld", fill = 1}}

     

    See the attached screen recording.

    johnrellis
    johnrellis
    Legend
    September 4, 2026

    [View this post in your web browser. It contains formatting and images that don't appear in email.]

     

    Thanks for submitting this. Some of my plugins have long tripped over this bug on both Mac and Windows, but I never submitted a bug report, guessing that the developers were unlikely to fix the issue. But the current team has tried to address some other problems with floating dialogs this year, so maybe they’ll fix this one too.

     

    As an example, with the Any Filter’s Filter floating dialog:

     

    When a user deletes one of the columns, it results in this:

     

    For this plugin, I’ve used the “resizable = true” workaround, preserving the window’s previous position but requiring the user to resize the window manually. 

     

    Both workarounds (“resizable = true” or using a new value for “save_frame”) require the user to do something manually when the window’s content shrinks. Either the user has to resize the window or move the window back to the desired position.

     

     

      john beardsworth
      Community Expert
      john beardsworthCommunity Expert
      Community Expert
      September 4, 2026

      You are right about what happens, and it would be good if it didn’t. However, what you can do is read save_frame from a preference or variable which you can reset.

        Karsten.G
        Karsten.GAuthor
        Known Participant
        September 4, 2026

        Oh, really? How can I do that?

        john beardsworth
        Community Expert
        john beardsworthCommunity Expert
        Community Expert
        September 4, 2026

        For example, in  LrDialogs.presentModalDialog you have save_frame = ui_frame

        You need to store the value of ui_frame and retrieve it before the LrDialogs.presentModalDialog function is called. I just keep ui_frame in preferences, with the string "1234" as the initial value which is easy to increment from a button in the UI, for example.

         

        Terms & ConditionsAccessibility statement
        Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices