Page MenuHomePhabricator

Update dialog shown when clicking on the special page tab after saving preferences
Closed, ResolvedPublic


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.

Version: unspecified
Severity: enhancement


Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:03 PM
bzimport set Reference to bz24700.
bzimport added a subscriber: Unknown Object (MLST).
Huji created this task.Aug 6 2010, 7:00 PM
Huji added a comment.Aug 6 2010, 7:02 PM

Suggested fix: Check if request mode is POST; don't show the green dialog if this is a GET request.

Huji added a comment.Aug 6 2010, 7:08 PM

Fixed with r70585.

Huji added a comment.Aug 9 2010, 6:34 AM

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


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.

Sn1per added a subscriber: Sn1per.May 9 2015, 6:52 PM

Similar to T19496 ?

Similar, but not the same – however, this was actually fixed by the patch for that bug, 6d3c65b5b022c4844710a50a6cf12f18f16c40d9 :D ("Remove success=1 querystring on load to prevent unnecessary reappearance of notification on reload.").

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 21 2015, 10:36 PM
matmarex closed this task as Resolved.Dec 21 2015, 10:37 PM
matmarex assigned this task to Sn1per.
matmarex set Security to None.
matmarex removed a subscriber: wikibugs-l-list.
Fomafix reopened this task as Open.Dec 22 2015, 6:01 AM

Reopen. The bug still exists as described. A click on the "Special page" button generates the success dialog message again.

Indeed. The query string is removed client-side at runtime, but the "Special page" tab is generated server-side and contains the query string regardless.

Change 260966 had a related patch set uploaded (by Sn1per):
Remove success=1 from Special:Preferences "Special Page" tab after notif display

The Printable version also generates a success message.

Change 261033 had a related patch set uploaded (by Gerrit Patch Uploader):
Preferences: Use cookie instead of URL parameter for success

Change 260966 abandoned by Sn1per:
Don't include success=1 in Special:Preferences "Special Page" tab link

Superseded by I1c2b011e7a66b2b9379dd4a3fdcc6f978dd43b52

Change 261033 merged by jenkins-bot:
Preferences: Use session data instead of URL parameter for success

Sn1per closed this task as Resolved.Jan 10 2016, 4:15 AM
Sn1per reassigned this task from Sn1per to Fomafix.