[Touch-packages] [Bug 1586800] Re: Captive portal experience is bad
*** This bug is a duplicate of bug 914507 *** https://bugs.launchpad.net/bugs/914507 ** This bug has been marked a duplicate of bug 914507 Feature Request: special Browser window for logging in to WiFi Hotspots -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1586800 Title: Captive portal experience is bad Status in Canonical System Image: New Status in Ubuntu UX: New Status in network-manager package in Ubuntu: New Bug description: If you connect to a wifi AP that uses a captive portal (a login screen before granting full internet access, often seen in cafes and hotels) with your phone, the experience is quite lacking right now. - Webapps won't work. They try to connect to their site, are smart enough to know something is wrong when it doesn't get the right site back, and never finishes loading anything. - Apps in general fail to gracefully handle the case of getting back an unexpected result to their connections. - You may very reasonably auto connect to a wifi AP and not receive notifications for internet services like Telegram until you log in to the portal or turn off wifi. - If Browser is closed or OOM, when you open it, the last page you were at is overridden with the captive portal page. That's lost information! I hope you remember what it was. - If whatever page you try to go to first on the captive portal happens to be an https site, you will get an error instead of the portal. - If you know what to expect with the captive portal, you basically have to open a new browser tab and navigate to a site you have no intention of actually using just to get the log in page. It's a bit of a farce and not a great UX. - If you are *trying* to trigger the captive portal but the site you try happens to be cached (in some way? DNS or content caching or something), you will see that cached page instead of the portal. Which is unexpected for you. (I *think* this happens, maybe I am misremembering though.) And there are probably more pain points involved. This is just off the top of my head. Can we please guide the user through this experience instead of leaving them with a system that acts busted? Maybe prompt the user and open a page for them? Maybe keep using mobile data until the portal is past? Maybe don't tell apps that they are connected to the internet when they really aren't? Maybe have the Browser not overwrite the last open tab with a portal? To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1586800/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1586800] Re: Captive portal experience is bad
** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1586800 Title: Captive portal experience is bad Status in Canonical System Image: New Status in Ubuntu UX: New Status in network-manager package in Ubuntu: New Bug description: If you connect to a wifi AP that uses a captive portal (a login screen before granting full internet access, often seen in cafes and hotels) with your phone, the experience is quite lacking right now. - Webapps won't work. They try to connect to their site, are smart enough to know something is wrong when it doesn't get the right site back, and never finishes loading anything. - Apps in general fail to gracefully handle the case of getting back an unexpected result to their connections. - You may very reasonably auto connect to a wifi AP and not receive notifications for internet services like Telegram until you log in to the portal or turn off wifi. - If Browser is closed or OOM, when you open it, the last page you were at is overridden with the captive portal page. That's lost information! I hope you remember what it was. - If whatever page you try to go to first on the captive portal happens to be an https site, you will get an error instead of the portal. - If you know what to expect with the captive portal, you basically have to open a new browser tab and navigate to a site you have no intention of actually using just to get the log in page. It's a bit of a farce and not a great UX. - If you are *trying* to trigger the captive portal but the site you try happens to be cached (in some way? DNS or content caching or something), you will see that cached page instead of the portal. Which is unexpected for you. (I *think* this happens, maybe I am misremembering though.) And there are probably more pain points involved. This is just off the top of my head. Can we please guide the user through this experience instead of leaving them with a system that acts busted? Maybe prompt the user and open a page for them? Maybe keep using mobile data until the portal is past? Maybe don't tell apps that they are connected to the internet when they really aren't? Maybe have the Browser not overwrite the last open tab with a portal? To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1586800/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
