Thank you so much Jira I just lost an hour and a half of work since I accidentally hit the escape key on your awesome dialog box!!

In Cloud at least, even if you navigate away from the page, if you haven't saved, it'll still be there when you revist. This is within the last year or so only.

There used to be a Chrome extension that saved my sanity many times when this issue was still a thing: Typio form recovery. https://chrome.google.com/webstore/detail/typio-form-recovery/djkbihbnjhkjahbhjaadbepppbpoedaa (had to go find my original post from here to remember what it was called https://jira.atlassian.com/browse/JRACLOUD-36670)

This is marked at low priority but it is EXTREMELY FRUSTRATING to lose your work due to a single key press.

This popped up again on a Jira cloud instance - typing in...

`./

In the rich text editor brings up a menu, which I instinctively hit escape to close the menu... and the issue is gone. This is very bad design, it is unbelievably annoying, and it caused me to have to type in ticket multiple times. I'm not going to bother using the Jira editor if I can help it, rather copy/pasting from a real editor that doesn't destroy my notes when I press escape.

Please fix this absolutely broken behavior.

This is very frustrating, specially when the emoji pop up appear, the first thing that comes to my mind is to press ESC to close that popup, but it's causing to loose all the changes !

https://gfycat.com/negativemammothchick

And when creating a new bug, I get a pop-up saying that navigating away will lose changes (when I hit escape) - that also makes sense in that context.

Since I filed this bug and there's not been a firm update from Atlassian, I'm glad to say that I think this issue has been addressed on Cloud.

Now, when I hit escape, the edit window still disappears without keeping changes, BUT, there is a little box indicating that there are unsaved changes and if click edit again, the unsaved edits appear in the edit box. This is perfectly acceptable behavior from my perspective. 

I am running JIRA-Server and in the process updating to latest... thank you.  I tried the Typio for Chrome, and it does not recognize my version of Jira (description) html-edit boxes (although I see it is recognizing this box .  Generally speaking I do the "external edit" then copy-paste, which is a pretty lame way to use a web site.  But this problem is not unique to Jira – it just strikes more because of the level of work.  I also use Azure Devops and it works a bit harder to make sure you don't unsaved accidentally.

@mark208, install Typio and this will be a thing of the past. It'll still happen, but it's like a magic undo button. 

@Mark Juras, they claim that it's fixed for Jira Server under JRASERVER-41814 around June 2018, judging by the last updated date.

However, JRACLOUD-41814 is still "gathering interest".

Lost 5 minutes of work a last week. And 10 just now.  Arg!  Where do we vote to get this fixed??

I just had this happen to me again, and I have to give @Josh Loe credit here, because the Typio extension that he recommended recovered what I'd entered beautifully. I've used it a few other times where I've accidentally closed a window, or similar, and it's great. It sits there in the background until you need it, and it turns what would be a super-frustrating event into a mild inconvenience. I have mine set to only show itself when I double-click in a field, so I don't even see it unless I need it.

Highly recommended, especially for readers of this thread.

Arghhhhhhhhhhhhhhhhhhhhh, Pleeeeeeeeeeeeeeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaese fix this soon. That was 6 months ago.

The problem is that if you click save, you will spam your entire audience with half-baked updates to a story. Not a good idea.

But if you hit escape - there goes another mornings work. I will try that chrome tool until Atlassian realize a purist UX principle has lead us all down a rabbit hole where I can't even find my last couple hours requirements.

Google never looses your drafts and they know a thing or two about UX. 

Quoted from Suggestion ticket JRASERVER-41814 today, reproduced here for reference:
 

Atlassian Update – 23 February 2018

Hi everyone,

After careful consideration, we've decided to prioritize making ESC key behaviour consistent across description and comment edit operations on Jira Server roadmap.

We hope to start development after our current projects are completed. Expect to hear an update on our progress within the next 6 months.

To learn more on how you suggestions are reviewed, see our updated workflow for server feature suggestions.

Kind regards,

Jira Server Product Management

I just lost 4 hours of work due to accidental press of ESC key :/

Poor web-world that needs a plugin for an obvious bug of a commonly used software... but anyway thanks! Unfortunately, doesn`t work for me in Jira 7.0.0

Until we get a proper fix, I can share this with you: https://chrome.google.com/webstore/detail/jira-anti-escape/ojlicbnjmjflndeachpneoalfifchppb

It's a chrome plugin that looks for ESC presses in textarea#description nodes on whitelisted domains (settings) and opens a popup that will warn you about discarding changes.

It works for me, your mileage may vary

Shiny new MacBook Pro, with touch bar brought me here.. I've started writing tickets in an IDE and just paste it into Jira now. Surely some kinda of prompt/confirmation would prevent such a simple issue.

Dear @Lev I'm sorry to disagree but if you had lost hours of work due to this issue like some of us have you wouldn't say that...

As a veteran on Jira I came all the way here only to say this ESC button issue is just so f****** ridiculous! Hitting the escape key on any other popup/window (not on Jira) ruins my edit work time after time. Honestly, it looks to me that you're creating issues in order to sell improvements that solve them.

