I have a strange problem on a small page I made.
When the content extends the height of the browser and I scroll down fast, the pixelated box appears for a split of a second and then goes away.
Why is this happening and how can I fix this?
Seems to be a chrome issue. I'm noticing this on a lot of websites since I moved from Firefox to Chrome.
This is just Chrome's rendering engine being crap. For the supposed "fastest browser", it fails to render part of the page when scrolling consistently often.
That said, there are some factors involved in when it happens. Generally, it can occur when there's a lot of layout recalculation. This may happen if you have a large table with images loading in, as each image's load causes the table to recalculate. Additionally, JavaScript can often cause recalculation in the layout. And it all depends on how powerful your computer is and how busy it is with other tasks.
Related
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
I'm currently fighting a very frustrating bug on Safari, and I'm not sure where else to turn.
It seems most elements (but not all, and I can't discern the differentiating factor) that will trigger a focus event will cause all elements on the page that are transitioned or animated to jump ~2px to the top and left. And this only occurs on the first focus event after the page loads.
It's a little annoying to see the bug, as it's in the logged-in portion of droplr.com, and I have been completely unable to distill down a simpler case on JSFiddle.
If you have/create an account and log-in, click on this edit icon for a drop:
You'll see that on the first focus of the page, things jitter. Here's the timeline when there's a single drop on the page and I trigger focus on an offending element:
With more drops, it's just more of the same, but it seems to max out around 40 paints. And the profiler doesn't suggest anything nefarious. Just a trip through jQuery internals.
If instead of laying elements out via a translate3d or matix3d, I simply use top and left, this bug goes away. After hours and hours of debugging this, I'm at a complete loss.
Hoping someone has seen something similar, could take a look, or could give me advice on debugging next steps.
Thanks so much!
Update: Dave Desandro suggested it was the 3d acceleration kicking in, so I tried it out with a translate instead, and sure enough, that did not cause the jitter. I have no idea why the hardware acceleration would be firing up with a focus event though, and only once.
I've tried setting a transformZ of 0 on page load to go ahead and ramp-up the hardware, but no luck there, either. Any more ideas are welcomed.
I've had this issue a while back and honestly I don't remember what exactly was the cause but here are some of the steps I followed:
Check that you don't have hide() and show() for the same element in the next line or vice versa.
Example:
el.show()
el.hide()
Change Custom fonts to "Arial"
For the elements you don't want focus events add this code at the bottom of your scripts:
noFocusElem.off('focus');
This will make sure to remove any focus handlers you might have added by mistake
Finally place your css before any scripts. It's a know fact that adding css rules after an inline style has been applied may cause jitter especially if you're using line-hieght property
Hope this helps :)
I've had this happen when using custom font kits. Could this be the issue? Some events cause custom fonts to re-draw, which can cause a ever so slight "jitter" in page display.
Sometimes, manually setting heights and widths on all the parent HTML elements can reduce the flicker.
I know this question was posted a while ago and this is a bit of a long shot but here goes:
Maybe as a starting point go back to chrome and look at the composite layering:
Hit this into the address bar:
about:flags
You will be able to enable composite borders from within there. The red borders generally indicate a rendering issue:
http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
What I have found from time to time is that although there are rendering issues in Chrome the browser copes pretty well with hiding them from me. In other webkit based browsers however the result can be more noticable (i.e. android).
I've also seen flickering occur when z-indexes are being used in conjunction with content that is being transformed.
Either way it would be great to know how you resolved this issue (if you did). Post an answer to your own question perhaps?
A way to avoid spending time fixing load time twitches; you could set the page to hidden then make elements visible with the load. If your page is slow to load, you may want to have a spinner default to visible, then have load hide it. Then you could come back to the issue when you have nothing better to do.
Just my 2c worth.
The first thing I would try:
First in chrome, whack in 'about:flags' (yes I know you're not using Chrome). Find the 'Composited render layer borders' and turn it on. Once this feature is switched on you'll get a rough idea of what is being rendered/hardware accelerated.
See: http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
and look for any rendering problems. These are normally caused by z-indexes. Play around with any z-indexes and hide/show certain elements until the rendering issues are resolved. Then work from there. translate-z hacks and opacity can also cause problems.
From experience I've found rendering problems in other webkit browsers can be diagnosed using chrome. Flickering is a common occurrence on the stock android browser.
Secondly: take a look at the focus event itself and try things like preventing the default behaviour. Seems like a long shot to me but give it a go.
I haven't tested this, so I will be very surprised if it works... but here's an idea:
$(document).ready(function() {
$(document).focus(function(e) {
e.preventDefault();
});
$(document).click(function() {
$(document).unbind();
});
});
I've been running into the same issue recently and found something that fixed it in my case.
Check for anything that's hidden offscreen like:
text-indent: -9999px;
left: -9999px;
Removing any instance of these from the 3d accelerated elements (including children) stopped the content jump on focus for me.
A website I'm currently designing displays and works perfectly in all mac browsers, and Windows Firefox, Chrome and IE 8.
I'm having major problems in IE 7 though. Whilst the CSS is pretty much there (a few tweaks needed), the site is maxing out my CPU at 100% rendering the site almost unusable and giving me scripting errors and javascript functionality is not working.
I don't even know where to start trying to find out what's maxing out the CPU, or how to get more info on the scripting messages - it tells me the line the problem is on but it doesn't tell me what file.
I'd like to provide a link but the client has asked me not to.
Any help would be greatly appreciated.
Thank you
Most likely, this issue is caused by ie's poor png rendering capabilities. In the situation that I have experienced, we were using jquery ui 1.8.7 to render modal dialogs and seeing the memory usage spike by 6-8 mega every time a dialog box was opened. It turns out that the culprit was the opacity and alpha CSS settings in the default jquery styles. See this post for a possible partial fix.
Other things to note include:
There seem to be many fixes that attempt to address this issue.
Jquery 1.8.16 has a partial fix where the large memory jump will only happen when the first dialog box is opened.
We have also experimented by setting a single pixel png as the modal background and this rendering of a single pixel caused the memory used by IE to spike 80 megs and caused a temporary spike in CPU usage.
One other peculiar observation was that if we set the modal value of the jquery dialog to false and created our own modal background by appending a div whose background was set to a semi-transparent png, the memory leak seemed to be smaller.
The short of it was to stop using transparent pngs and the opacity and alpha settings foe rendering in IE.
The issue discussed in this question happened to me with a production site, but in addition to Firefox, we saw it in IE.
This is how it should look, with all three fading to different pictures intermittently:
We got these screenshots from clients:
Abmormally small images:
Weird sized images:
We were able to reproduce it reliably with Firefox with a hard refresh (ctrl-f5), but the only one in our office that could reproduce it in IE was running IE8 on Windows 7, and then not reliably. The client was using IE7, I believe on XP.
I fixed it by setting up the slideshow in $(window).load() instead of $(document).ready(), but I never figured out why it was so hard to reproduce in IE. Management is unsettled by the fact that we could not reliably reproduce it in IE or explain why it happened, and I've been asked to investigate.
Does anyone have an idea? Does the same issue discussed in the linked question apply to IE in certain circumstances? All I can say at this point is "we can't always pin down things like this."
UPDATE: I was able to make it happen reliably in IE by not setting the src attributes in the slideshows until after I set up the slideshow in Javascript. I think this proves it was indeed the same timing issue, just happening more rarely because IE is a different rendering engine. Management is still curious what other circumstances intervened, but I'm confident now that it was indeed a timing issue in all browsers, and our production site is safe from further issues.
Also, I asked the same question on jQuery forums here and was told to explicitly set image sizes in the img elements. This also fixed the issue.
It's explained in the link you posted. It's a timing issue. Sometime the cycle starts early, sometimes not. And 'sometimes' may just be 'almost never' in some browsers.
Starting the cycle in document.ready ensures that all images have been loaded before the cycle starts so the dimensions are properly detected.
It can very well depend on CPU speed, network latency, browser, OS and whatnot.
The reason it's so hard to reproduce consistently is because the environment is very complex, and the results depend on things you don't see right away.
I know this is late in the game, but I, too very recently experienced this problem. It drove me nuts. The solution is, in fact to use the $(window).load event method to start the cycle plugin--it guarantees that all associated page-load activity (including any downloads associated with ANY child elements) is complete before it fires. It works in all of the 'big five' browsers.
In my case, I am displaying images of different sizes and aspect ratios, and populating the image list automatically by using a server-side script to populate a variable containing dynamically created tags for all the image types in a designated directory that I tell it to include. Consequently, I can't include the image width and height in the tags, because I don't know what they are. In order to get around this, at the client side I use cycle's onbefore: to fire a script that dynamically looks at the image being processed and then sets the slideshow container to a width and height matching the photo's native width and height. I display a "Loading xx photos..." message with an animated GIF loader graphic so that the user knows something is going on while the images are downloaded.
The slideshow(s) in question reside in an area on the hangmanhills.org website that is restricted to Hangman Hills Residents' Association members only, so I can't show you the end product.
Hi I was wondering if there is a limit to the number of divs that are allowed on a web page?
For example will Internet Explorer start to choke when it has to render a webpage with a thousand divs?
I know this is an old post, but I recently did a test that is directly related to this topic and I wanted to share my results.
I created a simple php script that spits out x number of 5px by 5px inline-block divs to test browser stability and page scroll-ability.
At 1000 divs on the page IE9, Firefox, and Chrome have no problem whatsoever and don't even seem to hiccup when scrolling.
At 10,000 divs IE9 and Chrome are able to scroll with a barely-noticeable delay, still within the 'acceptable' range in my book, however Firefox begins to lag more noticeably, to the point where you feel the scroll bar is jumping into position a half-second later than it should.
Interestingly, the performance difference between 10,000 divs and 100,000 is not as drastic as you'd imagine. IE9 and Chrome perform with only a barely perceptible delay in scrolling (with Chrome being the slightly smoother of the two), and Firefox has a delay that is very noticeable and would probably be considered annoying, but still functions reasonably well (i.e. it doesn't crash).
Now at 500,000 divs on the page it finally started to get interesting. IE9 Crashed and tried to restart itself (on the same page, of course) and crashed again, at which point I shut it down properly, restarted it, and tried one more time to make sure the same result would happen again. It did.
Chrome remained stable, but it became nearly impossible to scroll the page due to the extreme delay.
The big surprise was Firefox, the browser that was chunky at 100,000 divs is just about the same at 500,00 divs ... scrolling is not smooth, but it is way, way better than Chrome.
Amazingly, the results were pretty much the same for 1,000,000 divs on a page! Firefox handled them without crashing and remained scrollable though 'chunky'. IE9 crashed. And Chrome was able to load the page but became so slow that it was virtually unusable.
I know this isn't exactly a scientific study, but I figured it might be interesting to someone else besides myself.
Tests were performed on a Dell workstation with Dual-Xeon processors and 4 gigs of ram, running Windows 7.
There are two things to consider. Memory is one, where DOM nodes take up a huge amount of space. The other is CPU time needed to re-render all of these nodes when something changes. The threshold of smooth rendering depends on the engine used. In my experience, IE falls far behind, starting to choke after several hundred. Firefox can take several thousand, and it's about the same (and a little better) for WebKit browsers like Chrome.