You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @nishantwrp — I looked into this. I think the root cause of the auto-resize/contract glitch @amandamcg reported is that the dialog is left at the default setFitToContent: true, so Joplin's core app is auto-sizing the iframe to content height dynamically. That fights with the max-height: 80vh; overflow: scroll CSS added in 0aa28b4 — the host app measures/sets the iframe height before the CSS constraint settles, causing the grow-then-shrink behavior.
I think the fix is to call joplin.views.dialogs.setFitToContent(viewHandle, false) when the variables-form dialog is created, which locks it to a fixed 90vw × 80vh per the plugin API docs. That removes the conflicting auto-resize entirely, and the existing overflow: scroll on .variablesForm should then work as originally intended inside a stable container.
I'd like to take this on and open a PR — will test with both a small and a large number of template variables to make sure there's no regression on the normal case. Let me know if that approach sounds right to you or if I'm missing context.
I've opened a PR that I believe fixes this properly: #179
Turns out the root cause was that the dialog was left at Joplin's default setFitToContent: true, so it auto-resizes the iframe to content height dynamically — which races against the plugin's own max-height/overflow CSS from the earlier fix. Explicitly setting setFitToContent based on variable count (true for ≤5 vars, false for >5) resolves it.
Tested manually on Windows across multiple variable counts and orderings — details and screenshots are in the PR description. Happy to make any changes if you'd like a different threshold or approach.
Activity
PriyankaaXD commentedon Sep 14, 2026
Hi @nishantwrp — I looked into this. I think the root cause of the auto-resize/contract glitch @amandamcg reported is that the dialog is left at the default setFitToContent: true, so Joplin's core app is auto-sizing the iframe to content height dynamically. That fights with the max-height: 80vh; overflow: scroll CSS added in 0aa28b4 — the host app measures/sets the iframe height before the CSS constraint settles, causing the grow-then-shrink behavior.
I think the fix is to call joplin.views.dialogs.setFitToContent(viewHandle, false) when the variables-form dialog is created, which locks it to a fixed 90vw × 80vh per the plugin API docs. That removes the conflicting auto-resize entirely, and the existing overflow: scroll on .variablesForm should then work as originally intended inside a stable container.
I'd like to take this on and open a PR — will test with both a small and a large number of template variables to make sure there's no regression on the normal case. Let me know if that approach sounds right to you or if I'm missing context.
nishantwrp commentedon Sep 14, 2026
@PriyankaaXD sounds good, please go ahead!
fix: explicitly set dialog fit-to-content based on variable count
PriyankaaXD commentedon Sep 16, 2026
I've opened a PR that I believe fixes this properly: #179
Turns out the root cause was that the dialog was left at Joplin's default setFitToContent: true, so it auto-resizes the iframe to content height dynamically — which races against the plugin's own max-height/overflow CSS from the earlier fix. Explicitly setting setFitToContent based on variable count (true for ≤5 vars, false for >5) resolves it.
Tested manually on Windows across multiple variable counts and orderings — details and screenshots are in the PR description. Happy to make any changes if you'd like a different threshold or approach.