On Wed, 11 Jul 2018 11:04:29 +0100, Terry Coles wrote: > On Wednesday, 11 July 2018 10:20:49 BST Terry Coles wrote: > > All of the pages appear different in one other respect. Across > > the top of the Splash Page, there is a page Title that reads > > 'Sign in to network'. This appears at the top of all the pages. > > It's this hangover from the Sign In Page that makes me suspect > > that nodogsplash is serving the content. > This statement is actually a load of cobblers. I just used my Linux > Laptop and my son's Windows PC to connect to the WMT pretend AP and > that 'page Title' doesn't appear. On going back to the phones, > I've realised that this is nothing more than a banner inserted by > Android to allow users to decide whether to continue to use the > network or not (it has the three vertical dots to indicate that a > menu is available. So the content is presumably being served by > nginx but somehow Android 7.0's browser is messing with the > content, presumably due to something being done in the Splash Page. > > On the laptop and PC, I don't get the Alert that Android puts up and > which automatically routes the user to the Sign In page when > clicked. Instead, the machine simply connects to the AP in the > normal way and nothing happens until the user opens his browser. > This then puts up the Sign In Page and everything works fince from > then on.
I think you've hit the nail on the head there. Android seems to have a special browser that appears for signing in to captive portals, and it doesn't render web pages quite the same way as the usual browser. It makes sense that there should be a special browser, since users will not necessarily be using the main browser but might still expect internet access for other apps that won't show a captive portal log in page. Looking at the home page HTML and CSS, I think the most likely element to cause overflow off the screen is the image that says Wimborne Model Town Banner. The buttons have been given no specified width, so they should just get squashed to fit, but the image has an implicit width of 507px, with is inconveniently absolute. (And if the image pushes the page that wide, then the buttons might go off the screen too.) Now, I'm a bit rusty on this, but I believe that most mobile browsers, encountering this page, with no specified viewport size, would set the viewport (representing the visible portion of the page) to the width of the widest element (the image). The browser would then scale the viewport so that it fits on the screen (i.e. zoom out a bit to make everything fit). So, perhaps the captive portal sign-in browser does not support viewports in the same way that a normal mobile browser would. One option to fix this might be to specify the max-width (as opposed to the width) of the image to be 100%. Then it doesn't matter how big or small the viewport is. Another option might be to explicitly set the viewport to the width of the widest item on the page. This might be interesting from the point of view of seeing whether the captive portal sign-in browser actually supports viewports of this nature at all. I imagine this strategy is probably not considered best practice, since it's kind of a cheat to avoid having to fix the page to work with arbitrarily sized screens. -- Next meeting: Bournemouth, Tuesday, 2018-07-17 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
