An original dispatch-note form sometimes contains one sentence and sometimes a pasted inspection log. A tall empty editor wastes space on the first note. Unlimited growth can push the form's remaining fields far down the page on the second. Bounds should suit both.
Set the content growth limits
Merge these options into the existing TinyMCE initialization for the actual textarea:
tinymce.init({
selector: '#dispatch-note',
plugins: 'autoresize',
min_height: 180,
max_height: 520,
autoresize_bottom_margin: 16,
autoresize_overflow_padding: 12
});
The numbers are illustrative pixel settings for this form. Preserve the application's other plugins, toolbar controls, styles, license configuration, and deployment settings. The fragment needs an existing #dispatch-note element and a TinyMCE installation that loads the plugin.
Start with a minimum that leaves enough room for a normal short note beneath the editor's controls. A narrow toolbar can occupy more vertical space when its layout changes, so inspect the complete editor at the widths the form supports. Avoid choosing the minimum only from the height of the text itself.
max_height supplies the upper bound. Without an intentional maximum, a long note can continue growing along with the page. A bounded editor should still let the author reach its final paragraph by scrolling inside the editing area.
Account for the space around the words
autoresize_bottom_margin adds space below the content. An unexpectedly large empty area can come from that setting as well as from actual blank paragraphs. Inspect the document before deleting trailing content to compensate for layout padding.
autoresize_overflow_padding controls horizontal padding in the editor. It is not a guarantee that an arbitrary pasted table or image will fit. Check wide content with the application's actual content styles and image behavior.
The plugin operates on editor height. A surrounding fixed-height panel, clipped overflow, or constrained flex layout can still hide the lower edge or controls. Inspect the computed dimensions of the editor and its parents if it grows internally but the page shows a cut-off box. Repeatedly increasing max_height cannot remove clipping imposed by an ancestor.
Distinguish internal scrolling from page overflow
For the dispatch form, try these separate content states:
| Content | Intended observation |
|---|---|
| One short instruction | Editor stays near its useful minimum |
| Several ordinary paragraphs | Editor grows with the note |
| A long inspection log | Growth stops at the chosen maximum; final paragraph remains reachable |
| Most paragraphs deleted | Editor shrinks again while respecting its minimum |
Run these checks in the actual form that will host the editor.
Use a final log sentence such as “Return the test key to the dispatch desk.” Scroll to it, put the cursor there, and edit one word. This tests whether the last instruction is usable, rather than merely proving that a scrollbar exists. Repeat at a narrow form width and check that a page-wide horizontal scrollbar has not appeared.
Keep sizing separate from the stored notice
The height of the authoring surface does not belong in the notice's business content. The TinyMCE extraction guide explains capturing the current HTML for the application's real save path. Autoresize does not submit that value or confirm persistence.
After finding suitable bounds, save the long note and reopen it. Read its final dispatch-desk instruction in the intended reader view too. The author needs a manageable editing surface, while the recipient needs the complete log regardless of the editor height used to write it.