Page MenuHomePhabricator

Session failure warning message ('sessionfailure') gives bad advice
Closed, DeclinedPublic

Description

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.


Version: unspecified
Severity: enhancement

Details

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:25 PM
bzimport set Reference to bz17029.
bzimport added a subscriber: Unknown Object (MLST).

(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) (?).

Firefox doesn't save form state on HTTPS pages

Change 181812 had a related patch set uploaded (by Unicodesnowman):
Give better advice for sessionfailure

https://gerrit.wikimedia.org/r/181812

Patch-For-Review

Thanks. Will most users understand what is meant here by "submit button"? I'm not sure.

It should probably be changed to "Save page button", since the button to publish your edits says "Save page". I wouldn't exactly go with "Submit" on this one.

Firefox doesn't save form state on HTTPS pages

Are you sure? Firefox 34 doesn't seem to, at least not on mediawiki.org.

At least some parts of the code that use the "sessionfailure" message don't reshow the submitted form, hence the advice to "go back and reload".

You're right, Firefox does do that now.

Given that and certain places the sessionfailure messages shows up in, the current message is appropriate.

Change 181812 abandoned by Unicodesnowman:
Give better advice for sessionfailure

Reason:
See comments on https://phabricator.wikimedia.org/T19029

https://gerrit.wikimedia.org/r/181812

You're right, Firefox does do that now.

Did we test this in the main other browsers as well? (I'm biased, but Firefox is usually better at not losing data. :P)

I've tested this with Firefox & Chromium on mediawiki.org, form data was both preserved for me. Don't have IE to test.