Item11371: Code that adds users to group is broken and adds dummy names based on few typed characters

Try and add a user to a group.

Type the first few characters and wait for the ajax to list the person you want.

Pick this person with the mouse and submit.

Result is that you get both the chosen person added AND a none existing person that is called the few characters that you typed in the field.

So you end up with a group containing nonsense. Unless you typed the entire name you ALWAYS get this bug when you add users so it is a nasty one.

-- KennethLavrsen - 18 Dec 2011

Michael, Arthur, this is something down in the autocomplete code carrying forward the typed characters. I can't quite recreate it - With the following steps

• User JoeUser exists
• type Jo
• pick JoeUser and then submit
• Dialog briefly fills back in with the Jo after submit
• Response reports "Successfully Added JoeUser, Jo to ...

However the actual group in my testing does not contain the "jo" - but in any event this is wrong. Is this an issue in the new Autocomplete code, or in the Group UI implementation of it.

-- GeorgeClark - 18 Dec 2011

I dug a bit - I assume the code that processes the"pick" of a user needs to clear the input field so that the stale input is not processed. - somewhere in pub/System/JQueryPlugin/plugins/textboxlist/jquery.textboxlist.js But not sure where that has to happen.

-- GeorgeClark - 19 Dec 2011

At first try I can't reproduce this reliably. Kenneth, which browser do you use? Any js errors being reported on the console? Are you performing these steps on the WikiGroups or on the MyTestGroup topic itself?

From what I see I can add a "Jo" to the list of users added when typing "Jo" in the input field and then hit return on the keyboard.

When selecting "JoeUser" from the suggestions the input field does get cleaned properly and is empty, i.e. there's no "Jo", "JoeUser" in the list.

For debugging purposes add debug to the JQREQUIRE in Main.GroupViewTemplate, making it a %JQREQUIRE{"textboxlist, debug"}%. Then reload the page, type "Jo", select "JoeUser" from the list of suggestions. Then save a copy of the debug output found in your browser's console (given you have firefox + firebug or Chrome).

Watch out when the extra "Jo" gets added to the input field.

... I can see now some "Jo" being added back to the input field again as a result of some hovering over the suggestion list. Not sure.

One good thing I found out is that the core seems to filter out and rejects to add any non-user string to be added to the group despite being reported so. So when I hit enter and try to add "Jo" to the group, it does not really add it to the group. It reports so but visiting the group topic and even inspecting the group with raw=all does not show any sign of "Jo". If that's so then this is still a somewhat uggly bug in the autocompletion code under certain circumstances, but the core effectively seems to protect dummy names to be saved to a group. Right?

Checked in a fix to close the suggestion list when hitting return: there definitely was some weird behavior when the list was still on the screen after hitting return + hovering over that list. It then added a gray placeholder-like leftover to the input box, that I have no clue where that comes from.

Please check.

-- MichaelDaum - 19 Dec 2011

I can easily reproduce this in different browsers. Even on my iPad.

I use ApacheLogin and not TemplateLogin. That may be important.

-- KennethLavrsen - 19 Dec 2011

Okay - we have a 2nd issue that actually is in 1.1.3 as well. You cannot add any user that is contained in an existing user as a prefix. So if the group contains JohnSmithson. You won't be able to add JohnSmith. That explains why I couldn't recreate the adding of the bad user when jquery doubles it up.

Unfortunately the original error is still not fixed with MichaelDaum's commits.

-- GeorgeClark - 19 Dec 2011

The key to reproduce is to write the first characters in lower case.

The JS finds the names with the ajax without being case sensitive. So adding SidSnot found after typing si adds both a bogus si and the correct SidSnot

-- KennethLavrsen - 19 Dec 2011

Or svn update to get the fix to Item11373 TopicUserMappingContrib that I just checked in. Then the spurious members will be created even when the case matches.

-- GeorgeClark - 19 Dec 2011

The grey text is because of the css class .foswikiInputFieldBeforeFocus { color: #797979;} applied to the field once focus moves away. So the typed characters are leftover in the textbox after autocomplete processes it. The jquery log doesn't show any messages after the entry is picked. Clicking Add clears the log, nothing related to the leftover characters is logged by jquery.

Inspecting the element in chrome, there are multiple input fields with the same name. One for each of the "selected" names, and the actual textbox.

   <input type="hidden" name="username" value="Blah5Group" title="Blah5Group">
   <input type="hidden" name="username" value="AnotherOne" title="AnotherOne">
and
   <input type="text" name="username" value="" size="30" class="foswikiInputField foswikiDefaultText jqTextboxList jqInitedTextboxList ui-autocomplete-input foswikiInputFieldBeforeFocus" autocomplete="off" role="textbox" aria-autocomplete="list" aria-haspopup="true">

The type="text" input field contains the leftover entered data. Is there some way to clear it when a name is selected. It has to be possible to process the manual input field or it would not be possible to add a user or group not known to the system. Another option - rather than processing the actual text field, would it be possible to list the typed characters verbatim as the first choice in the drop-down - so you could pick exactly what you typed without any further completion. Then change the type="text" field to have a different name, so it would not be processed by the addUser code. That would probably be clearer to the user than needing to click outside to dismiss the drop-down when adding an unknown user.

-- GeorgeClark - 20 Dec 2011

George, I think there are some misconceptions here. First: those multiple input fields are created as part of your user interaction. They all form the list of things selected. This includes those of type=hidden as well as the type=text. There's no extra provision needed to select the strings already in the input-type=text field as they are already there. The dropdown list is just there to select some other value to be put into it. When that happens a new input-type=hidden field is created thus extending the selection, and the input-type=text is cleared.

... me looking into the other issues reported above.

Here are the steps that exactly describe how to reproduce the error:

1. go to Main.AdminGroup
2. hit ctrl-r to refresh any possible browser cache
3. click on "Add members" -> twisty opens
4. click into the input field now became visible; don't move the mouse or click anywhere else. -> the input field gets a new css class foswikiInputFieldFocus and turns lightblue (pattern skin)
5. enter "a" and wait till the ajax call finishes and a suggestion list pops up -> it shows "AdminGroup", "AdminUser"
6. click on "AdminUser" -> "AdminUser" is added to the selection, "a" is cleared from the input field!!!
7. click the "Add members" -> "a" suddenly appears again the in input field and the next screen says: "a added to the AdminGroup group."

Note this does not happen with NatSkin.

The problem stems from foswikiForm.js processing the input field as well triggered by the foswikiDefaultText. This code manipulates the input-type=text element in addition to the textboxlist code...

Solution: remove the .foswikiDefaultText css class from the input field and try again.

Btw. don't add "AdminGroup" to the AdminGroup a you will otherwise DoS your foswiki server running into an infinite loop: Item11375

-- MichaelDaum - 20 Dec 2011

Commenting is disabled while not logged in