WiFiManager drops consecutive spaces in SSID via configportal.

[stevemisel]

Basic Infos

Hardware

WiFimanager Branch/Release: Master

Esp8266/Esp32: ESP32

Hardware: ESP-12e

Core Version: 2.4.0, staging

Description

WiFiManager drops spaces in SSID names; cannot connect to SSID with two spaces in the name. In this test case, I changed the SSID on a test router to "Lots of Spaces" [note double space, appears to be a single space here in github renders too!]. When running configportal, the SSID scan returns the proper name [see debug], but the additional space is missing ("Lots of Spaces") when viewing and selecting the SSID in the configportal UI.

Due to the SSID mismatch, WL_NO_SSID_AVAIL.

Adding the missing space manually in configportal resolves this. I have not debugged, but this smells like an HTML rendering issue.

Settings in IDE

Module: ESP32e

Additional libraries:

Sketch

#BEGIN
#include <WiFiManager.h>

void setup() {
  WiFi.mode(WIFI_STA);
  Serial.begin(115200);
  WiFiManager wm;
  wm.setConnectTimeout(10);
  wm.setDebugOutput(true);
  wm.autoConnect();
}

void loop() {
}
#END

Debug Messages

09:00:25.892 -> *wm:[2] AP:  -51 Lots of  Spaces

09:01:58.146 -> *wm:[2] <- HTTP WiFi save  
09:01:58.229 -> *wm:[2] processing save 
09:02:00.175 -> *wm:[2] Connecting as wifi client... 
09:02:00.175 -> *wm:[2] setSTAConfig static ip not set, skipping 
09:02:00.175 -> *wm:[1] Connecting to NEW AP: Lots of Spaces
09:02:00.247 -> *wm:[1] connectTimeout not set, ESP waitForConnectResult... 
09:02:05.551 -> *wm:[2] Connection result: WL_NO_SSID_AVAIL
09:02:05.551 -> *wm:[0] [ERROR] Connect to new AP Failed 
09:02:05.551 -> *wm:[2] Processing - Disabling STA 
09:02:05.585 -> *wm:[2] NUM CLIENTS:  1
09:02:05.585 -> *wm:[2] [EVENT] WIFI_REASON:  201
09:02:05.585 -> *wm:[2] [EVENT] WIFI_REASON: NO_AP_FOUND 
09:02:05.585 -> *wm:[2] <- Request redirected to captive portal 

[tablatronix]

• test lots of spaces

[tablatronix]

Ok so there are 2 ways to do this

I can either add some kind of decode on submit..
or
just not use html content as the parameter.

Right now we use js to copy the innerhtml into the form from the link

I think option 2 is the best as it will help avoid future issues as the ssid will be an escaped attribute and not html in the dom.

So I have added to the hrefs a data-ssid attribute and change the js to look for that first.
I added a new template var to account for this {V}

I was worried about this in the past and added an alternate ID parameter which is the wifiscan ID, but since I added async scanning I decided that data could change or if submitting an old session it would be bad if they were not synced up.

Also now using a data-attrib we can possibly change it to add bssid and other bits to encode base64 data etc..

I do not forsee any issues with this, let me know if anyone thinks of anything, if someone has custom html it should still fallback, I have not tested that though..