Page MenuHomePhabricator

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

Description

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

Details

Reference
bz24700

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

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

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

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

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

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

Reason:
Superseded by I1c2b011e7a66b2b9379dd4a3fdcc6f978dd43b52

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

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

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

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