Hiding the address bar in Mobile Safari

[Ellsass]

First, I know that Matteo has said he will post an example of this,
but I understand he's busy and this seems to be a trivial issue for
most people, so I was hoping someone could post their fix.

This always works, but it is not programmatic: When the page is
loading and you can see some content, but before the page finishes
loading, scroll down with your finger (drag your finger up). Obviously
not a great solution, but it provides some insight into how Safari
decides to hide/show the bar -- I tried to simulate this in #4 below.

I've tried these methods, and none of them work:

1.
window.scroll(0,1) on load
result: no effect

2. window.scrollTo(0,1) on load
result: no effect

3. the above commands, just before initializing var x = new iScroll
result: no effect

4. window.scroll(0,100) with an inline script tag at the bottom of my
content, before the footer div -- this is my attempt to simulate the
non-programmatic solution above, since that's essentially what I'm
doing with my finger.
result: no effect

5. Adding a large (200px tall, full width) dummy div at the bottom,
and...
5.1 doing nothing else
result: no effect
5.2 adding or subtracting its height in setHeight: wrapperH =
window.innerHeight - headerH - footerH + dummyFooterH
result: pushes footer up or down by that amount, does not affect
address bar

6. adding or subtracting an arbitrary amount from setHeight: wrapperH
= window.innerHeight - headerH - footerH + 50
result: shifts the footer up or down so that it's not aligned with the
bottom of the window, but does not affect the address bar


Any other suggestions?

[Ray]

You can make full screen webpage. Details are here:

http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html#//apple_ref/doc/uid/TP40002051-CH3

and here:

http://mobile.tutsplus.com/tutorials/iphone/iphone-web-app-meta-tags/

Once you add the meta tags to you webpage, the use will have to view
then page and then select "add to home screen". That will add a new
icon to the home screen. Then the webapp is started from this icon the
safari address bar will not be shown. This works on both iPhones and
iPads.

[Ellsass]

That's not exactly what I'm looking for. (Actually, I'd love to use
that, but I *hate* that Safari reloads the page every single time you
launch the 'app', even if you just switch back to it via the multitask
dock. It's also not very useful if your site launches many external
links, which mine does.)

I don't mind the bookmark/navigation bar at the bottom. Basically,
right now Safari looks like this:
http://artoftheiphone.com/wp-content/uploads/2008/11/mobile-safari-update-in-22.jpg
(ignore the red circle, this is just a random image I found)
But I want it to look like this: http://www.blog-ppc.com/images/blog-ppc.com/opera2.jpg
(same thing, but with no address bar)

On Oct 31, 3:59 pm, Ray <raykrei...@gmail.com> wrote:
> You can make full screen webpage. Details are here:
>

> http://developer.apple.com/library/safari/#documentation/AppleApplica...

[DataZombies]

So, basically, you want the app to save it's state when you leave it.

If that's correct then just write some JavaScript to save which page
the user is on so that if they exit and go back to the app they start
where they left off.

That's a hellofalot easier than tyring to hide the address bar.

On Nov 1, 8:39 pm, Ellsass <cpa...@gmail.com> wrote:
> That's not exactly what I'm looking for. (Actually, I'd love to use
> that, but I *hate* that Safari reloads the page every single time you
> launch the 'app', even if you just switch back to it via the multitask
> dock. It's also not very useful if your site launches many external
> links, which mine does.)
>
> I don't mind the bookmark/navigation bar at the bottom. Basically,

> right now Safari looks like this:http://artoftheiphone.com/wp-content/uploads/2008/11/mobile-safari-up...

[Ellsass]

No, that's a different issue entirely. And on that issue, my problem
isn't that the user loses his place, it's that he has to wait for all
of the HTML/CSS/JS to re-download and re-render each time he opens the
'app' version of the page. I know I could offload a lot of this to
HTML5 localstorage, but again, this isn't what I'm after.

Open any page with enough content in Mobile Safari -- www.nytimes.com,
www.google.com, www.cnn.com. On all of them, as soon as the page
loads, the address bar slides up out of view, giving the page more
vertical space to work with (but leaving behind the bookmark and back
button bar at the bottom of the window).

[JeromeM]

mmh don't know if you had my message but here's how i do :

Metas :
<meta name="viewport" content="width=device-width; initial-scale=1.0;
maximum-scale=1.0; minimum-scale=1.0; user-scalable=0;" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />

Header :
<script>
window.scrollTo(0, 0) ;
</script>

