On my Mac Book Pro, you CANNOT download the Adobe AIR SDK from the Adobe site using Safari.
I have found this to be true for several months.
http://www.adobe.com/devnet/air/air-sdk-download.html
Use Firefox instead to download the Adobe AIR SDK. It works!
This is a problem with Adobe's server, still happening today (Apr 18th, 2013). It doesn't send the appropriate binary content-type to the browser, so Safari tries to show the big 200 MB tbz2 file in the browser, as if it was a plain text file. This causes Safari to stall and show the "spinning beach ball of death", which in some cases even makes the OS unresponsive, leaving you with little choice but to turn off the computer holding the power button a few seconds. This is poor coding in Safari's part. Big text files (even if they're not really text files in this case) shouldn't bring down the browser and the OS.
Even though this is Adobe's fault for not sending the appropriate content-type, Safari could have fixed this problem in the fly, as Firefox does (it detects binary files even if the content-type is not correct). But it doesn't, and thus this problem happens.
Please vote in this bugbase report so Adobe fixes this:
https://bugbase.adobe.com/index.cfm?event=bug&id=3544775
Related
Chrome mobile browser for iOS and after updated iOS to 16.1 version rendered one of my website as a download. Anyone had the same problem? Earlier I've never seen that for the years. That problem is occasional but some of traffic is lost.
The url looks like this (on the left side see the download icon):
The rest part of the website is rendered only as a text and photo.
Others mobile browsers checked and I didn't see that problem. The same for Android but in this case my website is the right rendered for all browsers.
Could you tell me where I should look for the reason of that problem?
In my current MEAN stack project, everything functions fine on desktop Safari, Chrome, and mobile Chrome, but in mobile Safari for iOS, data-binding shows as text (e.g. {{data.total}} as opposed to $25). To make matters worse, when I open the app from iOS Safari served from localhost, it also works properly.
I've tried rolling back my Heroku app and the problem persists, even when I go back to a version from when I'm sure it looked good on an iPhone. I've checked it out on others' iPhones, and gotten the same negative result. I can't find this problem elsewhere on the internet, nor am I sure what I should be looking for as the problem seems to be with Heroku or iOS.
Here's the live page: http://minneapolish3-beta.herokuapp.com/reddress. This has me very much stumped, but I'm pretty green. If you find it not working on other platforms, I'd love to know about that as well.
(Naturally, I can't well spin up a CodePen example as the problem is only occurring in the wild.)
A friend introduced me to the Safari Web Inspector for mobile which allwed me to see warnings, alerts, etc.
It turns out that my Google Maps API call, via http://, was causing the page to break on mobile Safari. When I changed it to https:// everything worked! Thanks go to Bonus Kun whose answer to another question helped expedite my solution.
Having a very difficult time tracking down a solution to this bug, hoping someone can help me.
My web app http://www.customozer.com loads fine on desktop, but on mobile safari, some images load corrupt (screenshots below in comments).
This issue does not appear when I use chrome on my ipad (iOS 8.1.2), just safari and saved web apps.
What's also interesting is that when loaded directly from my local MAMP stack using an ngrok tunnel (http://alexgoodwinmedia.ngrok.com/Oz-Snowboards/site/app.php), the issue does not appear. Files on my local machine and on the customozer.com server are synced.
From what I've read, there's a mobile safari issue with loading large amounts of AJAX data.. but that's not how these images are being loaded.
Does anyone have some insight into how can this issue be resolved? Happy to provide more details/tests.
Thanks!
After rather extensive testing, I've finally concluded that the PNG images were being corrupt by an old version of PNGlib (a GDlib element). By moving my project to a new server that allowed for a newer version of GDlib to be installed, I was able to fix the problem.
I've been doing lots of work in getting a few web apps to work offline on iOS using the HTML5 manifest. I've ran across the typical problems everyone else has and fixed them and everything seems to be working fine—except in the case where I save the web app to the desktop on my iPhone 4.
If I do this and then enable airplane mode, I get the following alert when trying to access the app via the home screen: "your-app-name could not be opened because its not connected to the internet." Accessing the app via Safari browser works fine while offline.
If anyone knows if this is an error on my part, or even the slim possibility of a work around, do tell.
Even downloading the new Financial Times web app (very well done with extensive localStorage support) results in an error when accessing it offline from the home screen.
Technical specs: Running iPhone 4 with iOS 4.3.3 (but also saw the issue in 4.3.2)
After reading the comments (especially Rowan's) I ran more tests and found the answer:
No, Apple did not disable HTML5 offline capability for web apps saved to the home screen, it works - for the most part. There is a bug that will make it not work. It doesn't seem to have anything to do with your manifest setup (unless perhaps it downloaded a bad manifest or incomplete manifest at one point.) We don't know how widespread it is but the fix is to clear your Mobile Safari Cache.
Here's the steps:
Close the web app (make sure its not sticking around in the background).
Cleared Mobile Safari cache: Settings > Safari > Clear Cache
Reopened the app (for caching).
Close the web app again (make sure its not sticking around in the background).
Enabled "Airplane Mode": Settings > Airplane Mode
Reopened the app.
It should now work offline. If it doesn't then its probably a separate manifest issue in your app. Looks like a weird bug with the browser cache - or perhaps the cache was completely full? Who knows, but that's the answer. Thanks guys.
iOS seems to be very sensitive to load issues when offline.
I was getting your "could not be opened" error when offline on a page I was working on. The problem turned out to be that the page created an iframe pointing to a site that didn't have an AppCache. Removing those iframes fixed the issue.
In my case, I handled it using window.navigator.standalone which tells you whether you're running in an iOS homescreen app. The code looked like this:
if (!navigator.standalone) insertFrames();
add this to your html:
https://web.archive.org/web/20170201180939/https://jonathanstark.com/blog/debugging-html-5-offline-application-cache?filename=2009/09/27/debugging-html-5-offline-application-cache/
I found it massively useful - even though I've created my manifest file and compared it to other people's manifests this JavaScript debugging script gave me the clue I would have never found otherwise. I apparently had syntax error in my manifest ... long story short I had to remove everything and add the paths to each file/image one by one. The end result was the same however it worked... how weird!!! does whitespace / comments affect the syntax of the file?
I am developing an app for both BlackBerry and Android. On Android, when I send the browser to some url, it redirects to another url with good look. But on BlackBerry for the same url it is only displaying links on the site. It is not applying css and does not look like the Android layout.
Blackberry browser (specially in OS versions < 6) is not as good as the Android one. There are also a couple of options in the Browser Settings that you should enable for it to load JavaScript, Background Images or PC-targeted CSS files. Sadly, there seems to be no way of automatically passing this as a parameter to the browser before opening.
You're facing a platform issue, not a developer's one. Although you could, of course, create a set of CSS files intended for Blackberry visitors, taking these limits in mind and being conscious that it will not look as good as the Android one.