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

Reply via email to