IE11 CSS Translate3d shifts DOM element event - javascript

This issue only occurs in IE11 on Hybrid devices like Surface Pro 3!
I have a function that creates an Open and Close menu, which moves a DIV to the right and/or left.
The DIV contains elements with binded events, but when the elements move there is almost a shadow element of the previous position that remains active with the binded events attached to it?
If I click on that shadow then IE repositions the events on the right elements, as illustrated in the below picture.
Any ideas?

The problem was due to using animation, CSS translate3d.
I've changed it to translate and it works fine now.

Related

Click event not fired in floating button if over an element scrolling

When having a button (or any other element, positioned absolute or fixed) on top of an element with a scrolling area which is actively scrolling (i.e. for example it's decelerating) it seems that the button doesn't receive the click event when clicked.
It seems that when clicking (or touching) the scrollable element area, the scrolling is interrupted, but the button on top of it doesn't receive any event.
I've debugged events for the floating element in Chrome and the only thing received is a mousewheel event.
This is particularly annoying if the button is a navigation button, as you have to click twice to exit the page if the content is decelerating (as opposed to once when the content is still).
I browsed many times for a solution but never found a clue about this behaviour and how to avoid it, so any thoughts will be appreciated.
Sample code here: https://codepen.io/djibarian/pen/bGLoYxY
If you scroll the red box and while still scrolling due to inertia try to click the button, you only manage to stop the scrolling in the box, but the button doesn't receive the click event.
I haven't seen your code, but it's worth checking following.
Check if any element overlaps the positioned fixed element.
Make sure the stacking context of the element is correct.
Try adding a higher z-index and see if it's working. If it works then it's worth changing the dom element order for precedence.

Get mouse coordinates when the mouse is over a disabled element?

When using a global mousemove event attached to the window object, the mouse coordinates are not available when the mouse moves over a disabled element. Disabled elements do not fire any events, presenting a problem.
Part of my application includes a free-transform tool which allows elements to be rotated, scaled, resized and dragged around the viewport (drag & drop). The flow of my app is broken if the mouse is moved over a disabled element while freely transforming an object, because suddenly the mouse coordinates are not available to my objects until the mouse leaves the element, giving a choppy / laggy feel and a poor user experience.
I've tried the readonly attribute instead. However, this is not a viable solution as it is only supported by two elements (input and textarea) source: https://www.w3.org/TR/html4/interact/forms.html#h-17.12 and has different behaviour.
Here's a Fiddle showing the choppy / laggy behaviour: https://jsfiddle.net/rmw9anLs/2/
I understand the element itself doesn't fire any events, but I'm not attaching any events to the disabled element. I would expect the window.mousemove event to fire regardless and don't understand why a disabled element on the page would interrupt a global event listener.
Aside from implementing a custom disabled feature using JavaScript, is there a way to get the mouse coordinates without having to account for the mouse being on top of disabled elements?
You cannot, hence the disabled attribute has no effect, other than making your HTML invalid.
To stop the mouse event working, attach an event handler to the element using event.preventDefault() on it, check for a data-disabled attribute on the element in your existing click handlers or use pointer-events: none in a CSS class which you toggle on/off as needed. Also be aware that pointer-events is not well supported in IE <11
E.g:
https://jsfiddle.net/x4nLu0a5/

Android 4.0 browser overflow: scroll and touch/click events

I've run into a really annoying problem with the stock Android 4.0 browser. I have a div with overflow: scroll, and elements within which scroll horizontally if they exceed the length of the div. The scrolling works fine, but for some reason (only in the Android browser), click/touch events attached to the elements within the div do not get triggered at all, unless you hold your finger on the element and let go EXACTLY at the point in which the highlighting disappears. Just wondering if anybody has encountered this problem and/or has any idea of how to fix it. Thanks.
So the bug seems to only occur when the element bound to a click/tap event within the scrolling container is an anchor (even without href attribute). If it's any other type of element, it works fine.

Javascript IE mouse events restricted to original recipient?

I have an info overlay that works great in Chrome and FF. It is a div containing a table (for border image layout) and then a central content div. I trigger mousedown on the appropriate border table cells.
Once this happens, a different div is brought to the front with z-index, and that passes along the mousemove and mouseup events to handle dragging the info bubble around. Once the mouseup is fired, the info bubble puts the "event" div back to where it was.
I also follow the same process for dragging the lower right corner of the bubble to resize it. Again, works in Chrome and FF, but fails in IE.
IE seems to be restricting the event triggers to the info div. If the mouse manages to move outside the div (from dragging faster then the events fire/update), the info overlay no longer receives mousemove events. However, if I move the mouse back over the overlay (without releasing the button) it continues to receive mouse events.
Edit: In creating some example code (the current functionality is split across several JS modules), it worked in IE. As soon as I find the difference between my example code and the actual code, I will update again.
Edit/Answer: (SO wont let a new user answer their own question in this time span...)
Still not sure what the actual problem was. (If you ask me, a div with a z-index of 100 should be receiving mouse events just fine?)
My solution was to fix my mouse event handling such that I could attach my mousemove and mouseup to the parent div (as should have been done in the first place) for all dragging/resizing behaviors I wanted to set up.
The problem was due to a newbie approach to the events and having stopPropagation() in too many locations preventing me from taking such an approach. (I wanted text, etc in my info box to be selectable).
I adjusted the code so that my text containers only had to stop propagation on mousedown instead of all the mouse events.

IE 8 specifying background-color changes element behavior

I have an absolutely positioned div on which I am trying to trigger mouseenter and mouseleave events. In IE8/7 with the background-color of the div left unspecified (so that it defaults to transparent), the mouseenter/leave events are not firing when the cursor crosses the div's boundary, only somewhere in the middle of the div and when the cursor is over any text within the div.
When I attempt to debug the problem by adding a background color to the div (e.g. background-color: green), the problem magically goes away. The div's box model is honored perfectly and mouseenter/leave fire as when expected. It's only when the div's background color is left unspecified (or even explicitly set to transparent) that it doesn't behave correctly.
Any ideas? Googling for this IE bug/quirk is coming up with nothing.
The mouseenter and mouseleave are not registering until the cursor hits something visible. This is not correct behavior, but this is Explorer we're dealing with.
Two possible solutions:
Put a thin border on the DIV, one that matches whatever is behind it and won't be noticed. (This doesn't work; see the comments.)
Track mousemove events and have your code determine when the mouse has entered the area of interest.
(Added; see the comments.) Make your background a tiled transparent 1x1 image.
Both solutions are pretty much yuck, unfortunately.
Edit: Question: Do mouseover and mouseout show the same weird behavior?
To add to this: onclick fires as well when using Solution 3, in the answer above. It's overall a nice workaround for grabbing clicks on transparent elements over non-transparent ones in IE.

Categories