WordPress.org

Make WordPress Core

#20747 closed defect (bug) (fixed)

The list "Display name publicly as" resets when cliking on the "Nickname" label

Reported by: paul.payen Owned by: azaozz
Milestone: 3.4 Priority: normal
Severity: normal Version: 3.3
Component: UI Keywords: has-patch commit dev-reviewed
Focuses: Cc:

Description

In the Screen "Edit Profile".

When you click on the "Nickname" the "Display name publicly as" list resets automaticaly with the username value.

Is this behaviour will be corrected in 3.4 ?

Attachments (5)

defect_nickname.png (17.5 KB) - added by paul.payen 23 months ago.
Defect Screen
initial_list.png (9.6 KB) - added by paul.payen 23 months ago.
This is the initial dropdown list.
final_list.png (7.0 KB) - added by paul.payen 23 months ago.
This is the final list
20747.patch (1.2 KB) - added by azaozz 23 months ago.
20747-2.patch (1.6 KB) - added by azaozz 23 months ago.

Download all attachments as: .zip

Change History (24)

paul.payen23 months ago

Defect Screen

comment:1 nacin23 months ago

  • Keywords reporter-feedback added

I cannot reproduce this in either 3.3 or 3.4. Sounds like a plugin JavaScript conflict.

comment:2 SergeyBiryukov23 months ago

  • Component changed from General to UI

I couldn't reproduce either at first, but then I noticed something strange in Firefox:

  1. Click on the "First Name", "Last Name" or "Nickname" label or input.
  2. Click "Display name publicly as" dropdown.
  3. It gets reset to the Nickname value (or Username, if Nickname is blank).

Not sure if that's the described issue, but sounds similar.

Tested in Firefox 12, Chrome 19, IE 8, Opera 11.64. Only happens in Firefox.

Last edited 23 months ago by SergeyBiryukov (previous) (diff)

comment:3 follow-up: paul.payen23 months ago

Yes Sergey. This is the issue I described. The dorpdown list gets reset when you click(or doubleclick) on labels.

I reproduce in IE8, IE9, Chrome19, Firefox 12.

Thank you for your reply.
My client is very important and is waiting for an answer from us.
Do you think a homemade patch is possible ?

paul.payen23 months ago

This is the initial dropdown list.

paul.payen23 months ago

This is the final list

comment:4 SergeyBiryukov23 months ago

  • Keywords needs-patch added; reporter-feedback removed

comment:5 in reply to: ↑ 3 azaozz23 months ago

  • Keywords reporter-feedback added
  • Owner changed from Paul Payen Amj-groupe to azaozz
  • Status changed from new to reviewing

Replying to paul.payen:

Looking at the screenshot:

This is the initial dropdown list.

Where does the "vide" option in the select come from? That <select> contains the following options:

  • username
  • first name
  • last name
  • first + last
  • last + first
  • nickname

As all fields except "username" are empty, the select should have only that option.

If "vide" it taken from somewhere else, perhaps it should be set as "nickname", then the JS reset would work properly.

comment:6 follow-up: nacin23 months ago

  • Keywords reporter-feedback removed

If "vide" is the current display name set from a nickname, and then the nickname is cleared, it is still a valid display name. The display name field is a dropdown only for convenience purposes; it is not limited to those combinations.

SergeyBiryukov reproduced this, so removing reporter-feedback. It's clearly a JS issue.

comment:7 in reply to: ↑ 6 azaozz23 months ago

Replying to nacin:

If "vide" is the current display name set from a nickname, and then the nickname is cleared, it is still a valid display name.

Right, that makes this an UX issue. Do we keep the old (non-existent) nickname as a display name, or do we remove it when the nickname is removed?

The display name field is a dropdown only for convenience purposes; it is not limited to those combinations.

It is a convenience method to select one value from the four fields above plus two combined values. If it can contain something else, there's no point of having a drop-down. It should be a normal text field so the user is not limited to what can be entered there, generally turning it into a 5th name filed.

comment:8 azaozz23 months ago

  • Keywords ux-feedback added

comment:9 follow-up: nacin23 months ago

Right, that makes this an UX issue. Do we keep the old (non-existent) nickname as a display name

Yes, absolutely.

It is a convenience method to select one value from the four fields above plus two combined values. If it can contain something else, there's no point of having a drop-down.

I disagree. There's nothing wrong with showing a list of defaults but if the default changes, we still keep the old value.

comment:10 in reply to: ↑ 9 azaozz23 months ago

Replying to nacin:

There's nothing wrong with showing a list of defaults but if the default changes, we still keep the old value.

Sounds good. But then why do we limit the user to only these display names? Seems the UI would need to be fixed there to allow the users to enter arbitrary display names (too late for 3.4, 3.5-early perhaps).

comment:11 azaozz23 months ago

Going to try a quick fix so the JS keeps all previous values for now.

azaozz23 months ago

comment:12 follow-up: azaozz23 months ago

20747.patch keeps all previously entered values in the "Display name publicly as" drop-down and doesn't reset when a name field is emptied.

azaozz23 months ago

comment:13 azaozz23 months ago

Actually we don't need to keep reference to the previously selected value as we only append new <option> tags to the select and don't need the HTML IDs on them.

Last edited 23 months ago by azaozz (previous) (diff)

comment:14 paul.payen23 months ago

Thanks a lot for the quick fix.
We will test your patch on our WordPress instance.
I will let you know asap.

comment:15 in reply to: ↑ 12 SergeyBiryukov23 months ago

  • Keywords has-patch added; needs-patch removed

Replying to azaozz:

20747.patch keeps all previously entered values in the "Display name publicly as" drop-down and doesn't reset when a name field is emptied.

This also fixes the Firefox-only issue from comment:2.

comment:16 azaozz23 months ago

  • Milestone changed from Awaiting Review to 3.4

comment:17 markjaquith23 months ago

Tested. Fixes the bug. Good for commit.

comment:18 nacin23 months ago

  • Keywords commit dev-reviewed added; ux-feedback removed

Good here too.

comment:19 azaozz23 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In [20964]:

Do not clear the old values in "Display name publicly as" drop-down on the user profile screen, append new values there when the user changes any of20747 the name fields, fixes #20747

Note: See TracTickets for help on using tickets.