The Prompts site recently developed a problem. This issue makes it very difficult to refine prompts (aka messages, aka inputs).
-When you click “edit” to modify a message in the right-side panel, clicking the scrollbar to move to another part of a long message immediately cancels the editing mode.
You have to use a cursor with a keyboard - where the cursor also scrolls below the viewable area, because the messages are overlaid with the big input box at the bottom.
I understand why clicking elsewhere is used as a quick way to exit editing mode. It avoids the need to scroll all the way back up to find the save button in a long message. However, this new issue makes the playground nearly unusable. Right now, the only way to move around in a long message without losing editing mode is by using the cursor keys, then try to scroll around to get the cursor back into view. Even then, selecting large sections of text can also cause problems.
A good UI
A simple solution would be to add a top bar at the beginning of each message. This top bar would clearly show where each new message starts, making it easier to see separate messages in the current white blur. The top bar could include a toggle button to switch between “rendered” and “editable” modes. Alternatively, you could place this toggle at the top of the entire user interface, making it easy to switch modes consistently across the site.
Thanks! Those buttons could be unattached and hover (as does a ChatGPT markdown code fence block’s “copy”), as another brainstorm to not need to find your way over to the main scrollbar, along with the right panel being its own overflow flex container with independent scroll that stays entirely visible, instead of a lower z-index than the input text field covering it.
I have received the fix. Closing messages on reaching for scroll does not close editing (but yet clicks in other areas closes editable boxes, and means one has to go searching again for the edit button off-screen in what was meant to remain interactive). Also noted is the “collapsed message” behavior.
Major new issue
However, I must report another highly-damaging behavior:
Editing of message boxes can completely erase the contents unexpectedly, with no ability to recover the contents of a now-empty user or assistant message. This can happen on either pane side.
Case: moving generated context “forward” into the “multi-shot” area, to build a new calculated message, out of documentation and described needs. Whether a click on the checkmark, or simply by pressing another panel, when editing and a “close” is triggered, you get unpredictably…
BOOM: entire contents of message box is erased, unrecoverable. The session and work is destroyed.
This has happened in multiple instances.
Additional major issue
Editing a message box and making significant changes: One presses the [ENTER] key. That the editing is closed instead of inserting a linefeed is bad enough, but additionally:
BUG: all editing is discarded upon pressing {enter}
Hey @_j, would you mind sharing a screen recording or gif of this behavior? I can’t quite get it to repro on my end, so I must be missing a step or two. Thanks!
Inability to save and share a state of the user interface with support: An attempt to create a preset messing up the presentation and the convenience of the interface by moving everything to the left panel.
No adding to the right panel without running AI on it.
I’ll see what I can do about loading the UI up again against annoyances…
Principle of least astonishment → most befuddlement
Then add onto the pattern problems:
system message: ready for you to interact any time.
vs other messages:
ready for your futile attempts to do so
ready for you to lose “edit” at any time without visual indication if not markdown
ready for copy across a table or other rendering to be damaged clipboard
move text box to box? Inscrutable.
the button just clicked on jumping out of scroll display.
mystery buttons for you to find, if you can hover
paste clipboard and lose all linefeeds, even between areas
ctrl-shift-v the copied output and get no plaintext clipboard except a “SYN” byte.
how do you get the preset panel’s scrollbar? Random proddings, or maybe mouse wheel 20 spins?
What will enter key do? At least three different behaviors depending on the focus.
New message added or not? Hope you didn’t have whitespace to break your expectations…
I really appreciate seeing OpenAI Support here on the forums—recently I have been feeling that a lot of my feedback is falling on deaf ears. This is very encouraging to see. Thank you @OpenAI_Support
– 24 hours later, this continues to destroy data. Of course, after complete browser shutdown and restart and hard refresh (putting the 30 day “history” only in local browser storage makes complete browser cleanup a data destruction also).
Example: I just want to pick “edit” so that I can edit a user message (and/or even simply copy clear text out of a user message in edit mode for safety now) after deleting a poor assistant response. The entirety of the message is wiped…once you scroll back up to find where the checkmark is to “save”.
Hi @_j, thanks again for reporting this! I believe the Enter/Return behavior is by design. New line is "Shift + Enter". Please let me know if you have any questions or further thoughts.
It works fine in Chromium on my same organization on the same machine. Where I have taken my engagements today.
The enter key behavior, when the key is pressed alone, should (with the current poor pattern OpenAI wants) be closing the “edit mode”. Not wiping all the data in the box.
AI might say: “Does this make sense to you?”
It is not a problem with understanding the usage. It is a problem with Firefox implementation. Or the local state of site data, like the 30 day history, bringing out a bug with the client software. And persists. It is not a problem with training me.
Hi all,
Nicholas here — daily user of the model and prompt editor.
I’ve encountered the same bug and wanted to contribute a clear technical suggestion to help resolve it.
Issue recap: On Firefox 137, pressing Enter while editing a message discards the entire content instead of saving it or inserting a line break. This doesn’t happen on Chromium.
Root cause (likely): The default keybinding or event handling on Enter is not being scoped properly in the DOM context. It likely triggers a submit or blur event unintentionally when focus or state is inconsistent (especially when local history or storage is involved).
Suggested fix (dev-level):
Prevent default behavior on Enter in edit mode if not combined with Shift
Explicitly scope the “submit” trigger to a clear UI element like a save checkmark
Ensure all local state syncs only after save is confirmed (not on focus loss or Enter)
This would prevent unexpected data wipes and make the edit experience more stable, especially on Firefox.
Thanks to the team for listening and tracking this. If it helps, I’m happy to test any patch or send additional logs.
I’ve investigated the issue and would like to offer a developer-level analysis and potential fix to help the team address it more efficiently.
Likely Root Cause:
Enter key event is not properly scoped in edit mode.
It may bubble up or trigger a form submit or unhandled blur() event.
This is likely compounded by local storage state (prompt history), which causes an inconsistent UI state or overwrite.
Proposed Fix (Code-level logic):
// In the input editor JS handler
editableBox.addEventListener("keydown", function(e) {
if (e.key === "Enter" && !e.shiftKey) {
e.preventDefault();
// Only allow exiting edit mode if content is valid and not empty
if (editableBox.textContent.trim().length > 0) {
saveEditedMessage(editableBox.textContent); // safely store data
exitEditMode();
} else {
showWarning("Cannot save empty message");
}
}
// Allow line break with Shift+Enter
if (e.key === "Enter" && e.shiftKey) {
insertLineBreak(); // custom function
}
});
And make sure to explicitly control any storage write, like:
function saveEditedMessage(content) {
localStorage.setItem("lastPrompt", content);
// optionally: debounce writes to reduce corruption risk
}
---
Benefits:
Prevents accidental content loss
Brings Firefox behavior in line with Chromium
Allows for consistent multi-line editing via Shift+Enter
Improves reliability of the edit-save interaction overall
---
Thanks again to the OpenAI team for the openness to feedback. Happy to assist with more testing if needed.
Nicholas
If you’ve encountered the same bug, and not just an AI rewriter assuming that, then you would be able to test your unsure bot theory - sourced from the removed “magical thinking” bot paste post.
It is the “edit mode switching” mechanism itself and not a keyboard binding, as pressing the checkmark to “accept” the edit gets the same data loss.
The far better UI would be an “all editable / all rendered” toggle always in the viewport, instead of scrolling around to find an off-screen button in the overflow.
