#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
Priority: normal Milestone: 3.4
Component: UI Version: 3.3
Severity: normal Keywords: has-patch commit dev-reviewed
Cc: Vincent.MORAINVILLE@…, nicolas.batteur@…

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

Download all attachments as: .zip

Change History (24)

Defect Screen

  • Keywords reporter-feedback added

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

  • 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 months ago by SergeyBiryukov (previous) (diff)

comment:3 follow-up: ↓ 5   paul.payen12 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 ?

This is the initial dropdown list.

This is the final list

  • Keywords needs-patch added; reporter-feedback removed

comment:5 in reply to: ↑ 3   azaozz12 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: ↓ 7   nacin12 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   azaozz12 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.

  • Keywords ux-feedback added

comment:9 follow-up: ↓ 10   nacin12 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   azaozz12 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).

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

comment:12 follow-up: ↓ 15   azaozz12 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.

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 months ago by azaozz (previous) (diff)

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

  • Milestone changed from Awaiting Review to 3.4

Tested. Fixes the bug. Good for commit.

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

Good here too.

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