Last modified: 2014-03-19 19:35:21 UTC
The default sessionfailure message reads: 'There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please hit "back" and reload the page you came from, then try again.', This is not a super great suggestion -- hitting 'back' and/or reloading will in some browsers lose your form state, so you've now lost all your work and have to start over. In most cases, the correct fix is actually to more like *hit the submit button again*, since the rest of your form state will be preserved... possibly going to login and preview beforehand, though. Generally this kind of sucks.
(In reply to comment #0) > This is not a super great suggestion -- hitting 'back' and/or reloading will in > some browsers lose your form state, so you've now lost all your work and have > to start over. Are browsers still so stupid? Firefox has always handled this quite well, I think Chromium does too, of course I don't know about IE.
Adding many blockers of bug 38638 to the list of "easy" bugs, to mark them as candidates for [[mw:Google Code-in]] tasks (gci2013). If you think this bug is not suitable, remove the keyword.
Change 96370 had a related patch set uploaded by Mayankmadan: Replacing please hit back and reload with click the submit button https://gerrit.wikimedia.org/r/96370
Change 96370 abandoned by Bartosz Dziewoński: Replacing please hit back and reload with click the submit button Reason: Since you submitted another patch for your GCI task instead, I am assuming you do not want to follow up with this. Closing the changeset here; if you ever want to return to it, just click "Restore". https://gerrit.wikimedia.org/r/96370
Per Siebrand's code review on the above patch, not so easy. Patch amounted to: - Go back to the previous page, reload that page and then try again. + Click the submit button again. Review was: > Hmm. This message is a bit awkward. It's for example also used in > dieUsage() in ApiMain and ApiPersona: > $this->dieUsageMsg( 'sessionfailure' ); > The suggestion that is being added here is most probably not correct > in that case. Not sure what the correct solution is; maybe splitting > up in multiple UI strings (one for non-interactive interaction (pun > intended) and one for interactive use cases) (?).