Develop Reference

Would the version of Chrome affect the behavior of a JavaScript library?

I ran into a bug that seems very nuanced and strange. I am using OpenLayers (v4.0.1) in a web application to display multiple WMS layers from a GeoServer (v2.8.2). Everything seemed to be working great until Windows 10 did a big update. Shortly thereafter, my browser began to crash when attempting to view the page on which the map and all of its layers should be displayed.
After a lot of digging, it appeared that this issue only shows up in Chrome Version 60 (60.0.3112.90 to be exact). I tried to reproduce the issue on multiple OS's and browser combinations (Linux/Windows/Mac and Firefox/IE/Edge/Chrome Version 59) and it works great everywhere except on Chrome 60 (across all OS's).
Though still hard to pin-point exactly, when doing a step-through of the JavaScript to find where the hang-up occurs, it is definitely happening somewhere inside of the OpenLayers code. Another key discovery is that the error does not occur at all if the browser window size is "small" enough. In other words, if I resize my window and try again, it will suddenly work consistently once a somewhat-random-seeming, certain browser size is reached. It seems to be more area-dependent, though, than a specific height/width constraint, as various height/width combinations will either work or not work.
At this point I have no great idea on how to resolve this issue, so I'm starting here by simply wondering if anyone knows if it would make sense that something in Chrome 60 is changing the behavior of the OpenLayers JavaScript library? If so, I'd want to open up an official GitHub issue with them. If not, would it be a Chrome issue I'd report? I'm reluctant to believe it is something that I have programmed, as it works in every other browser.
Thoughts?

This does indeed sound like a Chrome bug. Please file a bug at crbug.com/new, and include:
repro instructions (ideally, a link to a site that will trigger the crash)
any crash reports you see in chrome://crashes (if this is what caused them)
If you post the bug number here, I'll make sure it gets looked at. Thanks!

Performance issues in IE11 using ExtJS 4.2.1

I am facing performance issues with Tabs Panel for IE9 (and above) if I even open just 2-3 tabs with HTML document of size varying from 1MB to 20MB. Then on switching between tabs it’s taking around 3-4 seconds (when page has only tab panel) and around 5-6 seconds (when page has a lot of other extjs components) on IE-11. The response is almost 1-2 secs on IE8 which is very surprising.
I also tried with different hideMode options (Display, offsets, visibility, asclass) but with not much benefit although hideMode='asclass' is comparatively fast than other options.
I also created a sample page to confirm if it is really document size issue or extjs component issue. Created simple tabs (with divs) without any JS library and just changed their css z-index (instead of css display or css visibility) and they were switching instantly (on all IE versions). Trying the same solution on a separate page for ExtJS doesn't help on IE11 (somewhat faster on IE8). So it seems to be ExtJS specific issue.
Has anyone else ever faced this issue? Any comments or solutions would be greatly appreciated.

You can use the profiler for IE to see whether any scripts related to ExtJS 4.2.1 take a long time to load. If you discover such a script, you can then proceed to making a bug report for this library.
Here's some detailed information of how to do JavaScript profiling in IE.
Profiling JavaScript performance

Mobile Safari on iOS crashes on big pages

I have a problem where Mobile Safari crashes when loading and manipulating the DOM with jQuery when the pages get too big.
I get the same problem on both iPhone and iPad.
What are the best way to troubleshoot mobile pages to find the error? Are there any known problems that might crash Mobile Safari?

I actually found the problem. It wasn't with JS as I thought, but with the CSS. I added class to make a CSS transition to fade in some elements. For anonymous users these elements had display: none; and probably never ran the opacity transition.
The strange thing is that the transitions was on exactly two elements. So why would this only crash on long threads with 100+ comments?
So the bottom line is: -webkit-transition crashed the page on mobile safari.

Had the same issue, for me it was -webkit-transform: translateZ(0); that caused the crash of Safari.

