I realize this is a very general question but we are wondering if anyone has any suggestions in trying to troubleshoot why Chrome hangs sometimes when rendering certain pages on our site. It's intermittent. We've tried checking out all the plug-ins, disabling, etc. Just can't come to any rhyme or reason why it's happening. Any pointers on how to troubleshoot and resolve would be appreciated. It's an ASP.NET MVC site. Internet Explorer has no issue. Thanks.
Without more details it isn't going to be possible for someone to answer your problem for you, but if you can invest a two or three hours in the problem then you may well be able to solve it yourself.
As the issue appears in Chrome then you may be interested in the free "Discover DevTools" course run by Codeschool and sponsored by Google (you have to register in order to follow the course, but it is free).
I suspect that the issue will turn out to be related to a memory leak where large numbers of elements are being added to and removed from the DOM using JavaScript, or the same element(s) are being added and removed multiple times. The course specifically covers "Memory Profiling" using Chrome Dev Tools, as well as the specific problem of memory leaks - the cause of them and how to resolve them.
If it is a memory leak, then the issue will closely correlate with the amount of time the page is open within the browser, especially if it is a result of one or more elements being frequently added and removed as a result of user interaction.
Related
I've been looking for an answer for a while now and I can't seem to find any reasons why this is an issue. I have various places in my style sheets where I use cursor: pointer for UI elements like buttons and links. The majority of the time it works as I expect, but occasionally they just don't want to work. I'd love to say I have a specific example in the style sheets that would ensure replication but that's been the issue. When it happens, it's not just for one element, it's for all of them. I've experienced this across the board with modern browsers and it seems to just be completely random which makes it hard to troubleshoot.
The only thing I've been able to confirm 100% is that if it does happen, I can open developer tools, then select an element to inspect that is supposed to have the cursor: pointer and the effect begins working everywhere again. I'm not sure what's going on here and it's driving me up the wall.
Is there any documentation surrounding this issue or something similar?
I experience it in localhost.
I haven't noticed it in production.
I haven't noticed it on JS Fiddle or Codepen when creating wireframes.
Is it a localhost issue? I've even thought it may be related to something I had done prior, but it happens even as I just navigate the site while debugging, sometimes it works on one page, but come back to the same page later in the session and it may not work anymore.
I know this one's tough and there's not a lot to go on. I don't usually make posts without code, but I'm just wondering if anyone else has experienced the same or a similar issue and resolved it.
I too have experienced this. It's actually not a code issue at all. I've found that the cursor: pointer bug you're experiencing is directly related to the Visual Studio 2017 (and newer) remote debugging browser window.
Solution
In Visual Studio, disable "Enable JavaScript Debugging for ASP.NET (Chrome & IE)".
At the top of your Visual Studio window, go to Debug -> Options. The highlighted item in the screenshow below must be unchecked:
This was a feature added in 2017, and while it helps with debugging JavaScript and TypeScript, it does so by launching a plain browser window ("remote debugger"); that is, no extensions, no bookmarks, no history, etc. The remote debugging browser window seems to have its fair share of bugs.
I saw this same behavior but not while debugging through visual studio. If I hit F12 to go to the Chrome dev tools, then click on an html element. The cursor goes to the style listed according to the style sheet.
Starting this afternoon, with the introduction of Chrome 31.0.1650.48, many web pages are displaying with random formatting errors. I've confirmed this on both Mac and Windows machines running the most recent auto-updated Chrome release (31.0.1650.48).
This problem is affecting thousands of pages, and to immediately rule out our server generating different information, you can try this to reproduce the problem:
Visit this Google cache page with Chrome version specified above: http://webcache.googleusercontent.com/search?q=cache:nt70v_rn5BwJ:alaskanmalamute.rescueme.org/Idaho+&cd=61&hl=en&ct=clnk&gl=us
Notice what dogs are displayed and where they are.
Reload the page several times and observer closely.
You will randomly see one dog listing in the middle of the page, then two dog listings, the dogs move around, the menus around the dogs move around. Each time the page is reloaded Google is corrupting the source code in different ways, resulting in major formatting issues. (NONE of this code is generated outside of Google's cache.) All the pages on the www.RescueMe.Org have this problem, I'm using a cached page on Google's server in this article for an example since it proves it is not a server issue.
This sample page should remain the same every time, and be formatted correctly. It isn't.
Google Chrome (when viewing source) seems to be making random changes to the page (Chrome is dropping < or > at random places in source code) causing major display formatting issues.
Can someone reproduce this? Hopefully the folks at Google know about this issue, or someone here can escalate it with them?
Best wishes,
Jeff
can confirm - it seems to mostly be an issue with iFrames.
VisualForce iFrames in Salesforce break the entire layout.
Version 31.0.1650.48 on Mac, all addons removed.
In case someone else runs into this issue, I've narrowed it down somewhat. Chrome/31.0.1650.48 will randomly scramble the placement of tables on a page if the following two things happen:
1) You start the page like this: and do the reverse at the end: (doesn't have to be face=arial, any font setting or even just does the same thing).
2) Include some tags within the page containing various tables.
3) Magic! (not good magic, though) Each time your tables will randomly move about the page. Here's an example to try: http://server1c.rescueme.org/testb (Reload this page several times in in Chrome/31.0.1650.48 on Windows or Mac to see the tables jump around.)
THE SOLUTION: Start the page like this instead: and do the reverse at the end: (in other words, reverse placement of the center and font tags). Here's the "fixed" version of the page above with just those tags reversed: http://server1c.rescueme.org/testbfixed
While this is a Chrome bug, I feel this is worth keeping in Stack Overflow because this bug is breaking a lot of major sites, and programmers may want to know how to reprogram their HTML so those who have affected versions of Chrome won't have a confusing experience.
FYI... There are other ways to cause and solve this problem, but I'm trying to present here just the simplest method I found.
I recall some very rare instances of seeing major websites (Amazon, Facebook, etc.) either not downloading a CSS file or not applying the rules, causing the page to look like this:
I've been tasked to provide an internal explanation after we received a complaint email with an attached screenshot from a user of one of our websites showing the same effect. The screenshot contains sensitive user information, so I'm unable to post it. But it shows that inline styles are being applied, but any style referenced from an external CSS file isn't being applied.
Unfortunately, I am unable to reproduce this issue, and other than just saying "styles aren't being applied", I am coming up dry with a detailed explanation and I would love to understand it myself.
I would appreciate any input on why this might happen, or reference to any articles. Even if someone knows what this event is called, I would be happy to go research it, but as of now I'm coming up blank.
There are more than one scenarios under which this can occur:
1) bandwith issues : as italo.nascimento mentioned, a slow connection, where your HTML is downloaded but your CSS is timed-out so you're left with a naked HTML page (happens often also when a website is under DoS or has many many visitors and the server can't keep up with the traffic)
2) caching problems : something is changed in your HTML, but the CSS is served from the browser's local cache so the selectors don't match...
3) FOUC : It's not really similar to what you're asking, unless the printscreens were made during the page load.. It's called Flash of Unstyled Content.
In general 90% of these kinds of problems are cause by connection issues. Dropped packets, TimeOuts, CDN's not working properly.. And as they are random I don't think you can "reproduce them" - it's not something that can get fixed.
Happened to me lots of times in major sites.
Mostly, it happens when Internet connection is very slow or oscilating, so the files doesn't load correctly from the server (packages get lost) and the site is showed in pure HTML. Maybe you could reproduce it by limiting your bandwidth and reloading the page.
Our web application renders fast in some IE browsers, slow in others... It seems to be an HTML rendering problem... The first 10% of the page displays immediately, the last 90% takes up to 10 seconds, and this is static content. I've run with firefox/yslow, renders very quickly. Seems to be isolated to some users/configurations of ie. Quirks mode does not seem to make a difference.
Is there a tool or application that I can use to help me discover a rendering bottleneck? Am I doing something egregious in my code? Could it be a javascript issue? Any help or suggestions will be much appreciated. thanks.
Use Fiddler to look at the times to load images, css, js files, etc. In other words, is caching a problem? Javascript can definitely cause issues in different browser versions. There's lots of optimizations you find in some versions that aren't in others. Also, make sure your html is well-formed xhtml if possible. How the page is arranged can also affect life. If your document tree is deep, it may need to wait to render large sections until it reads all the child nodes. Another thing to note, certain toolbars and plugins do look ahead loading and can slow down life. An HTTP Proxy can help you watch what's going on network-wise at least.
Not sure if anything of those ideas might help your exact problem, but they can help life overall.
If it runs fast in FF or Chrome then it's a javascript issue for sure. IE7 is VERY slow in processing large amounts of script and complicated HTML. We had a sharepoint page that took 10 seconds to render in IE and sub 1 second in FF and Chrome. We benchmarked the page by adding a timer to the server-side processing and sending the output to the client via a Response.Write(). By doing this we could determine the server time to process the page and the client time to render the page (since you would see the timer results on the screen and then wait 10 seconds for the rest to render). The bottleneck was 100% IE on the client. This also explained why the speed was variable on different peoples machines, because depending on how fast the client machine was the page would render at some speed between 8-15 seconds.
We even had MS look at the issue and they confirmed that IE has a "rich rendering" engine which is slower.... IE8 runs much faster but that is no help to anyone today.
Are you using any behaviors in your CSS? I've seen behaviors bring an app to its knees if too many are used and/or if they affect too many elements. Check for any .htc files lurking around.
Of course behaviors only pertain to IE and they use JavaScript, so I'm sure different IE versions handle them more competently than others.
There is a special tool for such scenarios called dynaTrace which is available for free at this website:
http://ajax.dynatrace.com/pages/
This tool could really help you out because its tracking almost everything and its specially build for IEs.
Check for memory leakage in the script.
http://www.javascriptkit.com/javatutors/closuresleak/index.shtml
Steve Souders gives an excellent presentation on 14 (simple) steps to improve the performance of your web pages:
http://developer.yahoo.net/blogs/theater/archives/2007/08/steve_souders_high_performance.html
If it's hanging in the middle of the page, the first thing I would personally look to do is ensure or move all my JavaScript is at the bottom of the page.
IE is great at being a bad performer, particularly with JavaScript, so if you move it to the bottom, IE can render the page, then get on with processing the JavaScript.
I use HttpWatch for troubleshooting linked assets (images, script, css), network or HTTP related problems in IE. There's a free & paid version. Free is fine but you lose out on some nice features.
While browsing with Chrome, I noticed that it responds extremely fast (in comparison with IE and Firefox on my laptop) in terms of rendering pages, including JavaScript heavy sites like gmail.
This is what googlebook on Chrome has to say
tabs are hosted in process rather than thread.
compile javascript using V8 engine as opposed to interpreting.
Introduce new virtual machine to support javascript heavy apps
introduce "hidden class transitions" and apply dynamic optimization to speed up things.
Replace inefficient "Conservative garbage colllection" scheme with more precise garbage collection scheme.
Introduce their own task scheduler and memory manager to manage the browser environment.
All this sounds so familiar, and Microsoft has been doing such things for long time.. Windows os, C++, C# etc compilers, CLR, and so on.
So why isn't Microsoft or any other browser vendor taking Chrome's approach? Is there a flaw in Chrome's approach? If not, is the rest of browser vendor community caught unaware with Google's approach?
Chrome's approach is difficult to write, and requires forethought from the developers. IE and Firefox are both attempting to move to a process-per-tab model, but due to backwards compatibility are not able to transition quickly. Chrome, being an entirely new browser build on a clean rendering engine (WebKit), was easier to write in this way.
They have crossed over from a web browser as a tool to view web pages, to a tool optimized to work for web applications. There may be some flaws in this initial release, but they are changing the game.
IE8 uses a similar individual process per tab module, though they do not use a single process per tab, but instead spread all tabs across a process pool.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
Thats actually a WebKit feature, Chrome just inherited it.
Virtually all of these features existed in other browsers before Chrome. IE8 had process isolation for tabs. Firefox / Safari had most of the JavaScript stuff. Most browsers do their own memory management.
Chrome has a few unique features (hyperrestricted render processes, etc) which are difficult to put into other browsers due to add-on/application compatibility concerns.
The primary thing Chrome has going for it is an extremely hardcore focus on minimalism and high-performance. By focusing on these as their competitive advantages, they can appeal to users who find this area of focus compelling.
As time passes, I'm sure you will see the homogenization of features as the browsers attempt to one-up each other.
In the meanwhile, I still stick with Firefox over Chrome for the simple reason that Firefox is (i) non-profit and has a (ii) huge addon community.
Addons such as NoScript and AdBlockPlus are almost essential for me.
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
Yeah. I mentioned this on uservoice and got declined because the current size is evidently the default under webkit. Every other site I've tried with Chrome that uses textboxes to compose content manages to have a decent sized font. The default definitely doesn't work, but there's obviously some way to override it. Jeff needs to fix this!
Edit:
Jeff was nice enough to point out how to fix this problem yourself.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
I also wanted to point out that Google completely built Chrome from the ground up, with the exception of using webkit, so they have some of the advantages of not having to not deal with old-code. And of course there is the INSANLELY cool/smart developers.
The biggest chink I've found is its lousy proxy support compared to IE, FF and Opera. So it's pretty much useless at work, render pages at random, and requesting authentication for the proxy, where the others pass it seamlessly.
That said on my home machine it works great, if it wasn't for the OTT EULA I'd use it now.
thing2k
One "flaw" about Chrome is that it uses more memory upfront than all of the other browsers. I'm just guessing that this is due to the overhead associated with all the separate tab management.
After it's been open for some time, however, it doesn't use more memory than other browsers.
Many companies play a game of "What's the least we can do to get the leg up?" Marketing creates a laundry list of features needed to be better than the competitors. Project management ensures engineers stick to those features for fear that the project will exceed the time allocated... which of course it will. There's not a whole lot of room in such a system for a big picture leap-ahead. The incremental improvements you see in products, and browsers, is a consequence.
You have to keep in mind that Microsoft primary business is Rich environement (GUI) Application. Web tool is a threat to them as it is platform independant (not promoting they main product).
Of course the IE team probably had figured something like that but... Microsoft definetly won't invest a lot of money in IE if what they are selling is a Rich application platform.