-
Suggestion
-
Resolution: Won't Do
-
0
-
3
-
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
Hi everyone,
Thank you for raising and voting on Making ESC Key Behavior Consistent Description and Comment Edit Operations. Your feedback is invaluable in shaping and enhancing Jira for all users.
Given the high volume of feature suggestions for Jira and issues in particular, we must prioritize those that provide the most value to the majority of our users. After a thorough review by the team, we have decided that we will not be able to implement Making ESC Key Behavior Consistent Description and Comment Edit Operations in the immediate future.
Please remember that jira.atlassian.com is only one of many inputs for our roadmap. We’re continuously learning, analysing and interviewing customers to make Jira better. We encourage you to also share your feedback through Atlassian Community. Please also check out latest updates and upcoming plans from the Jira Cloud roadmap and the Atlassian Cloud release notes blog.
We understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions or feedback.
Regards,
Angela Hawkins
ahawkins@atlassian.com
Product Manager, Jira Cloud
Description:
What happens currently when editing a description is that your edits are discarded if the Escape key is pressed.
There are many reasons why the Escape key can be pressed by mistake in today's browser use and varied workflows, and so users end up losing their unsaved descriptions.
Furthermore, Jira itself encourages the use of the Escape key to clear the focus of the current fields.
If you click away from a description edit box to lose focus, your work is saved. However, if you use the Escape key to lose focus, your work is discarded. This is inconsistent behavior.
The above behavior is in contrast to how editing comments behaves. When editing comments, navigating away whether by click, escape key, or page refresh, will popup an alert for the user to confirm their action (when there are changes to the comment).
I'm not sure why editing comments is given so much more importance than editing issue descriptions, but both edit operations should behave consistent with eachother, as it is confusing for the user to have separate behaviors depending on what you edit.
What should happen:
1. Make editing issue descriptions behave the same way as when editing comments.
- Alert box will show when there is risk of losing changes.
2. As a way of allowing users to preserve current behavior with mininal disruption, provide users a way to configure the behavior of the ESC key in description boxes. Possible (but not exaustive) list of choices:
- Escape to discard changes, no confirmation (Current behavior, should be default for existing accounts)
- Escape to discard changes, require confirmation (Can be default for new accounts)
- Escape to save changes, no confirmation (Alternatively, can be default for new accounts)
- Escape only to lose focus but leaving text area in edit mode
- Do nothing
See: my previous comments for a longer rant on this topic.
- is related to
-
JRACLOUD-39031 ESCAPE key destroyed my edits
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
- Closed
- relates to
-
- Gathering Interest
[JRACLOUD-41814] Make ESC key behavior consistent across description and comment edit operations
That mirrors my experience on Jira Cloud, Anusha - yes, confirmed. Including the "unsaved changes" label next to the word "Description"
Hi 58e3fdfd9145 Thank you for explaining this - here's what I see when editing the description of an existing issue:
Steps to repro
- Open an existing issue and start typing in the description field. Do not click Save
- Press the escape key
- Observe that the Description field goes out of focus and the text you typed disappears but a label saying "Unsaved changes" appears next to the word Description
- Click back into the Description field and the text you typed will still be there
- Hit escape again, and when the Description field unfocuses, hit the escape key for a second time. This will close the issue pop-up.
- Reopen the same issue. Observe that the saved draft is still there.
Can you let me know if you are seeing different behaviour on your Cloud instance?
That's for creating new issues; I may be mistaken but I'm pretty sure that it's always done that if you hit ESC or cancel when creating a new issue.
When editing descriptions in an existing ticket, it still silently exits edit mode without any prompts when you hit ESC. The good news is that lately it does seem to preserve what I typed on both Chrome and Firefox if I click on the description field again after hitting ESC; have others observed this improved behavior in Jira Cloud?
There is now a pop-up confirmation when you hit escape while editing an issue:
If the watchers agree, I suggest that the title of this issue might be edited to refer solely to the ability to configure the behaviour of the ESC key. I will wait a week before making any changes in case anyone disagrees.
These kinds of inconsistencies are annoying for experienced users who want to be more productive, and confusing for new users.
Absolutely infuriating behavior. This wastes at least an hour of my time every couple weeks. Tremendously poor UX.
Yes, please fix this. I was entering a description, need to use a slash "/" which bought up a context menu I didn't want. Fair enough - happy to have that shortcut - but I closed it with Escape and it close the "new issue" dialogue so my work was lost.
Work being lost is surely a sign this might be a fairly critical issue, is it not?
Plus the corresponding server (vs cloud) bug report says this is fixed... fixed in one SKU and not the other?
It also affects my team.
Saving the current work as a draft is the best solution, similar to Confluence, but a simple prompt before closing the pop-up or enabling "full mode" instead of a pop-up is also acceptable.
I concur - my team is still affected as well. Our lead programmer remarked the other month that they hate that editor, they've lost so much work to it, as have I. And it still gets us sometimes. I just encountered it when pressing CTRL+SHIFT+ESC to bring up task manager while I was editing a description, and it dumped the edits without warning.
By contrast, editing a comment ignores the ESC key, and clicking "Cancel" prompts, "You have entered a comment on this issue. If you navigate away from this page without first saving, the comment will be lost."
When they decided on JRASERVER-36670: "After careful consideration, we've decided to prioritize making ESC key behaviour consistent across description and comment edit operations on Jira Server roadmap.", I was expecting that they'd also apply the changes to Jira Cloud. It's a good idea.
(And no, it doesn't give any indication that Description edits are pending, nor does it recover the edit when clicking on it again. We use the plain text editor.)
Hi dfb61e047700 and watchers of this issue, as per my previous comment, I would like to update this issue to refer solely to the ability to configure the behaviour of the ESC key. I believe the other elements of this feature request have now been met. Please let me know if you disagree.
Please note we do have a related open feature request that you may wish to vote for and watch: JRACLOUD-23284 Add a confirmation dialog display on the Click of Cancel Button when editing field on existing issue