I know this question has been successfully answered but I just wanted to put my five cents in too as I have been banging my head against the wall over this one quite a few times:
As most answers have pointed out already it usually comes down to memory issues. Almost anything can be the last bit that finally tips over the "memory pile" much like a translateZ or anything else.
However in my experience it has nothing to do with the actual CSS (or JS) command in specific. It just happens to be that the last transition was one too much.
What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.

The main issue with any iOS app is memory usage. So, it is likely that your pages are using too much memory.
Mobile Safari use some clever technique so that not the whole page has to reside in memory at any given time, only a portion of it. Maybe you could check if anything in your page defeats this mechanism or makes it less effective.
In any case, to give more up to the point suggestions, more information about your page would be really great.
By the way, you could have some hints from the crash log that the device store. Check to see if you can find it under Settings:
General
About
Diagnostics & Usage
Diagnostics & Usage Data
If it's a memory problem, you should find something like "signal (0)"; not sure if this can only mean "killed due to memory usage", but I usually take this for granted when I found a signal (0).
Otherwise, it might tell you what is wrong...
Hope this helps.

There are both memory limits and Javascript execution time limits, though it's a little fuzzy as to how you may actually hit those. Common reports come in that a page with a size greater than 10MB will have issues, and Javascript execution is limited to 10 seconds.
See Apple's documentation for more info.

I recently had an issue with mobile safari crashing on web-app pages containing a lot of images (30+ were enough) and a few transformations for the menu. After a lot of trial and error, I settled with a solution similar to what LinkedIn does, but for infinite scrolling using angularjs. I used requestAnimFrame and two expanding/shrinking divs (with js style attributes) on the top and bottom of the list to remove all image containers (with other stuff overlayed on top) except for a few ones which are close to the viewport. Scrolling performance (native, no js) is fine and memory consumption is in check.

I had a similar problem, the web page worked like a charm on android devices and crashed on IOS (iphone and simulator).
After a lot of research (using also the ios_webkit_debug_proxy) I found that the problem was connected to the jQuery ready event.
Adding a little timeout solved the problem. My application was also using iframes.
$(document).ready(function () {
window.setTimeout(function () { ready(); }, 10);
});

Problem with headjs resizer

I have been playing around lately with head.js but I have found a stranger behavior that I think is not normal. When I'm using the screen size detector for resizing functionality the classes for the size doesn't change as it was expected to adapt to the new size (when you change the size of the window).
Have anyone experienced a similar problem with head.js?
Thanks!
EDIT: Head.js answered the ticket on Github and the problem is fixed:
This is now fixed:
https://github.com/headjs/headjs/commit/91324d8e676fd7a7f22c9f51f5482db0cb155f1b
NOTE: I did not update the minified
version of the file at this point.
Thanks!

Playing around on the headjs.com website, it doesn't seem as if its updating the classes as I resize my browser (which it is supposed to do according to the description). Perhaps a bug report is in order?

Jquery Load function issue in IE6

i am using IE6 as a browser and when i call upon a local HTML file as an overlay by using Load function it loads the page but, following things happens
1: shows a loading status bar all the time
2: All the javascript in the called page(overlay) stopped working.
this is the call code
$("#mainoverlay").load("card1.html");

IE6 has known issues with transparent images (IE6 has A LOT of issues). There are numerous javascript fixes for this - but they all work basically the same way with a 1x1 pixel GIF. If you have the ability to go with JPGs or GIFs instead, that would save you a lot of heartache - but I would guess you would have already gone that way if you could have.
One way I've dealt with it in the past is to detect the browser and swap in a non-transparent image (GIF/JPG) if it is IE6. This is approach has many challenges as well and will end up being a significant effort.
The bottom line is that IE6 is just a pain in the rear. You might want to try one of the other IE6 transparent image solutions to try to avoid the conflict, but I wouldn't be optimistic on coming up with a clean execution.

use DD_Belated.png to fix PNGs in IE6 and this may fix this secondary issue: http://www.dillerdesign.com/experiment/DD_belatedPNG/