Mantis timeout when typing in a response

This is a follow-up to a previous thread about Mantis - invalid security token which I ran into yet again. It’s quite frustrating because I had typed in the results of an hour of work/debugging and attached images and a patch. Luckily I have the image and the patch, but the text is all gone. Using Back on the browser does not bring the text back. In the previous thread @sam888 asked what the error message was, so here it is (below). It would be awesome if the timeout could be extended to a couple of hours at least. Thank you.

Off to recreate my train of thought for Mantis.

APPLICATION ERROR #2800

Invalid form security token. This could be caused by a session timeout, or accidentally submitting the form twice.
Please use the “Back” button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

Yeah, MantisBT is a pure misery in this respect.

I cannot tell you the number of bug reports I’ve lost due to the security token timeout. And usually, they are the more intricate reports that require extra experimenting or complex reproduction workflows. Those are the reports where you have to spend more time working on filing a good report. So when the ‘back’ button suggestion ALWAYS fails to recover any data, it inspire something like ‘road rage’.

It might be less annoying if it were more predictable. But the timeout seems to fluctuate between 30 minutes and 4 hours.

I stopped reporting bugs and faults because of this…

Because even when I wrote the text in i.e. Word first and then copied the text, it often failed in the process of adding attachments and doing the same work 2-3-4 times, it’s just not worth the time vs. the response.

@StoltHD I share your pain, but your input is valuable to the Gramps community so hope you keep contributing. I have run into this only a few times over the last few years, but that doesn’t lessen the frustration. I’m going to change my modus operandi to keep notes in another app like you do. When I’m completely ready to put things into the bug report, I’ll refresh the bug report page to reset the timeout token then start typing/copy/pasting into the report.

This is a case of software training users how to work :slight_smile:

Opened another discussion in August of the problem on the MantisBT support forum.

The thought occurs that popping another browser window (with the unvalidated contents of the Form) when this validation error occurs would bypass the lost data aggravation. You’d still have to freshen the session, then copy’n’paste and you’d probably lose attachments… but that is much better than a complete lost.

I never had multiple Mantis sessions open when this thing happens, but I have always a lot of browser session opens for other services and sites.

I even tried to use separate browsers (Vivaldi and Firefox) without any other open sessions, didn’t help, the timeout still occurred…

Another browser window isn’t part of the issue reproduction process. But since the form submit process and caching are not working, having the submit spawn a preview would create a scratchpad woarlaround.

Ugly… but viable with their current design.

It didn’t work even in a clean new browser session in another browser, after that I gave up, long time ago…

Yes, what I’m suggesting is a feature request I made on MantisBT’s support group. It isn’t something you can do yet.

If it is implemented, you wouldn’t have to do anything. The MantisBT form validation behavior would change to become slightly less aggravating.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.