Can anyone help me figure out why this page causes Android browsers to crash?
http://thewellcommunity.org
All sub-pages seem to work just fine, but when I load the home page on an Android, the browser app just closes without any warning or error messages. I've tried this on 3 Android phones and on a Kindle Fire.
When I completely disable JavaScript in the browser on the phone, the page loads successfully. Unfortunately this is a live website, so I'd prefer to save disabling chunks of JavaScript on the server side as a last resort.
On a side note, Opera Mini, Opera Mobile and Firefox on an Android phone do not crash, but Dolphin, Miren and the stock browser do.
UPDATE: It appears that I spoke too soon when I said this was fixed. I was able to reduce how often the browser crashes, but it still does occasionally crash when the page is loaded. :(
UPDATE #2: It now appears that the crash may be CSS related. After spending weeks enabling and disabling various JavaScript snippits, I tried disabling the stylesheet, and now I can't get it to crash.
Anyone know of an Android CSS bug that might be causing this? My guess is that it's related to some CSS that only gets accessed after the JavaScript does it's work.
I found the culprit... It appears that a css font-family rule was to blame. Although, I'm not sure why since the same font stack is used several other places on the site. :\
Here's the line that caused the problem...
.Site-Search .Buttons input
{
...
font-family: TeXGyreHerosRegular, Arial, "Helvetica Neue", Helvetica, sans-serif;
...
}
For whatever reason that line caused all stock Android browsers to crash. Weird.
Check out Weinre. An explanation can be seen in this youtube movie.
That way you can debug the Android webkit browser just like the well known Firebug.
In Eclipse's emulator (2.3) it loads fine but has some layout flaws.
If anyone came here looking for a possible reason why all of their mobile's different browsers crash after a several seconds when loading a particular website it may be due to the version of jQuery employed.
For example, the LG-p690f and HTC Incredible S are some of several Android 2.3.x phones known to have troubles with fade transitions in jQuery 1.8.1 and 1.8.2 due to a browser javascript bug that will cause jQuery's Animation function to fail at this line:
percent = 1 - ( remaining / animation.duration || 0 )
If you are the owner of the website you can try upgrading to 1.8.3 (or downgrading to 1.7.x if allowed). Otherwise, you can send an e-mail to the website.
Sources:
http://bugs.jquery.com/ticket/12497
https://github.com/jquery/jquery/pull/1019
Related
I have some problems with my website. My site is coded in HTML,CSS and JS.
Everywhere works perfect, Desktop (all browsers), Android (All browsers), in iPhone(iOS.11) doesn't work!!!
I think there may be two problems:
1. When i open the site, i have Loading Page script, and in iPhone it stops there and doesnt open the site.
2. The problem may also be with the new iOS 11, because with earlier iOS(10) was working very well.
Any suggestion, or any site which i can check my errors (debugg) or..?
google didn't solve my problem so i decided to ask, but still can't find the problem!!!
Thanks.
If you have an OSX available you can enable remote debug and see what's happening, most likely something is breaking based on something not being available.
I have an issue with Firefox. In both responsive mode and Firefox Mobile to be accurate.
The touch scrolling isn't working on my website. (But the scroll with the mouse is working on Responsive mode)
It works fine on Chrome mobile & Safari mobile.
I checked online and I already tried the dom.w3c_touch_events.enabled set to 1. It was actually set to 1 by default.
I think it's an issue on the JS/CSS side but I can't see where.
I use SASS and Pleeease to compile it and it's a React app compiled with webpack.
Also I use the method fetch to call my webservices if it can have any influence but I doubt it. (and have a polyfill for it)
I tried to nuke totally my CSS and it still didn't work.
Happy to share URL if people want to see the actual problem. I just don't want to be seen as a spam. Also I will share a test server and not the live one. (problem is the same anyway)
Found the (stupid) solution and posting it as it might be helpful to someone.
I had a overflow:hidden; added by mistake in html, body { into my SASS.
For some reason the responsive mode in Firefox is still not working (bug? cache? I don't know...). But once I tried again on my Firefox mobile it was gone.
Looks like Chrome and Safari are ignoring this CSS but not Firefox.
For the record I am on last versions on all my browsers.
I'm tearing my hair out at this one.
On my iPhone 5s running iOS 7.1.1 everything regarding my web page is fine:
WEBSITE LINK REMOVED FOR SECURITY PURPOSES.
However, on iPhone 5s running iOS 9 I get the following error, that completely destroys / does not load the page, making it completely unusable:
"A problem occurred with this web page so it was reloaded"
I have searched high and low for ideas about this one but there appears to be no real direct cause.
One thing I noticed in my trial and error testing, is that if I remove the main app.min.css stylesheet, it will at the least load the page (DOM).
However, if I then load the CSS but this time with an empty file...the error appears. So it appears that it's not related to my CSS per se - just to the act of linking to it.
I've gone through and tried removing all scripts, images etc...with no luck. Removing the CSS is about as close as I have gotten to solving the issue, but even with a blank CSS file, the problem occurs. It makes no sense to me.
So to summarise what I know:
This appears to be triggered by the inclusion of my app.min.css
stylesheet.
Even if the CSS is included as a totally blank file, the error still happens.
Removing all JS does not solve the
issue.
It happens on any page, not just the landing page or any
particular area. Works fine on my older version of iOS but not the
newer 9+ on iPhone 5s
I'm hoping you can help. I would love to provide isolated code examples, but since this issue is so 'out there', I wouldn't know what to write up as a test case.
If there's anything obvious you can notice in dev tools I'd love to know. Thanks!
Here's a screenshot of the iOS simulator having the problem too:
After much debugging, I found the offending CSS that completely causes webkit browsers on iOS9 + to crash and burn (Safari and Chrome):
::-webkit-scrollbar-thumb:window-inactive {
// Properties
}
Removing this line now removes the error and loads the page correctly.
This problem was hard to debug because the iPhone heavily caches your CSS files. To get around this, cache bust your CSS when testing by appending a random query string to the end like so (PHP):
<link rel="stylesheet" href="/path/to/css/file.css?refresh=<?php echo md5(rand()); ?>">
Remember to remove this once your debugging is done so that you can take advantage of caching.
Twitter post here for sharing: https://twitter.com/michaelpumo/status/669478677600669696
Hope this helps somebody out there. What a pain it was!
Seems like your website opens only on Google Chrome. Safari crashed. Opening on Mozilla Firefox shed some light.
I see this error on the console downloadable font: download not allowed (font-family: "Tiempos Regular" style:normal weight:normal stretch:normal src index:1): content blocked source: http://example.com/wp-content/themes/future-cities/dist/fonts/TiemposTextWeb-Regular.woff
which is in app.min.css.
#font-face {
font-family: "Tiempos Regular";
font-style: normal;
font-weight: normal;
src: url("../fonts/TiemposTextWeb-Regular.eot?#iefix") format("embedded-opentype"),url("../fonts/TiemposTextWeb-Regular.woff") format("woff")
}
Take that font out of css and then try it. It should work.
Hope it helps!
Ever since Chrome updated itself to version 32, I have been experiencing aggravating bugs. One of the worst is when editing the DOM using the Web Inspector, and Chrome will about every minute start popping up this dialog, which yanks focus from the Web Inspector:
It's complaining about the Web Inspector itself being "unresponsive", when it really isn't, and nothing's gone wrong.
This particular page I'm messing with is making use of the mutation-summary library. Perhaps the bug in Chrome that thinks stuff is unresponsive could be related to setting various continuously-running setTimeouts. I say this because I observe similar behavior in the web app we build at work where this has also started happening (and is equally annoying).
The workaround is I believe it is possible to just ignore the dialog and work can continue. I wonder if anyone else (or everyone else) has been experiencing this issue?
I started getting this problem as well.
In searching, I came accross this issue https://code.google.com/p/chromium/issues/detail?id=335248.
As best I figured out, the bug is related to:
Windows 7/8 with Aero Theme
Scrollbars on pages (such as in the developer console)
Pages with popups (in particular Window.open() calls)
I guess they are slated to push the fix into version 33...and maybe leave the stable* 32 how it is (although I hope not).
So there are a few options:
Switch away from Aero Theme until version 33 is in stable
Upgrade to the beta channel, i.e. version 33
Click on the Wait button every 30 seconds whenever the chrome developer tools is open.
Update:
Chrome has released a hotfix into the version 32 stable channel. http://googlechromereleases.blogspot.ro/2014/01/stable-channel-update_27.html
Thanks to #probackpacker for bringing it to my attention.
I have experienced this as well on Windows, it seems that this will happen in general when using the browser (not only within the web inspector). It also seems to happen more often when loading flash content (such as a game). The browser and flash areas are responding normally, but the browser thinks that they are not for whatever reason. Pressing wait seems to hide the dialog for a few minutes until it will re-appear again.
I've read that this bug is fixed in the next beta (version 33).
Regards,
Moses
I have also experienced this issue. The change of theme workaround has worked, and the Chromium team has provided the following update today:
... We understand your frustration and are actively working to resolve
it. When you add that comment, it’s confusing the comments around
whether we’re able to fully fix it on canary. If we can confirm it’s
fully fixed in canary, we can merge into the stable channel and
everyone can get the fix. So please refrain from saying thatyou’re
having this problem, too. I assure you we’re actively working on a
fix.
This statement was taken from Chromium ticket #335248.
Okay here’s the solution you can do without changing your theme, right click on my computer, go to your System Properties, and then go to "Advanced", click on "Settings" under Performance, then check the below radio button. This seems to stop it
If the aero fix isn't working for you, download Chrome Beta
I have had this same issue with Chrome 32 (there are so many problems in the dev tools...) but it ONLY happens for me when I have the dev tools detached / undocked from the main browser window.
You might be able to avoid it by re-docking the devtools if you are using them in un-docked mode.
August 6, 2014 - I solved this by installing the latest Chrome Beta https://www.google.com/chrome/browser/beta.html
You can solve this problem in Chrome by following simple steps-
1-Go to Setting
2-Go to Advance Setting
3-Uncheck the "Use Hardware Acceleration when available".
I fixed that problem by linking modem directly to my PC, didn't reinstall or change Chrome or anything. I skipped connection through my wireless router which I think was the problem from the start... now all the pages Chrome couldn't load are loading with no problem at all. Maybe it's time to by a new router...
I am developing a web-app utilizing Application Cache, and everything is working great on desktop browsers and on Android (even very old & slow android handsets). However downloading the appcache is taking much much much longer on iOS 6 in both Safari and Chrome.
My application cache total size is a mere 2.1Mb, and I have a pretty solid 70Mbps (download) internet connection. I would expect caching to be pretty rapid.
Here are my times so far:
Desktop Chrome: <1s (similar times for Safari & Firefox)
Android 2.3.3 Stock Browser: ~4s (similar times for Chrome & Dolphin)
Android 4.2.2 (Emulated): ~7s (running inside a PhoneGap app)
iPhone 4S 6.0 Safari: 8 minutes!!! (around the same in iOS Chrome too!!)
iPad 2 6.0 Safari: as above!!!
All of these devices are using the same wifi and internet connection, and my iPhone/iPad are otherwise functioning fine (no native apps exhibiting internet speed issues, and regular websites load just fine). There just seems to be something absolutely decimating AppCache download speed under iOS.
The window.applicationCache.status throughout this time is appCache.DOWNLOADING, and I have a progress event running counting the files as they are downloaded, so I'm certain that it is not stuck elsewhere. This just appears to be the time it takes to download. What gives?
Addendum : The iPhone also runs ridiculously hot, and the battery ticks down very quickly during this operation. It seems that something is causing the CPU to run flat-out during this download.
(Note: I can't publish a link to the web-app here as we're still in private beta, but if you would need to see it before you think you'd be able to help diagnose it, email me at the address in my profile and I'll send a link to the app).
Okay, I figured it out with the help of the iOS Emulator, and Xcode Instruments to profile it. (I'm not sure if I should add my solution into the main question, or as an answer, but I thought I'd do it this way as my question is already a little cluttered).
As it turns out, it was actually some erroneous javascript causing the issue, but apparently only on iOS.
The web-app is intended to only be a single page high (no vertical scrolling, except within specific DIVs), so in addition to the usual standard JS code for hiding the address bar...
window.addEventListener("load",function() {
// Set a timeout...
setTimeout(function(){
// Hide the address bar!
window.scrollTo(0, 1);
}, 0);
});
...I had also added in the following:
$(document).scroll(
function(e){
window.scrollTo(0, 1);
});
From looking at the profile results, I was able to see that a lot of time was being spent in scrollTo, so it immediately pointed to this as the cause. Why the scroll event was being triggered so much, I have no idea (this was occurring with no touching of the screen whatsoever).
My initial fix is to throttle that code, but I am now evaluating whether or not I even need it at all. Here is the code I have that fixes it for now (using jquery-debounce, which I was already using for something else):
$(document).scroll(
$.throttle(function(e){
window.scrollTo(0, 1);
})
, 10);
The download time of the application cache is now in line with the Android times. Phew!
The code is getting itself into an infinite loop, as the initial scrollTo function call triggers the scroll event handler, which then repeatedly re-triggers itself! My best guess is that the iOS JavaScript engine handles this infinite loop differently to the other browsers' JavaScript engines.