Contact Selector - Form tab index is lost after selector resolves names on blur RRS feed

  • Question

  • I'm working with an InfoPath2007 form developed to be filled-out through the browser on a SharePoint 2007 site, and I'm testing using Internet Explorer 7.  It's a straight-forward form, with a number of text fields and two Contact Selector controls.

    The issue I'm encountering is with the Contact Selector control, where if the actor only enters a partial name into the text-field and then TABs away from the control the form will perform its auto-postback to look-up and resolve the partial name (showing the name resolution dialog is necessary), and afterward the actor's cursor is focused on the next field in the form.  The actor can type text into the focused field, but any subsequent pressing of the TAB key returns the actor's focus to the browser's ADDRESS bar, which is incorrect as it should proceed to the next field in the form.  I understand that the Contact Selector needs to perform its postback to perform the name resolution (so that there is no way through the InfoPath form designer to disable postbacks for the control), but why does the browser not know how to continue the TAB order of the fields on the form even when a field has focus?

    Wednesday, April 7, 2010 7:57 PM

All replies

  • Why?  I'm not sure, but it is the same behavior I've always had to endure.  The resolution of the user's identity is an intensive process.  I'm not sure knowing why would help - I haven't seen a workaround to overcome it.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Saturday, August 21, 2010 6:24 PM
  • We're seeing something similar in SharePoint 2010 InfoPath Forms - if you tab-out or resolve a user with  the people picker it returns you to the previous field.

    How do we solve this? This is a show-stopper for us.

    Wednesday, December 19, 2012 12:09 AM
  • I think I can reproduce this tabbing bug - I'll probably raise a MSDN bug:

    1. Create a custom list
    2. Create a people picker field (make it a required field)
    3. Create a text column (to demonstrate that you want to tab into this field


    1. Add a new item
    2. Enter Title, valid person (without resolving) then press tab, then enter Text
    3. Note that the person isn't auto-resolved and everything works OK when you hit OK
    4. Customise the form in InfoPath (don't make any changes)
    5. Publish the Form
    6. Add a new item
    7. Enter Title, valid person, then press tab - note that the People Picker auto-resolves the name and your tabbing order is lost.

    This is definitely a bug. Can we disable auto-resolution for required people picker fields?

    Wednesday, December 19, 2012 2:40 AM
  • I raised an MSDN bug, but haven't heard anything other than it's probably a bug they already know about.

    Our current fix is to make the people-picker field not required and create a hidden mandatory Single Line of Text and then use a rule to copy the People Picker value to the this field. This helps us enforce the mandatory field. We can then use a section with a red asterisk to "fake" the mandatory nature of the field.

    I've also posted about this issue here.

    Wednesday, February 20, 2013 11:57 PM
  • Please see my Stack Exchange post for an update. 

    It's a known internal MS bug that should be fixed in SharePoint 2013.

    Thursday, March 14, 2013 7:58 AM