View Issue Details

IDProjectCategoryView StatusLast Update
0012492mantisbtbugtrackerpublic2017-09-10 06:33
Reportermwyraz Assigned Toatrol  
Status closedResolutionduplicate 
Product Version1.2.3 
Summary0012492: Complete input get lost when timeout or not filling all required fields (when using ssl/https)

When not all required fields are filled, an error message occurs. It says to go back with the browser button fo fix the error. But when using SSL, the browser will not restore the field values so anything typed in the form get lost.
Same applies if the security token times out or any other error occurs.

Possible solutions:

  • Simplest: show all submitted fields on the error page to allow the user to copy it back to a new form
  • Prefered: Add a button that posts all entered data back to the original form
  • more prefered: Show the form plus an error message instead of an error page
TagsNo tags attached.


duplicate of 0009609 acknowledged Blank input fields lead to complete loss of typed in data if HTTPS is used 
related to 0009323 closedjreese Browser caching broken since 1.1.2 
has duplicate 0013299 closeddregad when sitting at bug for long time and adding long note, erroneously claims I submitted twice, loses my note 
has duplicate 0013548 closedrombert form field is reset 
has duplicate 0013586 closedrombert form field is reset 
related to 0013246 closeddregad APPLICATION ERROR #2800 when submitting notes 
related to 0023326 closedatrol preventing data loss 




2010-10-29 04:31

reporter   ~0027191

I had a similar issue. Users were leaving the entry open for a long time, eventually editing bit by bit, then submitting. By the time that happened though, MantisBT showed that the session had timed out. Browser Back, data had been lost (though it seems some browsers were capable of storing it).

Solution has been twofold: training on using MantisBT ;) and increasing the time before PHP garbage collection occurs.

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
; default: session.gc_maxlifetime = 1440
session.gc_maxlifetime = 86400



2011-03-14 11:40

reporter   ~0028416

SourceForge supports MantisBT as "hosted app", and users are forced to use https there. So this bug applies for all the proejcts there, and this is a very annoying bug.



2011-03-14 13:07

developer   ~0028417

Nice catch with the SSL here ! I have been wondering for some time why this was happening on the timeouts.



2011-09-09 05:07

reporter   ~0029668

Last edited: 2011-09-09 05:32


Invalid form security token. Did you submit the form twice by accident?

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.

EDIT: dregad, adding additional text from jmichae3's note 0013299:0029669

I don't know how much this helps. the tokens I make for my apps are time-based+ a few other things - if you stored yours in a session, HOW you make use of it is very important to having success in a form. I typically put the token in a hidden form field rather than session only, the reason being that SESSIONS EXPIRE.

I may get back to finishing my form entry after a 1-2 days do to the nature of life in general happening. I can't control everything in life.

I don't know what code is killing the security token.



2011-10-27 04:58

reporter   ~0030084

Also have this issue. Users screaming and shouting '(Personally don't know why they can't just hit submit at the time - add extra notes when you need to but hey!)'

Increasing garbage collection timeout would be ok if I can set it for JUST mantisBT, but I have no idea how I'd do this so....



2011-11-02 10:07

reporter   ~0030147

I finally solved the problem. Because some users complained about caching issues, i tired to find out, why some special cache-control headers where set with mantis. I finally found out that these headers where caused by
core/session_api.php: session_cache_limiter( 'private_no_expire' );

After changing it to session_cache_limiter( 'none' ); the cache issues disapeared.

And the best: the problem described above disapperared as well!

Now on errors after input, i can simply press browser-back, i can press reload to obtain a new transaction id and i can edit and send again - even with SSL enabled.



2011-11-02 11:13

developer   ~0030148

This setting in the session api was introduced as part of a fix for 0009323.

John, as author of this change could you comment on validity of fix proposed by mwyraz ?



2011-11-03 17:36

reporter   ~0030156

Last edited: 2011-11-03 17:40

it takes me a long time to edit bugs. the best solution is one which does not timeout on me. one which is not time-based. sometimes it takes me all night or 2 days (type in at night, finish in morning with machine on if I have to) to type in a bug report. if it's fixed and this is not a problem, yahoo!

Alain Frisch

Alain Frisch

2012-01-20 10:57

reporter   ~0030977

We're also regularly confronted to this timeout problem, but on regular http connections (not https). This happens for new bugs and new notes. It is of course very annoying to loose a carefully written text... Should I open a new bug for it, or assume it will be fixed at the same time as the https case?