Footer :
<script>
var scroll = window.setInterval(function() { window.scrollTo(0,
1) ; }, 2000) ;
</script>


Regards

On 2 nov, 12:29, Ellsass <cpa...@gmail.com> wrote:
> No, that's a different issue entirely. And on that issue, my problem
> isn't that the user loses his place, it's that he has to wait for all
> of the HTML/CSS/JS to re-download and re-render each time he opens the
> 'app' version of the page. I know I could offload a lot of this to
> HTML5 localstorage, but again, this isn't what I'm after.
>

> Open any page with enough content in Mobile Safari --www.nytimes.com,www.google.com,www.cnn.com. On all of them, as soon as the page

[Ellsass]

Thank you JeromeM, that works very well! I believe the setInterval()
piece was what I was missing.

[Ellsass]

Jerome's implementation brings up a point about UX that may interest
some of you. Across nearly all iPhone apps, a user can tap on the
clock at any time to scroll to the top of the current page or list (in
Safari, it scrolls up AND displays the address bar). You probably
don't want to break this expected behavior. In particular it's very
common to use this method in Safari to enter a new URL or to use the
search box.

Assigned setInterval a time of 2 seconds means that every two seconds,
the address bar will slide out of view. IMO, this isn't a user-
friendly amount of time to retain the tap-the-clock feature in Safari.
I've upped it to 5 seconds in my code.

I can think of two use cases for a user tapping on the clock: 1) they
want to enter a URL or search, and 2) it was an accident (or they
changed their mind and want to stay on your page).

Case 1:
Tapping the clock gives the user a few seconds* to then tap either the
URL input or the search input. Once either of these has focus, the
setInterval is effectively 'paused' -- the address bar will remain in
view until the user taps back on the web page. At that point,
setInterval is 'unpaused', and after a few seconds the address bar
will disappear and the web page will resume being "full screen".

Case 2:
If the user taps the clock and then does NOT tap either the URL input
or search box, the address bar will quietly slip away after a few
seconds. This is useful for maintaining the "full screen" look when
accidental or unwanted taps on the clock occur.

I think an interval of 5 or 6 seconds is the best way to accommodate
both use cases. Thoughts?

* When I say "a few seconds", it could really be anywhere from 0-5
seconds, with an average of (obviously) 2.5 seconds. In some cases
this will be too short (appearing to respond hostily to the user's
action) or too long (appearing to be unresponsive or broken). However
I think it's a decent compromise, especially if you expect users to
use your app more than once (in which case they'll understand from
past experience that they just need to try again or wait).

Obviously the ideal solution to all of this would be the pseudo-code
below, but if it were possible then this thread wouldn't exist :)

setInterval(checkAddressBarVisibility,500);
function checkAddressBarVisibility()
{
if (address bar is open) {
setTimeout(closeAddressBar,1500);
// Remember that this would only run if neither the URL input nor
search box had focus
// i.e., it would only run when the user was not interested in using
the address bar

[JeromeM]

I think it's possible ..

If you check the window.innerHeight property you can know if the
address bar is shown or not.

Some pseudo-code too (non-tested, and wrote in 5 minutes at work ...
^^)

var addressTest = null,
timer = null,
hideBar = null,
maxHeight = 0,
runtime = 300 ;

addressTest = window.setInterval(function() {

// Portrait
if ((window.orientation % 180) == 0) {
maxHeight = 356 ; // Values may not be that, don't remember well ...
}
// Lanscape
else {
maxHeight = 208 ;
}
if (window.innerHeight == maxHeight) {
if (hideBar) { window.clearInterval(hideBar) ; }
timer = window.setTimeout(function() { window.scrollTo(0, 0) ; },
5000) ;
} else {
hideBar = window.setInterval(function() { window.scrollTo(0, 0) ; },
1000) ;
}
}, runtime) ;

// Suppose your main wrapper have id "#wrapper"
with(document.querySelector('#wrapper')) {
addEventListener('touchstart', function() { touchStart() ; },
false) ;
addEventListener('touchend', function() { touchEnd() ; }, false) ;
}

function touchStart(e) {
e.preventDefault() ;
}

function touchEnd(e) {
e.preventDefault() ;
window.clearTimeout(timer) ;
hideBar = window.setInterval(function() { window.scrollTo(0, 0) ; },
1000) ;
}


If you want to test.. ;)

Regards

[Matteo]

Checking for the innerHeight is a clever solution. I would not check
on maxHeight, though (you know hardcoded values are always difficult
to maintain across devices/OSes). A better solution might be to check
just for height changes.

Eg:
Window Load > 100ms > scrollTo(0,0) > 500ms > activeHeight =
innerHeight > interval to check activeHeight against innerHeight
(every 2-5 seconds).

Matteo

[mi...@integroproperties.com]

Does this work in iscroll-4 or should I use the older version. I cannot seem to get the address bar to go away once I initialize iscroll. Is this a height issue?

[jtmkr...@gmail.com]

I can't get JeromeM's solution to work on iscroll4 either.

[Hampus]

I have the same problem, none of the provided solutions works on iscroll 4.

Has anyone find a solution to this yet?

[the....@gmail.com]

I have the exact same problem.  If anyone has a solution, please try to post it.  thanks.

[Matteo Spinelli]

take the "simple" demo.

Modify the following CSS properties:

#wrapper {

position:absolute; z-index:1;

top:45px; bottom:-11px; left:0;

width:100%;

background:#aaa;

overflow:auto;

}

