We Keep Coding

D3 Chord Example Hover Issue in IE11

I'm working through some examples of how to construct chord diagrams in D3 from a tutorial I found at http://www.delimited.io/blog/2013/12/8/chord-diagrams-in-d3
I'm looking at the first example, about hair colour preference. When you hover over a group around the edge of the circle, it shows only the chords related to that group, and when you move the mouse outside the circle again, all the other chords reappear.
This seems to be achieved by dynamically appending the css class "fade" to all the chords that are supposed to be hidden, and then the following piece of CSS handles hiding them all on hover.
#circle:hover path.fade {
display: none;
}
This works fine in Chrome, but when I try the same page in IE11, once you have hovered over one group, the remaining chords are never redrawn when you move the mouse outside the circle.
I fired up the debugger in IE11, and it seems that simply modifying one of the properties on the DOM whilst in the debugger resolves the issue - but I'm having trouble figuring out how I can achieve this in code.
I've created a fiddle here with all the details https://jsfiddle.net/49dym52r/
Thanks for any assistance.

I am able to reproduce the issue when viewing the delimited.io resource in Internet Explorer 11 on Windows 10. I am not, however, able to reproduce the issue in Microsoft Edge, which likely means the fix came in as part of additional web platform work done on EdgeHTML after the fork from Trident.
It's unlikely that we will be doing any feature-work on Internet Explorer, so your best option is going to be persuading Internet Explorer 11 into behaving more appropriately. This can sometimes be tricky, but after a couple of minutes in Telerik's Fiddler, I was able to resolve the problem in Internet Explorer 11 on my build of Windows 10 with the following addition:
div:hover { background: auto } // Or svg:hover, per the comments below
I added this to the top of the aforementioned delimited.io resource, and it appears to have resolved the issue for me. It's a bit heavy-handed, so you may want to adjust its scope if you find it causes you any issues.

Rendering bug in Google Chrome at certain window widths

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.

SVG Blocks Touch/Mousewheel events

Is there a workaround? I am running my own custom scrollbar script as opposed to using the built in browsers functionality. I prefer to use SVG for my image elements for a number of reasons, but one, pretty major pitfall is the fact that touching or mousewheeling over an svg blocks the event and thus brings the page scrolling to a halt. This is even more noticeable on mobile browsers where the svg might take up the entire width of the document in which case as soon as you get to an SVG element, the user is unable to scroll past it.
I haven't tested in IE, but in Chrome, the touch commands dont work on top of SVG, and on Firefox, the mousewheel events are a problem. I assume it will be both on IE haha.
A decent solution would be to somehow add an event to my SVG elements the catches the events and passes them onto the scrolling events. I can't seem to find a way. An even better solution would be to somehow place the document above the SVG so the SVG doesn't interfere with the scrolling at all. Again, can't seem to find a way.
I embed my SVG elements with object tags, which is important for a variety of reasons. I'm assuming the object tag is actually the culprit.

Per Duopixel's comment. Adding:
object {
pointer-events: none;
}
To the css does solve the problem in both Firefox and Chrome. I still have to test in IE, but for now this seems the best and easiest solution.
A good article that explains the pointer events attribute can be found at http://davidwalsh.name/pointer-events
If the issues mentioned above are an issue in IE, you can use a javascript solution that requires capturing the position of the pointer and passing it to the proper element. A working version that uses jQuery but could very easily be translated into vanilla javascript can be found here: http://jsbin.com/uhuto/1/edit

Issue with mousemove in Internet Explorer

Internet explorer does not fire onmousemove events when the event target is positioned over an <img> element and lacks a background.
But it does register the event when the target has a background. Does anyone have an explanation for this? I had the same behavior in IE10, IE9, and IE8.
Fiddle here:
http://jsfiddle.net/xSpqE/2/

As OP asked for a reason, here's my breakthrough:
It's easier to explain visually, so first off let's add a click handler to the imgs:
$('img').click(function() {
$('.pageX').text('img clicked!');
});
Fiddle
Fair enough. You click the image in Chrome/Firefox/not-IE browsers and nothing will happen as the absolutely positioned div covers it.
Now try it on IE. The img's click handler is fired! Therefore it shows that IE pushes elements through absolutely positioned "transparent" (no content or background) elements. More interestingly, relatively positioned elements suffer the same issue and setting z-index on either/both elements won't solve it either. Of course, as the image is above the overlay, it won't trigger the overlay's mousemove event.
An workaround is to provide some "filling" to the overlay, say background:rgba(0,0,0,0) will force IE to keep the absolutely positioned element at the top. Fiddle. If you need to support browsers without rgba support, use a 1x1px transparent gif as background.
I've never seen this defined in any spec nor officially reported as a bug. There's no logic or reason for absolutely positioned elements without content nor background to suffer this z-index issue, hence I'll call it yet another IE bug. Maybe reporting it on the Microsoft forums would be of use.
Also, related question: IE bug: absolutely-positioned element with a non-transparent background colour

Yet another IE fail! This is more of a workaround than an answer, but it seems to work alright:
var is_ie = $.browser.msie;
if(is_ie){
$('.main img').mousemove(function(e){
$('.pageX').text('pageX: '+e.pageX);
}
}
That is in addition to the $('.overlay').mousemove function, so keep that too, and of course the is_ie check is optional.

Safari jittering/jumping (bug?) on first "focus" event of page load

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.