Last modified: 2013-11-11 09:37:55 UTC
To reproduce: 1) Go to "my preferences", and click save button. 2) On this new page, you'll get a green message indicating that you've successfully updated your preferences. Now click on the "Special page" tab; you should expect to land on Special:Preferences. Instead, you land on Special:Preferences&success and the green message is shown again. This causes confusion; by clicking on the special page tab, you're not updating preferences so you shouldn't get the green dialog.
Suggested fix: Check if request mode is POST; don't show the green dialog if this is a GET request.
Fixed with r70585.
Reverted with r70746.
At the moment the form is POSTed to /wiki/Special:Preferences. The server answers with 302 and redirects to /wiki/index.php?title=Special:Preferences&success=1 The server should answer with the preferences page with success box directly on the POST request.
(In reply to comment #4) > At the moment the form is POSTed to /wiki/Special:Preferences. The server > answers with 302 and redirects to > /wiki/index.php?title=Special:Preferences&success=1 > > The server should answer with the preferences page with success box directly on > the POST request. No, it should not. This is PRG[1], that is by design and on purpose with a redirect at the end. The resulting page shows the preferences page, which should be a permalink to that. Refreshing manually or by a browser recovery should not re-submit the (potentially outdated) form information. What could be done instead is write a core js module (always loaded) that submits through javascript. That way the submission does not occupy the browser window and the url never has to include "success=1". Instead, the callback handler would put up that message programmatically (probably through mw.notify, while at it). As fallback for non-javascript it can stay as is (though it could be improved). [1] https://en.wikipedia.org/wiki/Post/Redirect/Get
Ok, re-sumit the (potentially outdated) form information by refreshing the page or by browser recovery is a good argument against a simple POST. When a new submit though JavaScript with mw.notify for notification is implemented, most users with JavaScript enabled don't use the browser submit anymore. Of course, a fallback for non-JavaScript must exist. What about a page /w/index.php?title=Special:Preferences&success=1 with just a success message and without the preference settings? So the user has to load /wiki/Special:Preferences again for changing further settings. With this combination it not possible to have unsaved changed settings and a success message on the same screen, which is confusing.
