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

View 2 revisions


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

View 2 revisions

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?

Issue History

Date Modified Username Field Change
2010-10-27 08:50 mwyraz New Issue
2010-10-29 04:31 yw84ever Note Added: 0027191
2011-03-14 11:40 johsin18 Note Added: 0028416
2011-03-14 13:07 dregad Note Added: 0028417
2011-09-09 03:55 dregad Relationship added has duplicate 0013299
2011-09-09 05:07 jmichae3 Note Added: 0029668
2011-09-09 05:32 dregad Note Edited: 0029668 View Revisions
2011-10-27 04:58 djsmiley2k Note Added: 0030084
2011-11-02 10:07 mwyraz Note Added: 0030147
2011-11-02 11:06 dregad Relationship added related to 0009323
2011-11-02 11:13 dregad Note Added: 0030148
2011-11-03 17:36 jmichae3 Note Added: 0030156
2011-11-03 17:40 jmichae3 Note Edited: 0030156 View Revisions
2011-11-22 12:15 rombert Relationship added has duplicate 0013548
2012-01-20 10:57 Alain Frisch Note Added: 0030977
2012-01-31 09:04 dregad Relationship added related to 0013246
2012-06-22 06:05 atrol Relationship added duplicate of 0009609
2012-06-22 06:05 atrol Status new => resolved
2012-06-22 06:05 atrol Resolution open => duplicate
2012-06-22 06:05 atrol Assigned To => atrol
2012-07-02 03:20 atrol Status resolved => closed
2017-09-10 06:33 atrol Relationship added related to 0023326