Region Dropdown doesn't appear when registration page loads and autofills country field

[yog-it]

Description

When the site is set to "Require a Valid Profile for Registration" on the registration settings tab and the Region and Country fields are set to "required" on the user profiles tab. The user can not register when the Country is auto-filled by the IP lookup mechanism because the Region dropdown never appears. This doesn't occur on the localhost.

Steps to reproduce

1. Install a new DNN site on a server or app service (this doesn't occur on localhost).
2. Set the Country and Region fields to required in the Site Settings > Site Behavior > User Profiles tab.
3. Turn on "Require a Valid Profile for Registration" on the Security > Members Accounts > Registration Settings tab.
4. Logout and attempt to register.

Current result

Using a PC on a US IP address (only country IP I've tested), the user can't register because the State/Region field never fills with a dropdown when United State is auto entered by the IP lookup. The region field will continue to blank out every time the form is submitted.

Expected result

The dropdown for the region appears, is populated and the user can submit the form.

Affected version

• [x] 9.2
• [x] 9.1.1
• [x] 9.1
• [x] 9.0 all 8 versions Does not effect upgraded sites from earlier versions if the Country field remains DataType of DotNetNuke.UI.WebControls.DNNCountryEditControl instead of DotNetNuke.UI.WebControls.DnnCountryAutocompleteControl from a new installation.

Affected browser

• [ x ] Chrome
• [ x ] Firefox
• [ x ] Safari
• [ x ] Internet Explorer
• [ x ] Edge

[RFHavens]

This is one of our biggest issues as we are a membership based use case for our club. I get nothing but complaints for this issue. Even clearly writing instructions to "make it work" most do not read the instructions I have put up. This should be a top issue that should be able to be fixed in a timely manner. Of course a custom solution could be built but that would also require the developer to maintain it thru future updates to the core DNN code.

[valadas]

This should be fixed in 9.3.0, basically two issues where fixed.

1. Some browsers autocomplete hid the built-in drop-down this not firing up the selection.
2. For the region list to populate, it needs to know the country first. On new installations the order is country then region. But to not disturb existing sites, if you upgrade then you should only need to move the country before the region.

If I remember correctly, the is also still an open issue about that order not getting applied everywhere, that I hope to get to for 9.3.1 or 9.3.2

[yog-it]

The order doesn't seem to be the issue. Following the steps above (even on the 9.3.1 RC) it still causes the same issue. The country field is already filled in, but the dropdown for the region does not appear, so even when tabbing from field to field, it doesn't initialize the dropdown. The only thing I could do to get it to bring up the dropdown of regions was to actually remove the "s" from then end United States and type it back in, then it shows the selection box for countries and initializes the dropdown. I thought the country field might be filled by the browser's form autocomplete, but it happens on every browser even in private mode. This does not happen when I'm running the site from localhost.

Once the "s" from United States is removed and typed back in the Country is properly selected:

Then the region dropdown appears:

[ChrisHammond]

I've been testing something related to this today. If you have "require valid profile for login" and require country/region, it doesn't appear that DNN is loading the proper javascript libraries for the auto-complete to work.

I'm going to try to recreate on a clean DNN install before I dive into my particular customer's issue. Hopefully I can get testing it tonight.

[ChrisHammond]

So my testing in 9.3.2 found that if you create a custom login page, put the login module on that page, and have Valid Profile Required for Login selected, that the auto-complete functionality doesn't work on the Country selection page.

Steps to recreate

1. Create new 9.3.2 Install
2. Login as host
3. Navigate to Site Settings, change user profiles options to require the Country and Region fields on a profile.
4. Navigate to the Security page, login settings tab. Check the Require a valid Profile for login
5. Create a new page called Test Login
6. Place the Account Login module on the page
7. Navigate to Site Settings and configure the Login page to use the Test Login page
8. Create test user (using the host/superuser account)
9. Open new incognito browser, navigate to the site
10. Click Login page, Login
11. Try to type United States in the Country field, the autocomplete won't fire.

I'm trying to determine what isn't loading and why to see if I can come up with a fix for this scenario

[ChrisHammond]

Tested this in 9.4 tonight (site was upgraded from 9.3.2 to 9.4) and the issue still remains

[valadas]

This may be related to #2947 #3003

[valadas]

Oh, re-reading this, maybe not

[ajwaka]

Just coming across this issue now, we've often used other modules for registration. But now one has a bug, so I'm looking at Core registration as it's come a long ways over the years.

1. It's "now" (I noticed) a textfield and not a dropdown.
2. As stated by @RFHavens the autocomplete shows up behind most browser auto-completes. Mine too as it was completely hidden.
3. Region is now busted - the reason for this entry.

I'd like to help if I can, but first would like to know (if you can link me to various discussions)

1. Why is this a textfield instead of select list
2. Why choose an implementations who's autocomplete is hidden by most browser's helpful implementations
3. Is there any reason we can't go back to a select list for country?

[valadas]

Hmm, I was sure that was fixed, apparently not.

-The spec does say it should be autocomplete="off" to prevent auto-fill. Chrome (and maybe others) have a bug that ignores that.

-One workaround is to use some other string that is not valid in the specs such as autocomplete="false" which works good in some browsers but others just work once, it then remembers whatever you stored there on second use (like site admins doing it multiple times for many users).

-Another workaround is to generate a random string for the autocomplete value so that way even for the browsers that do store it, the next time you get another value so it does not fetch the stored one (I was sure this was implemented here in 9.3.0 but apparently not).

-And yet another workaround is to use autocomplete="new-password", which does work on all browsers but may mess up with password managers maybe and looks semantically wrong too.

[valadas]

The fix for this should be something similar to https://github.com/dnnsoftware/Dnn.Platform/pull/2237/files on the Profile.ascx but in https://github.com/dnnsoftware/Dnn.Platform/blob/develop/DNN%20Platform/Website/DesktopModules/Admin/Security/Register.ascx file

[scottri]

I am upgrading to 9.8.1 from 6.x for a website that only applies to users in the United States, and my wish is to require a Region field and not a Country and default the user Country value to "United States". My testing with code suggests the following issues:

Issue (1): When I only required Region and not Country for registration, the Region field does not have a dropdown and submitting a text value of say "Texas", the form fails with "State/Region is required" even with a value. Issue (2): If I require Region and Country for registration, (a) the Country control defaults to "Not Specified" regardless of the default value in Site Settings, or my IP address, and (b) when I select "United States", no dropdown appears in the Region control.

Investigation: For (1) I have not investigated the cause of yet.

For (2b), my debugging suggests that OnItemChanged() in \DNN Platform\DotNetNuke.Web\UI\WebControls\DnnFormEditControlItem.cs is failing to find the "Region" control, i.e. the following always returns null: var regionContainer = ControlUtilities.FindControl(this.Parent, "Region", true);

I am not familiar with how this works but when I added a line to set the value for my specific registration configuration it worked. regionContainer = this.Parent.Parent.Controls[5];

I could not figure out how to change the FindControl call to get it to work. Looking in the debugger, id property for the "Region" control is something like "7e68faa99a598b92a30cd2cf7098b94d", so I do not know if that is part of the issue.

For (2a) on initialization of the country control using CreateControlInternal() in DnnFormEditControlItem.cs, the binding value from the new user profile is the country name, i.e. "United States" based on my IP address, and I believe the control expects the country code, i.e. "221" to work properly. The result is that the default country for the user ends up being "Not Specified". If I set the value to "221" while debugging, the country control displays "United States" as desired. The binding for the control obtains the value from the default new user and this value based on the IP address of the user is the country name, not the country code, so I believe that the code should be returned.

Issue (3): When the country control defaults to 221, i.e. "United States" using (2a) workaround, the Region control dropdown does not appear initially, specifically, OnItemChanged() in \DNN Platform\Library\UI\WebControls\PropertyEditor\Edit Controls\DNN Edit Controls\DNNCountryEditControl.cs is not called right after creating the form but is first fired when the user changes the value in the country control. The code should be updated to trigger OnItemChanged when the form is displayed.

Issue (4): My opinion is that if the Country property in the UserProfile table is set, i.e. 221, and the profile does not require Country for registration, the value for the new user should default to that value and not based on IP address. If users are associated with a specific country, the Region control can display a dropdown for registration w/o showing the Country control.

My Workaround: So for the current state of the code, I can work around all this by:

• Hard code LookupCountry() in \DNN Platform\Library\Entities\Modules\UserModuleBase.cs to always return 221 for United States
• Set default value for Country profile property to 221, just in case
• Added code to DnnRegionControl_Init() in DNN Platform\Library\UI\WebControls\PropertyEditor\Edit Controls\DNN Edit Controls\DNNRegionEditControl.cs to add "Country.US" attribute to itself; taken from OnItemChanged() in \DNN Edit Controls\DNNCountryEditControl.cs.
• Update Profile to required only Region value, not Country since it will be forced to be 221. Above not ideal, but works for now.

[johnhenley]

I have never been able to get this working correctly. Even this latest fix #5501 doesn't solve it for me. In my experience the majority of the IP addresses country lookups end up filling the country with N/A, which causes even more grief since users have to know to clear it out, and it's not intuitive. My "workaround" is to add an entry to the Lists table for Country with a fake row for N/A (Value of N/A and Text that is blank). That at least doesn't fill the country with N/A and users don't get N/A as their country.

[valadas]

reopening to test more

[johnhenley]

I think there should be a portal setting in user profile settings to disable the geoip logic for guessing the country. I tested a bunch of ip addresses and only one (the public one for my site itself) returned a country. Also, the code that detects localhost doesn't understand ipv6 addresses.

[rodrigoratan]

@johnhenley could you share some screenshots to help me understand the issue better? or perhaps you could join us on the Saturday's Open[Source] Coding Sessions we have on Discord? I would like to help on this again

I have never been able to get this working correctly. Even this latest fix #5501 doesn't solve it for me