Page MenuHomePhabricator

"Restore all default settings" should be a button
Closed, DeclinedPublic

Description

"Restore all default settings" in Special:Preferences should be a button, just like "Save" and "Undo changes". The text link looks odd at the moment.


Version: 1.21.x
Severity: minor
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67338
https://bugzilla.wikimedia.org/show_bug.cgi?id=68689

Details

Reference
bz18961

Event Timeline

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

By the way, did anybody ever try it? I did and clicked confirm, and it didn't restore
anything, maybe due to a lack of saveSettings().

A button executes an action, this does not. It takes you to a confirmation page. I think this should be marked WONTFIX, but I'm open to third opinions.

Thanks for the report as to it not working, I've added saveSettings() in r51420.

Hold on, no wonder I'm the first person on the planet who ever dared
to click the "Restore all default settings" button (in the lab, of
course): How can the user click it with any confidence, when the only
information he knows about which settings he will be getting restored
back is only marked for one!:

(*) MonoBook (default) (Preview)

The rest are a mystery as to what the defaults he is about to get are.
The best he can do is create another account and see what they look
like, but we don't want him to do that. Therefore, please somebody add
"(default)" to each of the remaining items. Thanks.

(P.S., and no fair using e.g., sneaky CSS. Must work just like the Monobook line above, so text browsers can see the defaults too.)
P.S. welcome to split off another bug if Summary should stay put.

Marking this bug as Lowest priority.

I've done this in a batch to (usually enhancement request) bugs where:

  • It is not clear that this bug should be fixed.
  • It is not clear how to fix this bug.
  • There are difficulties or complications in fixing this bug, which are not justified by the importance of the bug.
  • This is an extremely minor bug that could not be fixed in a few lines of code.

If you're interested in having one of these bugs fixed, your best bet is to write the patch yourself.

  • Bug 19952 has been marked as a duplicate of this bug. ***

Proposing WONTFIX as per comment 2.

(In reply to comment #7)

Proposing WONTFIX as per comment 2.

I respectfully disagree.

The fix should be as simple as creating another form. Just set the method to get, the action to the URL of the verification page, and have the one submit element with no name and the value "Reset all default settings". Since the form has nothing to pass, it goes to the page with no values added.

  • Bug 53900 has been marked as a duplicate of this bug. ***
saper closed this task as Declined.EditedOct 29 2015, 7:05 PM
saper claimed this task.
saper subscribed.

I'll be bold and wontfix this for now. It is quite good that those functions are different visually:

  1. The first one ("Save") is used 1000x more often than the other one ("Reset all default settings").
  2. The second one ("Reset all default settings") is a destructive option (seldom used).

Just like the "Forgot your password?" option is usually less prominent in the UIs as the "Log in" option, it is perfectly okay that the "Reset" is a relatively obscure link.

Having both of these displayed as visually equivalent may imply dichotomy similar to what the "OK" / "Cancel" buttons offer. In a typical "OK / Cancel" scenario both offer the way to exit a (usually modal) form. OK is a bit more likely, but Cancel is not as destructive as our "Reset".

Actually I am more afraid that this perfect imbalance will be broken by T67317, introducing big red button for Reset, maybe.