Although I too am a Firefox user, this afflicted me today while I was inadvertently using IE Edge v90, which is built on Chrome. I got a "Session Expired" page in Confluence after working on a post for 2 hours. Thanks Atlassian. This describes how I recovered my submission without any plugins, add-ons, or third-party tools. Summary:

1. Press F12 to open Developer Tools.
2. Go to the Network tab
3. If there is a page with populated with 40x error status, click on it, otherwise refresh.
4. Go to the Headers sub-tab and scroll down to find the Form Data section.

Story

I first pressed the back button expecting to find the same filled in textbox, as Firefox often behaves. But it was empty and pressing the forward button again as suggested here simply showed the same Session Expired page. Even refreshing the page still showed the same error, even though the form resubmit warning popped up. At this point I assumed that all this interaction would surely have overwritten any cached form data I was hoping to salvage. I was prepared to search through a process memory dump at this point.

Next, I pressed F12 to open developer tools, clicked on the Network tab and again refreshed the page. It populated content and showed a document in red (called answerquestion.action in my case) with a 403 status. Although the Preview sub-tab still just showed the same error page, the Headers sub-tab had my work when I scrolled down to the Form Data section! In IE Edge, I couldn't find an "Edit and Resend" option like Firefox has, so I manually copied the html out.

The last time this happened to me 15 years ago, I don't think we had all these newfangled dev tools. I had resorted to installing a core dump tool and had then sifted through the entire thing to find my work. Right now, on a locked down machine, I don't even have admin rights to install anything. So this saved me a lot of time, I hope it helps someone else as well.

*** Correction: although the below does work in Firefox and Chrome, the snapshot in Firefox produces a (gzip'd) binary file. So for now this approach works only in Chrome : (

For both Firefox and Chrome, I think a much easier way compared to an actual core dump of a system process is to use Developer Tools.

Go to the Memory tab (used to be named "Profiles" in Chrome), then take a Snapshot and save it to a file (it's just text). Then search the file for some word that you know you had written in your form – that's probably the fastest way to find the entire content.

I just tested it on Chrome in a page where a dynamic form (JavaScript) messed up by itself and lost all the text I had written. It was still in memory and I could recover it even if I hadn't submitted it yet!

See https://developer.mozilla.org/en-US/docs/Tools/Memory and https://developers.google.com/web/tools/chrome-devtools/memory-problems/heap-snapshots for more details.

Modern versions of Firefox have Developer Tools on board that can be used for this. Press Ctrl+Shift+E (before Firefox 55: Ctrl+Shift+Q) to bring up the Network tool, press F5 to reload the page (confirm the warning that the content will be resubmitted, we want exactly this to happen) and select the (probably) topmost line in the Network tool. It should show POST as method.

On the right-hand side a set of tabs appears. The one we are interested in, "Headers", should already be open. Click Edit and Resend to get the full request contents. The Request Body field contains the full request data in url-encoded form. Run it through a decoder like this one to get your data back.

My method was tested in an emergency case (lost Facebook comment). It needs a third party tool – ProcessHacker. It's only for Windows – for a Linux method, check that question. It should work with every browser, not only Firefox.

There are two methods. First is more user friendly, but if PC would crash, you'd lose data. Second is more fail-safe, but needs an additional tool. With second you'd get a file you can give to some expert, if that tutorial would be too difficult. You can do Method II, steps 1&2 to be safe and then Method I to make it easier. I used Method I.

That's the exact list of steps I took:

Method I

1. The first thing to do is to pause the process. This is critical for success. I opened ProcessHacker (PH), found firefox.exe on the list (you can click on the "Name" column to get rid of the tree view and get a list view) and from the context menu I used "Suspend". Then it would look like Firefox is frozen, so if Windows would ask you about terminating not responding process, don't do it! It's alive, just sleeping.

2. Double click on the firefox.exe row or choose "Properties" from the context menu of firefox.exe.

3. Go to the "Memory" tab and click on the "Strings..." button in the top-right corner.

4. I used default settings ([✓] is checked checkbox, [ ] is unchecked) – Min. len.: 10; [✓] Detect Unicode; Search in [✓] Private / [ ] Image / [ ] Mapped. Click on the "OK" button.

5. After a while (up to minute, but probably a few seconds) you'd get all strings found. With such settings I've now over 700k strings. Check every one searching for the lost text. Just kidding! Go to the next point :)

6. Click on the bottom-left "Filter" and choose menu item that fits you the best. I used "Contains (case insensitive)".

7. Enter some word that was in your lost text. Word because some strings could be saved, e.g., as "foo bar". The longer and more unique word, the fewer results you'd get (so it will be easier). If you don't get results, try another word. I had my comment in two parts of the memory – in one it was full, in other just second half.

8. Look through the results. Most strings will be visible with null character after every char, e.g., foobar will be f.o.o.b.a.r (hex 66 00 6F 00 6F 00 62 00 61 00 72). Don't worry about it; it's the Unicode thing. If you'd find your text click on the "Save..." button. My comment was looking like part of HTML, i.e., it had <div> and <span> tags around.

9. Open the saved file in an editor that supports Unicode. I don't know about built-in Notepad, but it should work. I used Notepad++.

10. Find the text, copy the needed part. Say "hooray". You may now right click on firefox.exe row from the main window and choose "Resume".

Method II

1. Repeat step 1 from Method I.
2. Find firefox.exe row, right click on it and choose "Create dump file..." from the context menu.
3. Use some editor which supports loading big files. Notepad++ should handle it, but you need to turn off syntax coloring and spell checking. Examples: HxD (freeware, IMO better), wxHexEditor (FLOSS).
4. Go to step 10 from Method I.

I found a new addon that can be used to recover lost postdata: Form History Control

The author claims:

This plugin also stores text from editor fields as you type, so you never have to loose your work when disaster strikes. Recover your lost work after session timeouts, network failures, browser crashes, power failures and all other things that will destroy the hard work you just put into writing that important email, essay or blog post.

EDIT: Oh, it indeed saved this post. :)

