I am currently working on a new frontend javascript framework. In past few days I refactored the DOM updater and few another code to look nicer and to get rid of some memory leaks when DOM elements stayed detached in memory.
Unfortunately, Safari on both, iPhone and iPad 2 started crashing now from unknown reason (the rest of browsers I am testing on are fine
windows:
IE10emu/11, edge 14, chrome, opera, FF - latest versions
android:
Webview 4, 38, chrome, opera, ff - latest versions
and there is no problem).
I tried to debug it with remote debugging using the Chrome on Windows and ios_webkit_debug_proxy but unfortunately it does not show anything to me.
I am almost convienced the problem occurs when I am working with the main DOM document or with the shadow DOM document.
What is strange: when I switch logging to console on (there is extensive logging
feature in the framework) just for the DOM updater module and use the remote debug feature, everything seems to be working fine (except its slow of course) and it does not crash anymore so I can't even see when it crashes.
As I have no Mac even the Apple dev license I am looking for help of somebody who owns Mac and have some dev experience. I would like to know if it is possible to somehow debug these kind of unexpected crashes or at least if it is possible to get the reason why it is crashing (some kind of safari log?) - memory leaks, out of memory... whatever what can help me to do some workaround.
The previous version was working fine. Compared to it I am not doing anything special, especially when manipulating the DOM but the code is reordered, placed in more functions / methods and optimized a little bit.
The working (less or more :) version can be found here: http://ajsfw.azurewebsites.net/
The problematic version can be found here: http://ajsdoc.azurewebsites.net/ with logging switched off (i can switch on if necessary)
Sources for the working code can be found here: https://github.com/atomsoftwarestudios/ajsdoc.
I can also provide new, problematic sources if necessary but I don't want to push them to the main until it will get fixed so I can i.e. fork or send it as zipped package. The problem is it is a visual studio solution so bit incompatible with Mac at this time :) But I am pretty sure we can find a way.
The code is quiet complicated already and it will probably require bit of coopeartion by my side to find what is going on.
Hope you can help.
Update (problem resolved):
It was crashing on adding/removing "ontouchmove" event listeners.
I am using multiple HTML documents (document.implementation.createHTML) for templates and the main document (window.document) as a managed render target. When I loaded templates to the "shadow dom" using the innerHTML the ontouch... attribute assigned to the template tag was causing the problem so before I set the template innerHTML I rename it and later during rendering to the main DOM I addEventListener with the original name.
What is strange: before refactoring it didn't matter the event listener was registered in the template "shadow DOM". But I also added some new features so maybe one of them is causing it. Hard to debug, especially when the browser is crashing. Important is it works like charm again even with small complication in the code.
Results can be seen on links provided before, ajsdoc... is with logging so slower (slow as hell with IE10/11), ajsfw if unoptimized (unminimized) release without logging so faster.
Fixed sources commited if sbdy is interrested
So I have finally obtained some crash logs from Safari.
It is crashing on adding "ontouchmove" event listener. Now I have to figure out why it didn't crash in previous version and register it in a different time.
So, just to summarise where the problem was, I am using multiple HTML documents (document.implementation.createHTML) for templates and the main document (window.document) as a managed render target. When I loaded templates to the "shadow Dom" using the innerHTML the ontouch... attribute assigned to the template tag was causing the problem so before I set the template innerHTML I rename it and later during rendering to the main DOM I addEventListener with the original name.
What is strange: before refactoring it didn't matter the event listener was registered in the template "shadow DOM". But I also added some new features so maybe one of them is causing it. Hard to debug, especially when the browser is crashing. Important is it works like charm again even with small complication in the code.
Related
Update 2018-03-01:
This issue has apparently been fixed in version 66. Tested a number of pages in Android Chrome Dev and Canary, no crashes observed even during long and/or heavy runs. I never did find a workaround, however 66 should be hitting Chrome Beta soon, and not too long after Stable so normal users should be able to run them again on Android in the regular version of Chrome within a few(ish) weeks. Incidentally, this is the same update that Chrome will fully discontinue trust in Symantec-CA-based HTTPS/SSL certs. I have noticed it seems slightly janky in comparison to before, but will have to test as this could be merely subjective on my part, or due to changes in my code looking for workarounds. Further info can be found in the Chromium Bug report linked to below.
** Note: If you've followed this post... I have to admit I thought I had a workaround by rounding values to only two decimals out. However, I later realized this was causing a side-effect (because of an optimization I had made) of scale3d-ing some elements to 0,0,0, essentially causing them not to be rendered, and thus not triggering the problem for a long time. When I temporarily removed scaling, said elements rendered again, and the bug was triggered. Deep andhumble appologies, but-- problem not solved. So, I have removed my answer. Here are some things I have tried, none of which were successful:
Rounding transform decimal values to x.xx, two digits out.
Rounding transform values to straight integers.
Using setInterval instead of RAF to see if that was a factor (ugh!).
Using a style tag and .innerHTML to set dynamic transforms via css instead of the DOM (this was surprisingly efficient, but still triggered a crash just the same.
I've tried narrowing it down to particular transform parameters, numerical patterns, element nesting depths, just about anything I can think of to get around triggering a crash, and it looks like there is only one pattern: every time you do a transform there is a chance of a crash. It's a seemingly tiny probability, but doing scripted animations, even if you optimize to prevent repeats of identical transforms, makes the crash inevitable. I can make it take longer, but I can't prevent it.
Now, I've seen similar reports all over the web regarding recent problems with CSS in Chrome since November, when version 62 update was pushed on the stable channel. This last test, using a dynamically generates, embedded style-sheet to update the transforms was especially dis-heartening. There doesn't seem to be a way around it except to wait for version 67 when chromium.org says the fix should come out. That is months away for the typical Android-user.
This problem is not relegated to scripted animations either. I've seen similar issues reported with CSS animations and transitions as well.
I've gone to the extent of trying a number of my animation engines from the past, all of which work beautifully on version 61 down to when RAF was available. I've even written new, simple test engines, just for this. I've tried a number of other developers engines. Still crashes.
At this point, I think the only thing that can be done is to wait for the fix, and possibly get enough attention from enough people to hope they will up the priority.
They said in the ticket it's a problem with a code-optimization. I would really like to see them revert that portion back in version 65 before it hits the stable channel, so the average user will not see this problem soon. There's still time to generate another build and get it out before then.
Anyone who would like to see this happen, please go to the link below and put your two cents in on the ticket at chromium.org.
PREVIOUS UPDATE: This issue has now been tested and confirmed at chromium.org as a bug in the GPU rasterization code, affecting up to version 66 of Chrome for Android, and appearing after build 62.0.3197.0 (the last build unaffected). Their engineers are now working to fix it.
I am leaving this open for anyone who has run into this issue, so they don't think it's a problem with their code, and in case anyone happens to read it that can either contribute to the fix or offer a reasonable workaround until a patched build is released. If anyone does find a workaround, please provide it as an answer here.
For those interested, the link to the ticket is below. Here is an excerpt from the bug report:
Tested the issue in Android and able to reproduce the issue.
Steps Followed:
1. Launched the Chrome Browser.
2. Navigate to the URL: https://keithclark.co.uk/labs/css-fps/
3. Tap on any of the tab and try to access the game
4. Observed that Chrome gets hanged.
Chrome versions tested:
64.0.3282.116 Stable/Beta, 65.0.3325.16 (dev) 66.0.3328.0(Canary)
OS: Android 8.1.0
Android Devices: Pixel
Using the per-revision bisect providing the bisect results, Good Build
- 62.0.3197.0 (497604) Bad Build - 62.0.3198.0 (497674)
You are looking for a change made after 497614(GOOD), but before
497615(BAD).
Previously:
Not quite sure if this is a Javascript, CSS, or Android problem-- but here goes...
Basic Question: What do I need to do to keep my pages with scripted RAF 3D transforms from locking up Chrome vs. 62 and above on Android? Is anyone else having this problem?
**Note: This problem may actually be a Chromium issue. I have opened a bug report with Chromium Project. Those interested can view the ticket here: https://bugs.chromium.org/p/chromium/issues/detail?id=805525
I am leaving this open for now so they can view the full description, and in case it turns out I can fix my own pages with a change to my code. But please, read on... ;)
Background:
My pages work great on 61 and below. I manually updated Chrome on my Samsung Note 3 to version 63 stable recently, and found every page (not just mine) with complex, nested 3D transforms running on a requestAnimationFrame loop would lock up the browser. A perfect example is a page from Keith Clark, who has a CSS/HTML/Javascript proof-of-concept demo of a First-Person Shooter. Now, the mobile version worked great on my phone before. After the update, it locks up. My pages work really good, even on weak devices, till this update.
I've narrowed it down a bit. If I clear cache, and uninstall updates, the stock Chrome (41) runs these things great. Install updates to 63, 62, 64(beta), same problem. I can't remember if I tested 60 or 61, but update to version 59 and we're still golden. Firefox is fine. Opera is well, Opera. Same updates on desktop run great.
What I'm not totally sure of is if it's a problem with my phone. No other problems, ever. I know it's a little old, but it still blows most mobile devices off the shelf. Android version 5, Lollipop. Rooted. If any of that matters. Malware scans have always produced 0 with any AV/M app I've tried. I'm very careful.
Anyway, if anyone else has had this problem, or knows of it...
What do I need to change in my code to make it compatible with current Chrome on Android? Is this a problem I need to solve with code? I've looked everywhere but can't seem to find info specifically on it. All I can say is it's breaking my animations. I can't even use dev tools to figure it out, as running a perf check from my computer crashes my phone so bad Chrome dies and loses the connection and any performance data gained, taking my phones wallpaper along with it!
I'm not picking up any errors from my script-- it's fairly basic. I stripped it down to bare bones because I thought I had a runtime error, but nothing. Is there a change with the way Chrome for Android interprets the CSS or does the layering or something?
Sincere apologies if this ends up being off-topic, as I'm not totally sure if this a coding issue, or just a problem with my phone in particular. If it's a coding issue, that's what I need to know-- and how to fix it.
I have more general question on how you usually approach on debugging page with tons of javascript (mostly third-party add-ons) and event watchers to discover the problematic line, which in my case causes the Chrome to crash or Firefox to freeze?
I have a landing page with many external dependencies: the usual suspects like jquery and bootstrap, but also many add-ons like sliders, re-size watchers. When I re-size there is a micro-freeze on Firefox and a crash on Chrome. This is from any block of code (some watchers most probably).
After page crashes I lose all of my dev tool data. Firebug doesn't have the timing control over scripts execution, and if I start with breakpoints I have to put dozens.
How you usually proceeding to identify the script that causes the problem and further more the block of code?
If I start with breakpoints I have to put dozens.
I used to have this problem a lot back with Internet Explorer 4/5. Those browsers made such poor use of memory that almost any significant error wold result in the browser crashing. And even before it did, the browser debugging tools were far, far worse than the Chrome ones. So what did I do? Sadly, debugger and console.log.
You must have some idea, or ideas, as to where the problem lies, so just start at wherever you are certain your code is working and add a console.log (if you can still see the logs up to the crash) or a debugger (if you can't) to every point along the way to the crash. Eventually you won't make it to one of your debugging statements, and then you'll know that the problem is in-between that statement and the previous one.
It's a really lame way to debug, I know, and as you said you will have to add a lot of debugging statements, but sometimes it's all you have.
Suddenly I’m experiencing something strange with document.getElementsByClassName in my website.
Here is what happened:
I am running an aspx website on IIS7.0 where some parts of my JavaScript code uses document.getElementsByClassName.
I never experienced any problems with this on Firefox, Chrome or IE8+
Today, I’m migrating my website to a new server, which runs IIS7.0 as well.
I copied my website, and suddenly document.getElementsByClassName is not recognized any more by IE8+ (it works normally in Chrome and Firefox though...)
I know there is a workaround for this issue described here: javascript document.getElementsByClassName compatibility with IE but that is not the question.
My question is: how is it possible that document.getElementsByClassName no longer works, while I just copied my website?
Is their something to be changed on the new server, IIS, … ?
Many thanks,
The major change to this working app is the change of server. I'm
pretty sure my comment above is a much more likely cause for the issue
than Joseph's prediction of coding mistakes. Sudhansu gave a good
suggestion as to the reason Compatibility Mode is being changed, but
ultimately, that's the thing you have to check. Read my earlier
comment.
– Katana314
Already suggested in comments, but to wrap up as answer:
If a working IE11 site suddenly stops working on another server, and the connection string's structure has changed in some way, the most likely cause is that IE11 believes it's viewing an old intranet site, and pessimistically uses IE7 mode for maximum compatibility. A few other things can cause this, like having an unreadable or old <!DOCTYPE at the beginning of the page.
You can change IE11's default compatibility settings to fix the issue locally, use a fully-qualified domain name, or there are some <meta> tags or HTTP response headers you can add to change IE's default behavior. Microsoft would likely have more informative articles on their own site.
Yes, I know, IE 7 is dated and does not support modern technology. **Insert classic Microsoft joke**
However I work for a state University and there is a lot of red tape so for the time being we still partially support IE7 (hopefully that won't be the case soon). Also, I'm really curious about this issue.
I have read through Angular's documentation for supporting old versions of IE and for the most part I can get things to work. But oddly enough, a simple Angular application crashes on IE7 if you populate two attributes with data bound content in the same HTML tag.
For instance if I am looping (ng-repeat) through an object to create a link list, this works just fine:
Google
But this does not work:
Google
In fact it crashes the whole application. Any thoughts?
Here is a working Plunkr http://plnkr.co/edit/znbXJkhiEQXqhTcyYcU4?p=preview just so you can preview some sample code. When I run that code on a static .html page in an IE 7 browser emulator (browserstack.com), nothing shows, not even the "Hello World". Just the Angular templating brackets.
Please let me know if you need more information. Thanks.
So I was involved in a site rewrite recently and we've gone live with what’s a big improvement on the previous in every way (no it's not perfect, we live by deadlines and are always improving :D) with one exception: in IE6/7 it will lockup after the page has shown. I know it's the JS as with it disabled it's fast and I'm aware of some things like the simplegallery plugin that we use being very slow but even with that and Google ads removed it's still at a crawl(+8sec). I've looked through the Firebug profiler and made loads of JS/CSS changes such as:
Moving all JS except our img error handling to the bottom of the page
Improving all jQuery selectors specify for best performance
Moving to jQuery 1.4
running our core custom JS (main.js) through JS Lint
Spriting commonly used images
Reducing CSS selector complexity
Doing this was good for all browsers and I know I can do even more but I'm not seeing a major improvement in IE6/7 which I need. We do use DD_roundies_0.0.2a.js for IE7 but not for IE6. I tried DynaTrace but couldn't see anything obvious though I did get a bit lost in its depth.
A sample listing page
A sample search page
Can anyone see what I might be missing here and/or point to some good IE profiling tools?
Edit: I should have mentioned that I've been through YSlow, PageSpeed and Chrome's Developer Tool. All of which I used to base most of the improvements mentioned above on. At this point I'm not saying the site is fully optomised but it's Ok and moving in the right direction. However I have an issue in IE6/7 and I believe it to be the JS execution.
Edit 2: We already send down the Chrome Frame meta tag for IE6 from the server. It's not a solution but I see it doing more good than harm for IE6. I'm after JS specifc feedback at this point as I think I've covered all the other bases.
You can manually profile your "common.js" script in IE6.
Just grab a new time-stamp at strategic places and alert them at the end.
e.g.
function ts() { return (new Date).getTime(); }
var t0 = ts();
// some of your code
var t1 = ts();
// rest of your code
var t2 = t();
alert(t1-t0); // milliseconds between t0 and t1
alert(t2-t0); // ms between t0 and t2
Maybe one part of the script is that much slower than the rest.
Or maybe it's just IE6.
You're including jquery from http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.js, it'll download faster if you host it on your website.
Also, checkout the YSlow addon for Firebug, it gives you lots of information about what you can do to improve the load time of your site.
If you want to be drastic force your users to install the Google Chrome Frame it will make IE use the chrome renderer and javascript engine
http://code.google.com/chrome/chromeframe/
Currently only thing that seemed there suspicious was "omniture.js".
Here's a blog post I found regarding omniture.js and IE6.
You can use SpeedTracer on Chrome to debug speed issues. Of course the js speed will be according to V8 engine.
The javascript itself is often not the issue, it's when you modify the DOM you end up in trouble, for example animating, adding and removing elements. Be extra careful with opacity.
Take a look at LABjs & RequireJS: Loading JavaScript Resources the Fun Way which talks about how you can load scripts in parallel.
Until the latest generation of
browsers, the tag had some
really unfavorable performance
characteristics to it. Namely,
tags “block”, meaning they
call a halt to everything else that’s
loading/happening on the page, while
they load and while they execute. Not
only do they halt all other parts of
the page, they even used to halt the
loading of any other tags.