#footer {

position:absolute; z-index:2;

bottom:-60px; left:0;

width:100%;

height:48px;

background-image:-webkit-gradient(linear, 0 0, 0 100%, color-stop(0, #999), color-stop(0.02, #666), color-stop(1, #222));;

padding:0;

border-top:1px solid #444;

}

Now in the loaded() function add:

setTimeout(function () {

window.scrollTo(0,1);

}, 100);

This is just a (admittedly lame) solution, but it works. The url bar hiding has nothing to share with iscroll. The bottom line is that the page must be taller than the visible area.

Matteo

[the....@gmail.com]

Thanks Matteo.  It works!

[Mark]

But not on the iPad right? Unless perhaps you make it a launchable (from desktop) page?

Cheers

Mark

On 22 April 2011 01:01, <the....@gmail.com> wrote:

Thanks Matteo.  It works!

[Gerry Straathof]

the address bar on the ipad incorporates the lower bar elements on the iphone. because of that you cannot hide it.

and really, you want to hide it to free up real estate, which is not as big a deal on the ipad. On the iphone that real estate is a precious commodity.

[emad...@googlemail.com]

As Moboa wrote, it works perfectly unless you create a homescreen icon to launch the site.

I've had this idea: Add2Home script detects if there is a homescreen launcher in order to prevent the popup to appear;

now if we add that script to the the "simple demo" that Matteo included in his post, could we prevent the resizing of the

screen when the script detects a homescreen laucher?

I also would like know if it's possible to hide the lower bar in landscape mode.

I have managed to hide the text in landscape mode (or in portait) by using the following js and I was wondering

if there is a way to make it interact with the iScroll lower bar too:

(btw, Matteo you did a wonderful job -thank you!)

<script type="application/x-javascript">

	window.addEventListener('load', setOrientation, false); 
    window.addEventListener('orientationchange', setOrientation, false);
    function setOrientation() { 
    var orient = Math.abs(window.orientation) === 90 ? 'landscape' : 'portrait'; 
    var cl = document.body.className; 
    cl = cl.replace(/portrait|landscape/, orient); 
    document.body.className = cl; 
    }

 </script>

[Valentine Marchetti]

This ONLY works in the lite version. As soon as I swap to the non -lite version it snaps the address bar back down immediately. I can put a js alert right after the window.scrollTo(0,1); and it will show correctly while the alert is up. Once I press "ok" it snaps back. I want to use iScroll with the "ios perfect scrollbar" demo. I still haven't found a solution for it yet or been able to work out one for myself. Help? :)

[Valentine Marchetti]

To follow up on this. What was needed was a longer delay for setTimeout(). Not sure why, but now it's working even with iScroll and the "ios perfect scrollbar" demo. 

[Paul van der Meer]

Hi Matteo,

Works great thanks.... But when I add it to my iphone homescreen and restart my webapp the footer disappears...

..en what about android devices.

Thanks!

Paul

[cortex]

Try implementing something like this for home screen launched

       if (window.navigator.standalone == true) {

              //alert('homescreen');

              $('body > #footer').css({bottom: '0px !important'});

            }

fyi window.navigator.standalone wil equal false if in safari

hope it helps

[Tosh Koevoets]

Hi Mateo,

Thanks, this works great! I've summed up the whole address bar issue in a blog post, for those who are interested you can read it here:

http://appyourbrain.com/fullscreen-webapps-and-the-address-bar-issue/

Op donderdag 4 november 2010 09:17:25 UTC+1 schreef Matteo Spinelli het volgende: