Page MenuHomePhabricator

ULS should indicate when display preferences change is complete
Closed, ResolvedPublic


In Display Settings/Fonts, change the font in the selectbox
Quickly click for a random page in the wiki

New font is likely not displayed

Changing preferences for fonts takes some time, on the order of several seconds. Suggest a spinner or other acknowledgement to the user that the preferences have been changed successfully.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:51 AM
bzimport set Reference to bz53772.

Change 82654 had a related patch set uploaded by Cmcmahon:
changing prefs takes a long time, see Bug 53772

Could it be this occurs because the changes to the DOM are made first, and only then the setting is saved in the local storage? If so, it may be possible to fix this by saving the preference first.

A spinner or something while the settings are saved would be useful here I think

The preferred solution here is to ensure that the preference is saved as soon as possible, and that no spinner is needed.

I don't understand what your point is. The preference is saved immediately and the time it takes to save the preference for logged in users is dominated mainly by network latency and then server side processing. IMHO optimization of either is not in scope for this bug. We cannot know beforehand whether spinner is needed.

We have been using the spinner to indicate that data will be loaded there. Here, the dialog is about to close and a spinner would probably only add distraction.

I propose to communicate the storing without adding new elements by doing all the following:

  • Button label change to ("Applying changes" or "Applying settings")
  • Button become disabled
  • Cursor changes to "progress"

I made a quick example to visualise it at

(In reply to comment #8)

I made a quick example to visualise it at

That looks fine, Pau. One possibly drawback is that the button size is changing, which is also a distracting element. This could be circumvented if the button width would initially be that of the widest width needed for any string that might be used in that button.

Change 95353 had a related patch set uploaded by Santhosh:
Visual indication while saving the settings

Change 95353 merged by jenkins-bot:
Visual indication while saving the settings