I used this One Weird Trick years ago to try to recover a heavily edited but unsaved source file from a frozen text editor (emacs?) on an old SunOS system. I thought I was pretty clever until I realised that the text wasn't stored in a contiguous buffer and I had to spend ages rearranging the out-of-order blocks in the strings output. I suspect now that it might have been quicker to just re-type the original file, but I was stubborn back then.
Before I knew better, I would live edit code directly on the application server. I had a similar crash, deleting all of the files I had opened at the time, and had to rush to recreate those files to get the service back up.
It was a low-stakes scenario, but...now I know better.
I recovered stuff from memory dozens of times, I imagine it's common for technical people...
Anyhow for browsers I long learned to first write in a reliable editor any text longer than a couple lines, you can lose them for a million reasons if you write directly in the browser (to the point that I don't know how people not doing it maintain their sanity...)
And by the way the reason sometimes is that the text gets deleted (e.g. StackOverflow comments....), so I often also leave around in a file for at least some time the stuff that took more time to write
(in the meanwhile genius me tried writing the first version of this message directly in a app, which crashed as I was finishing it :facepalm: )
I now do all my text composition longer than a couple lines either in an email draft or a VScode window that I always have open to a generic “notes” folder.
VSCODE is configured to auto save every time I switch focus or have a short delay in typing.
Though I have rarely faced crashes, the offenders on my side are the website themselves.
For example, after going through all the steps, the website decides to not accept my form because of some JavaScript issue or server issues (such issues either take you to a new page where pressing back button clears all your text)
That's why I started saving the text in a text file before submitting. :)
One simply can not just attach debugger to Firefox on macOS,
> At this time, official builds of Firefox 69 and later are Notarized. As a result, it is not possible to attach a debugger to these official Firefox releases on macOS 10.14+ without disabling System Integrity Protection (SIP). This is due to Notarization requiring Hardened Runtime to be enabled with the com.apple.security.get-task-allow entitlement disallowed. Rather than disabling SIP (which has security implications), it is recommended to debug with try builds or local builds. The differences are explained below.
A potentially better solution that also allows you to use all the functionality of your text editor (in addition to saving input form text in your editor's scratch buffer that survives a crash without core dumps) is to use the GhostText plugin on input forms
Though the best design would be for the OS to be extensible and allow you to use your text editor in any text input form, this way you'd have to care about a lot fewer apps disrespecting users by easily loosing user input
It's really cool, I've added an option to open these windows in floating mode automatically in my sway config through another application name iirc. Ans then I press a simple shortcut, and it opens my editor (Helix) with the already entered text and once I close it, it'll transfer the text from that temporary file which was open in your editor to the the input field/textare again.
The comm with Ghost is real-time, so it doesn't transfer just on close/open (if I understood your description correctly), so you can go drag&drop an image in the form and get a web app's link in the editor right away
But this is still too limited (only browser, needs another window, needs a shortcut)
What stumped me for a bit was that there was a null byte between each character (IIRC). Maybe it was some kind of Unicode encoding or specific to Facebook, I have no clue. But if just searching the string doesn't find it, look around in the dump for other strings and how they're "transformed" for a hint on what to search for exactly.
You can reopen closed tabs and windows from the History menu. It will restore the state of forms, so that form state is retained somewhere (presumably memory).
it used to be considered a common and annoying problem to accidentally type a lot using a different language keyboard (e.g. have English keyboard on, but trying to type Russian in), that a lot of people had an automatic keyboard switcher installed for that case (I'm talking like, 20 years ago)
one popular app for that also contained a keylogger with your whole typing history
somehow i don't miss the switcher, but i miss the history sometimes. it surely would be a security nightmare, of course
I've never understood the reason behind it though, you're either touch typing and looking at the screen, or switching back and forth every couple of seconds to "re-synchronize" and look for typos. People I know haven't used it for longer than a couple of weeks.