The Web browser definitely has the form data in memory. The difficulty is : How to retrieve this data ?

Here is my idea. I have not tried it. On paper, it works. This answer applies to Firefox and to other Web browsers.

In short : Reload the page, while examining the headers.

1. Set up the machinery. We need a machinery to examine the HTTP traffic sent from the Web browser.
   • The best choice is the extension LiveHTTPHeaders for Firefox. But I think that installing this extension needs a restart of Firefox. Don't restart Firefox, of course ! It would be nice to be able to install this machinery without restarting Firefox. Otherwise, you just need to have this extension installed beforehand. If need arises, simply use a time machine. ;-)
   • If you cannot have the machinery ready in the Web browser, there is another option. This option is heavier. But its mighty strength is that it works for all Web browsers, and without restarting them. Install a simple Web server, or set up a proxy server (like Squid), on your machine. Make sure that your server logs the inbound traffic, with the full headers. And place a rule in the OS for redirecting all outbound requests towards 127.0.0.1. This can be done with a hosts file.
2. Test the machinery. Create a new window in your Web browser. Write some text in Wikipedia here, and click Preview. Then verify that in your machinery you see your written text. If your machinery is the server option, you have to toggle off the redirection rule to load the Wikipedia form, and to toggle it on afterwards.
3. To reload the page, right-click where the form was, and choose Reload. This is important. In some webmails, this will reload only the frame where the form was. Here we want to reload only as little as possible. If you click the button Reload in the address bar or in the button bar, or if you press Apple R, you risk reloading the whole page, and in some webmails this is shooting yourself in the foot.
4. Normally, the Web browser will ask you : Do you want to send again the form data ? If you get this question, this is a good sign. Choose Send again.
5. Examine the POST data sent, with the machinery set up in the step 1. Here you shall find your wanted data.
6. Come tell us here that this solution has worked !

Another possible solution to recover your data is to make a core dump of Firefox (assuming you are using it under Linux or similar). See this answer for more details: https://superuser.com/a/236400/180675

I'd recommend you to install Lazarus - it has saved my butt enough number of times.

Whew! I figured out a solution -- I was able to hit the "back" and "forward" button with the "Live HTTP Headers" extension capturing incoming/outgoing traffic, and the form information was part of a POST response. (Firefox will resend form input, not sure where that's stored, but doesn't have any obvious built-in way to display it to users)

I'm afraid form contents aren't cached... Regular input fields (single line) may be saved with auto fill, yet text area's (multiple lines, the one that you probably typed in) aren't.