I've observed this on iOS 4.3 to 5.0. When you create a even a simple offline web app, meaning one HTML file + few assets such as CSS and JS (all present in the cache manifest), it works offline (I tested in Airplane Mode) – BUT, when you add such an app to your home screen and open it in fullscreen mode, it first displays initial content, then everything disappears (page becomes white) for half a second or more, then content reappears again.
You can see this by adding Glyphboard, a well-known and useful offline web app, to your iOS home screen and launching it a few times. You should see the white flash effect every time you load it.
This is a big problem because it gives away the non-nativeness of an app and gives the impression that the app is non-optimized for performance and buggy.
I've tried finding reports about this but all I can find is rumors and misconceptions about the iOS 4.3 JavaScript rendering engine fiasco, which doesn't need at all be related to this issue. But in iOS version 3 I distincly remember not ever seeing the white flash.
Clearing the screen and other artifacts while rendering is a common issue of HTML rendering due to the progressive nature of HTML. The concept is that the browser should draw as early and often as possible and render styles/scripts/content as they become available. It's possible the markup has an issue where all rendering is delayed until some content or a script is available. This could happen if:
You have dynamic heights based on image dimensions but you haven't
set the image dimensions in the markup or CSS.
Your layout is based on tables and you aren't using 'table-layout:fixed` in CSS.
Your HTML uses inline scripts with document.write().
You have some kind of onLoad() function that reveals/modifies content.
You link to an external stylesheet.
You're using uncacheable external content or you've disabled caching.
You're using external content that's returning 404 or isn't available offline.
Has your HTML/CSS changed between testing IOS versions?
I've found this to be caused by the use of:
<meta name="viewport" content="width=device-width initial-scale=1.0 maximum-scale=1.0 user-scalable=0">
With a minimal page, I get a white flash between the apple-touch-startup-image and the page contents if I use the viewport meta tag. If I take out the tag, no flash.
It's possible to work around the problem by setting the tag programatically.
I think what happens here is that iOS takes a screenshot from the page when it is added to the main menu. Then this screenshot is displayed during the application loads (WebKit loads). WebKit starts rendering the page and the page itself is constructed in such a way that the page content is not instantly available, leading to a white flash which is a rendered page when page content is not yet there,
You can avoid the problem to a certain level by building your JS/CSS so that it loads the initial HTML view fast and then lazily loads / builds the rest of the resources on the background. Also you can set a custom loading screen instead of the default screenshot iOS uses from the page.
Maybe if you can take yourself a screenshot of your app and then have something like this:
<body style="background: white url('my-initial-loading-screen.png')" />
... and make sure image is available and comes from manifest.
Or even better, have loading screen which does not require any external resources to show (just plain HTML) so you know the browser doesn't need to load anything.
Related
My responsive web app (made with Angular Material) works fine except with input fields on iOS / Safari: when the user focuses on an input field, iOS zooms the web page. Then the zoom level remains, breaking the responsiveness of the app (because then, the viewport becomes scrollable, and for instance the toolbar is no longer sticked to the top. Also, some elements supposed to be always visible on the left and on the right, are outside of the visible area due to the zoom).
I have followed recommendations given here and there, for instance https://www.warrenchandler.com/2019/04/02/stop-iphones-from-zooming-in-on-form-fields/ and iOS Safari zoom on input box.
An almost working approach consists to use the following in the HTML header:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0,user-scalable=0"/>
However this is not good enough in my case:
setting user-scalable=0 prevents the user to zoom the view
setting maximum-scale=1 also prevents the user to zoom on Chrome/Android (even if user-scalable=yes)
the trick with the "load" event (given in the 2nd link) does not work (I suspect because this is not called when changing page in a single-page application like Angular)
the trick using font-size=16px does not work for me (like many people also report).
Would anyone have a suggestion, to:
either prevent the focus on an input field to cause a zoom
or resetting the zoom to 1 after this operation
while letting users zoom the view manually if they wish to
?
Are any of your font sizes smaller than 16px?
You might be experiencing a browser behavior that isn't related to Angular Material.
My team experienced a similar problem. We found your question as part of our work. We eventually realized that the viewport zooming behavior that we saw had nothing to do with Angular Material. That's simply what iOS does when the font on an input field is less than 16px: https://css-tricks.com/16px-or-larger-text-prevents-ios-form-zoom/ Any input field. Angular Material has nothing to do with it.
Related: Please note that disabling viewport zoom for mobile was standard practice for about a decade after the introduction of the iPhone, but it is no longer The Way. https://webkit.org/blog/7367/new-interaction-behaviors-in-ios-10/
Iframe automatically goes full screen using Ionic 3.9.2 on iOS.
I've tried removing all the fullscreen tags. I notice that it is not happening anywhere else. Only happens on iOS. On other devices, I have to manually make it full screen.
Why does Iframe automatically go full screen on iOS?
<iframe src="https://d1mlukbqb3dh9w.cloudfront.net/PortraitCourse/Module01/Module01Section1/story.html" height="655" width="100%"></iframe>
A while ago I would have been able to provide you with a spot-on answer. Unfortunately I no longer have access to the resources I would need to do so... meaning my answer won't be a complete solution.
IFRAME, on iOS, works slightly differently than on Android. Getting an IFRAME to take only the height you want is not simply a matter of setting the HEIGHT property on the tag as the rendering engine works differently. You'll have to play around with CSS both in the container of the tag and in the contents of the body itself.
Try proceeding as follows:
prepare a mock target page that doesn't take all the height, make
its background red and see how much space it takes
make the mock page longer than the height of the screen by adding lots of text and images to it and observe the change
wrap the IFRAME in a DIV and set the style=height: xxx of the div, as well as its overflow.
wrap the contents of the mock page in a div, setting its height, overflow, position and display style
properties to control its appearance.
repeat step (4) with both the HTML and BODY tags of the mock page.
Playing with these in real-time using Safari to alter their values will prove most useful. It was to me at least, when I had the problem over an year ago.
UIWebView successfully loaded content, but is not displaying it. UIWebView is just white screen. BUT, if you click on this UIWebView it will process your click. For example, if you click at place where the link should be (but in fact the white space), the click processed and next page loaded and displayed OK.
The bug is unstable. I got it only with local HTML file (our homepage, it generated locally), web content loads OK. It happens in 20% cases. But in the same time, it is very sticky. Once got white screen, you can reload this page many times and see white screen (but if you click on invisible link, another page displayed successfully). Sometimes it occasionally appears without any reason. Your can "scroll" this blank screen up and down and it occasionally loaded. This local HTML has a lot of stuff, embedded images, javascripts, etc, and it could be javascript problem, but I can't explain how it can be, that content invisible, but still clickable.
It happens in iPod real device and iPhone simulator 4.3, but can't reproduce it on iPad or iPad simulator.
I spent a whole day trying resolve this. Any ideas?
I solved this!
This really weird behaviour of UIWebView was caused by javascript code. The javascript was like (simplified):
<script>
function onLoad() {
location.href='xxx://pageLoaded';
}
</script>
<body onload='onLoad();'>
The idea of this code was to inform app about the fact that page was loaded. In the app I catch request to xxx://pageLoaded and cancel it (in shouldStartLoadWithRequest). Because request cancellation, I didn't expect any problems here. Espesially, I didn't expect that content will become invisible, but still clicable. I added timer (setTimeout) between onload fires and location.href change. It solves the problem.
NOTE: I know about webViewDidFinishLoad event in UIWebView. This is very simplified example just to explain the problem and the solution. Real javascript is more sophisticated and what it is doing can't be reached by simple use webViewDidFinishLoad.
I'm writing a web app for the iPad using HTML5 and SenchaTouch. The app uses cache manifest to function offline. Once it has been added in the home screen and opened without Safari, it will refresh itself every time it is opened, even if just navigating to the home screen and back. The desired behavior is to leave the app, do something else, and then come back to the app with everything untouched.
An example of a similar app that displays the same (undesired) behavior can be found here: http://ignitedmediadesign.com/WebApp/index.html
I've read that using a cache manifest should have solved this problem on iPhone ( http://www.stevesouders.com/blog/2011/06/28/lack-of-caching-for-iphone-home-screen-apps/ ), but doesn't seem to have done the trick for either iPhone or iPad.
Is there another way to fix this? Is there some secret to cache manifest files that stops this that I may have missed?
I'm under the impression this is simply the nature of the "home screen" web apps that operate outside of normal Safari. I have an app that operates just fine in Safari with some minimal state saving, but the blasted non-Safari version refreshes every time. EDIT: Even the showcased O’Reilly example that uses a cache manifest reloads every time when added to the home screen.
You may want to look into creating "routes" (URL fragments) that point to a controller/action pair. Look into the MVC PhoneGap example (If not using PhoneGap, you can scroll past all of that stuff and implement your own data model and store). Also see this Sencha Touch MVC tutorial.
Also, most of the rendered sencha touch components seem to maintain state between changes of the active item. For example. I have a main TabPanel that contains all sub panels. When switching between tabs on the main TabPanel's TabBar, each sub panel maintains its rendering, unless I've set a listener or controller action to do otherwise.
Hope this helps.
Basically every time you refresh the page the browser clears the screen so it's completely white, then paints everything real fast. This causes a noticeable jump when switching pages or refreshing a page. It is most noticeable in FF and least noticeable in safari with IE being in the middle.
Is this fixable or just a con to using Sifr?
I think it's a con to using Flash to render text. Have you considered using a server side language to generate text or typeface.js ?
Or better still, can you use a web safe font, or is the client the type that won't budge?
Edit
You may be talking about FOUC ... Flash of unstyled content. This generally is an IE issue with stylesheet placement, but I've seen in it Safari before too. There are generally workarounds for this.