Make WordPress Core

Opened 12 years ago

Closed 12 years ago

#20747 closed defect (bug) (fixed)

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

Reported by: paulpayen's profile paul.payen Owned by: azaozz's profile 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 12 years ago.
Defect Screen
initial_list.png (9.6 KB) - added by paul.payen 12 years ago.
This is the initial dropdown list.
final_list.png (7.0 KB) - added by paul.payen 12 years ago.
This is the final list
20747.patch (1.2 KB) - added by azaozz 12 years ago.
20747-2.patch (1.6 KB) - added by azaozz 12 years ago.

Download all attachments as: .zip

Change History (24)

@paul.payen
12 years ago

Defect Screen

#1 @nacin
12 years ago

  • Keywords reporter-feedback added

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

#2 @SergeyBiryukov
12 years 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 12 years ago by SergeyBiryukov (previous) (diff)

#3 follow-up: @paul.payen
12 years 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.payen
12 years ago

This is the initial dropdown list.

@paul.payen
12 years ago

This is the final list

#4 @SergeyBiryukov
12 years ago

  • Keywords needs-patch added; reporter-feedback removed

#5 in reply to: ↑ 3 @azaozz
12 years 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.

#6 follow-up: @nacin
12 years 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.

#7 in reply to: ↑ 6 @azaozz
12 years 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.

#8 @azaozz
12 years ago

  • Keywords ux-feedback added

#9 follow-up: @nacin
12 years 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.

#10 in reply to: ↑ 9 @azaozz
12 years 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).

#11 @azaozz
12 years ago

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

@azaozz
12 years ago

#12 follow-up: @azaozz
12 years 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.

@azaozz
12 years ago

#13 @azaozz
12 years 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 12 years ago by azaozz (previous) (diff)

#14 @paul.payen
12 years ago

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

#15 in reply to: ↑ 12 @SergeyBiryukov
12 years 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.

#16 @azaozz
12 years ago

  • Milestone changed from Awaiting Review to 3.4

#17 @markjaquith
12 years ago

Tested. Fixes the bug. Good for commit.

#18 @nacin
12 years ago

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

Good here too.

#19 @azaozz
12 years 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.