This is not resolved. After spending 20 minutes on a Ticket, I hit escape by accident and Poof. 

Hello,

  Why not simply prompt for confirmation in case any edit has been done, otherwise close the edit mode?

  Thanks,

I've disabled keyboard shortcuts and this is still happening. Shouldn't this behavior be considered a "keyboard shortcut"? The UI already has an X button to cancel edits, so there is a non-keyboard way of doing things.

Just got bit by this and lost a bunch of work

Looks like the problem fixed in new JIRA interface.

This behaviour frequently results in me losing work, whenever I use the search box in the Chrome browser.

When I have a ticket with a long description, I often use Chrome's search box to find text snippets within the description.  When I'm done, I press Esc to dismiss the search box.

And then I lose all my work, because the Esc action is applied not just to the search box, but to the JIRA editor too.

Please fix this. Now. There is no reason that justify this behavior.

The issue type is also Suggestion, but I imagine that is why it hasn't been closed yet. Perhaps if others can comment there instead of here, it will draw more attention to that issue.

@jedwards1, I didn't see an intended fix in that ticket, which is still unassigned?

There is a different issue linked to this one which describes the intended fix, and it should take care of this: JRASERVER-41814

@drew.leske, in Atlassian everyone doesn't care. They are not losing data, so welcome to the club of ignored people.

Anybody watching this (other than other customers experiencing this)?  I also use Vim for other editing and lost two separate edits this afternoon because I am so used to hitting Esc before saving.  

Esc clearing a multiline textfield is not correct behaviour any more than is ignoring all the above customers .  

Perhaps it is correct for a text input box.  That would make some sense.

Just lost 30 minutes to this. Ridiculous!

I don't understand why "loosing hours of work" is of low priority for Atlassian. I documented today, that even ESC in other applications (like Windows Menu, properties dialog, ...) may destroy your current content. Not a good decision to define this as a feature, not a bug.

absolutely terrible - this is a major bug - just lost 30 minutes of changes with no way to get it back.

almost ready to quit using JIRA for this 'feature' - who's the PM in charge of this disaster ???

It's extremely frustrating when it happens and I'd ask you to reconsider. It isn't good UX imho, when a main description field with rich text formatting where people are writing full specs to loose all its information with a simple press of Escape. Make it configurable or be smart about it (only ask after 1min of the first actual change) or have a checkbox at the bottom of the field like Facebook's "Press Enter to Send" it could be a "Press Escape to discard" that's remembered... anything. The way it stands, you're training people the hard way to not type anything longer than a sentence in the description field.

I know this has been marked as "Won't Fix", but surely the number of people complaining about this "feature" literally for years might be a clue that your UX attitude is out of step with what your customers want.

Yes, I just lost a bunch of work by accidentally bumping the esc key while writing a tech spec. And yes, all my co-workers just laughed at me and said "NEVER use the JIRA editor you idiot, ALWAYS write your tasks in Notepad and then copy & paste when you're done!" Is that the reaction you want people to have to your web application? To advise everyone to avoid using it and do as much as possible in Notepad?

PLEASE at least add an option to put a confirmation when hitting esc to close an edit box which has had changes made in it!

@atlassian, I just lost more work due to this "feature".

When will an enhancement be prioritized within your product backlog?

I've never worked with an application before that causes me to lose work on a (semi) regular basis as does JIRA.

Just lost 15 minutes worth of work to this. At very least you could add a user-configurable "Please destroy all my hard work" confirmation prompt on a per-user basis.

Though I'm not a fan of the me-too comments, this happens to me quite too often. Just lost 20 minutes of work. This has to be fixed Atlassian, or at least make this behavior switchable so one has the choice to alter some 'default behaviour'. When this is client induced, just offer me the auto-save Confluence offers me.

Why?!? Why this silly problem is still exists in Jira?

Actually we could prompt users before 'escaping' their changes but this probably would slow down the majority of use-cases. Don't you think? With this change we would break the most common flow of using the Esc button.

I just lost 20 minutes of my work... How much time other people lost with this?

I have been following this for a while now and even though I'm careful to not use the Escape key it still makes me lose work from time to time!

Now 2 examples to demonstrate the confusion and inconsistency of this behavior:

1. When creating a new issue, a modal appears. If I enter some text in the description and hit escape a popup appears warning me that all changes are going to be lost if I continue. If I enter text in the issue description while being in the issue view (not in the modal) and hit escape no dialog warns you, but your changes are simply discarded.
2. When editing a comment and accidentally navigating away from the page a popup appears asking if I really want to discard my changes, if I dismiss it using the Escape key, my changes are not lost and I can keep on editing the comment, as expected. However, when editing the description and accidentally navigating away from the page again a popup appears asking if I really want to discard my changes, if I dismiss it using the Escape key, my changes are lost even though my action obviously intended not to discard my changes.

Of course the Escape key should be used with caution, but as described above the it is not always clear when the use of escape actually discards changes. In general, before losing potentially hours of work the user should be warned or at least given the opportunity do undo his mistake. Please change the behavior, it is a major inconsistency within JIRA and has lead to a lot of headaches and wasted working hours!

