I believe this feature was introduced within the last 24 hours.
Currently, if a prompt is too long, it is automatically collapsed when loaded. This is now the default behaviour.
A collapsed prompt can be fully expanded by pressing “Show more”. An expanded prompt can be collapsed by pressing “Show less”.
Personally, I would prefer all my prompts to remain fully displayed, as this new feature makes my workflow more cumbersome:
- When I send a long prompt, I have to manually expand it.
- When I load a chat, I have to manually expand all the prompts I need.
- When I save a chat as an .mhtml file, all prompts are collapsed in the saved file, even if they were expanded at the time of saving.
I would like to propose one of the following improvements:
- Add an option in Settings to disable prompt collapsing entirely.
- Add an option to change the default behaviour so prompts are not automatically collapsed when loaded.
Same here. This is especially disruptive for long-form writing and editing workflows. I also save chats as MHTML, and even after expanding prompts before saving, the saved MHTML file still keeps them collapsed. Please add an option to disable automatic prompt collapsing or preserve expanded prompts when saving/exporting chats.
Welcome to the community, @niji48 🙂
You both are definitely not the only ones running into this. The extra clicks become pretty noticeable once you’re working with long prompts, revisions, or archived chats. The MHTML behavior is especially frustrating since expanded prompts currently don’t seem to persist in the exported file.
We’ve forwarded the feedback from both of you to the team for logging, including:
- Option to disable automatic prompt collapsing
- Option to keep prompts expanded by default
- Preserving expanded state in exports/saved MHTML files
This feels like a UX change that helps readability for some cases but creates friction for heavier workflows, especially writing/editing use cases like yours.
Appreciate both of you sharing concrete examples since that context helps a lot when these requests get reviewed.
-Mark G.
Thank you, Mark. I found an additional related issue while testing this further.
This does not seem to affect only MHTML saving. Saving as PDF has the same problem.
It looks like the chat page is now using virtualized/lazy rendering. Only the messages around the current scroll position seem to be present in the page. When I use Ctrl+F in a long chat, terms that should appear many times throughout the conversation only return a few results, depending on what part of the chat is currently visible.
As a result, when I save the page as MHTML or PDF, the saved file only includes the currently rendered/visible section of the conversation. Earlier or later messages are missing unless they happen to be rendered at that moment.
This makes local archiving unreliable, because saved MHTML/PDF files may no longer contain the full conversation at all.
Could you please also forward this to the team? Saved/exported chats should include the entire conversation, not only the currently rendered viewport.
Hi @niji48, appreciate you digging into this further. What you’re describing does line up with virtualized/lazy rendering behavior, and I can see why that breaks trust in local archives if exports only capture the currently rendered portion of the chat.
I’ll make sure these findings, including the Ctrl+F behavior and incomplete MHTML/PDF exports, get forwarded to the team as part of the same issue report. Definitely useful detail for reproducing it consistently.
-Mark G.