I've trained myself to not hit ESC while editing descriptions. Circumstances still led to Jira capturing an ESC keypress and losing a complex technical edit just now. In other situations I would have saved or applied every few minutes, but on Jira I don't want to send multiple e-mail notifications to the six people watching the ticket as I edit and re-edit the description.

I was using CTRL and SHIFT to select blocks of text and edit it, and I accidentally hit DEL while still holding *both* CTRL and SHIFT. CTRL+SHIFT+DEL brings up the "clear history" dialog on Firefox. I hit ESC to get rid of the clear history box...and it canceled all my edits without asking if I was sure

Steps to reproduce:
1. Using Firefox*, edit a description in a Jira ticket.
2. Hold CTRL+SHIFT and hit left arrow to select some text.
3. While holding CTRL+SHIFT, press "DEL" (as if intending to delete the text, while forgetting what your left hand is doing). Observe the "Clear All History" window pops up.
4. Hit "ESC" to get the clear history window out of the way.
5. Jira cancels editing of the description and loses the edits unrecoverably.

* - Note: In this particular case, I would have been fine if I'd been using Chrome, because the "Clear browsing data" window opens in a separate tab, and hitting "ESC" on a separate tab doesn't affect Jira.

Not to say that I haven't accidentally lost my edits when I pressed ESC for plenty of other reasons, too. As Gabe noted, this is especially difficult for vi users, as they have a save reflex that involves first hitting ESC to exit edit mode.

That this is labeled 'Won't Fix' and the subsequent explanation I think really belies how little you understand your users or perhaps the lack of imagination and problem solving that your engineers employ.

If a user has made any significant number of changes to a document, no preventable action should be allowed that causes the immediate loss of all work done. I think you'd be hard pressed to find any serious user that would be OK losing 30 minutes worth of editing because of an accidental or habitual press of the escape key. I think any user that is willing to simply discard 30 minutes worth of work is going to be the outlier.

Wiki quote from Krzysztof Piwowar]: "... use of escape as a shortcut in dialog boxes for No, Quit, Exit, Cancel, or Abort, as well as a common shortcut key for the Stop button in many web browsers". – But we're not dealing with a Dialog Box or a pop-up or a modal. We're talking about a text field that is being used for direct document manipulation. If you opened ANY text editor, wrote a line and hit esc, the result would be nothing. Your text would remain. Your UI/UX engineers aren't correctly equating the context of the experience.

Regardless, implementation of functionality that guards against significant data loss could be provided and could be made configurable as an aspect of the users own settings without disrupting anybody else's work flow.

I can't believe how much time I've lost due to this issue over and over and over again. But rather than correctly or effectively address the issue, the Atlassian response (like so much of their other responses) is 'Get used to our way'.

When the most commonly employed tactic for interacting with your tool is to go use something else first, I think you're missing the mark.

If you'd like to see an example of a successful resolution to this type of issue, I recommend reviewing Jetbrains YouTrack issue tracker. You'll notice that if you hit 'esc' whilst editing an issue, a small modal appears only if you've actively made changes. On that modal is a checkbox labeled 'Do not suggest this confirmation'. Hitting esc again (correctly) dismisses the modal and returns me to the document without discarding my changes and still in 'edit mode'. If I hit Enter instead, my changes are discarded and the rest of the modal is accessible via Tab and Space.

Thanks Atlassian!
@kpiwowar

This might be a different issue but ESC-aping from Alt-Tab also causes text to be reset and lost.

To reproduce:

1. start entering text in a JIRA Description
2. press alt-tab to change window
3. then decide not to change window so press ESC to exit the window changer
4. the text you started to enter is lost

It seems that jira is receiving the ESC sent to the window changer.

I am using Linux and am not sure if this affects windows or not.

I've defined this problem proposed an improvement for this in JRA-61439

Please watch / vote for it.

Bump for bad UI. Lost another 10 liner.

Seems like a quick js hack to turn it into double escape in succession or cmd+esc / alt+esc.

I'm Chinese and we always use input method to type Chinese. And if I types something wrong on input method, I press ESC to cancel. But i also lost my text. It's really a bad experirence.

ESC can be hit for many reasons, some already mentioned. But also when it was meant for another window. Some I already ran into:

• multiple screens
  Meaning to Esc-ape something on one screen, which has my visual focus (my eyes), but accidentally not the keyboard focus.
• shortcuts
  • Esc-aping from Alt-Tab, but I guess I hit Esc twice? (or long?)
    Oh no, do not switch application. I do want to copy&paste something to my Jira-description, but it's in another tab on my browser
  • meaning to press Ctrl-Esc (shortcut Windows Start Menu), but I guess I hit Esc first?

+1 again. Just lost a 10 line description. Can Ctrl + Z actually undo this or something?

+1. Just lost 30 line description. Why can't hitting the back button bring me back to the modal? Some way to go back or undo the close.

Marius, thanks for the hack-around!