Adding or removing element attribute fires mouse event

[Adam Kalisz]

If we add or remove an attribute such as a class to an element any mouse event fires or that is the effect we observe. This is the case in Chrome and not in e.g. Firefox. The expected behaviour is that of Firefox.

Our use-case is to do animations via CSS transforms. We basically provide keyframes in CSS and the element should animate along these keyframes. This is generated and included at runtime and the CSS class always has a randomly generated UUID so they are always different and therefore distinguishable. It seems Chrome flaps on mouse events when we add or remove the class which causes these animations to be unusable.

Has anybody seen this? How can we stop this flapping?

[Mason Freed]

Hi Adam,

Thanks for reaching out! The behavior you describe sounds odd - adding attributes should not fire mouse events. Can you provide some sample code that shows the problem? Or a link to the same? Also, it would be very helpful to file a bug so that we can track this, if it turns out to be a bug. You can just link the sample code to the bug if you like, and cc mas...@chromium.org.

Thanks,

Mason

[Adam Kalisz]

Hi Mason,

I cannot reproduce this with a simple example that could help you (if
it actually showed the problem) without investing unknown amounts of
time and energy - we program everything in ClojureScript and
extracting/ translating the relevant parts would be considerable
effort.

I have tried this:

HTML:

<div onmouseover="addClass('index', 'red')"
onmouseout="removeClass('index', 'red')" id="index">
This is a test.
</div>

CSS:

.red { color: red; };

JS:

function addClass(id, className){
document.getElementById(id).classList.add(className);
console.log("Adding class" + className);
}

function removeClass(id, className){
document.getElementById(id).classList.remove(className);
console.log("Removing class" + className);
}

And the behaviour was ok as I would expect considering this is probably
quite common. In our system the class name is generated, the contained
CSS transforms as well (I though changing the color should be easier).
All is connected over ReactJS which of course could be handling Chrome
and e.g. Firefox differently.

We resorted to handling mouse completely in our app based on positions.
We then fire events based on calculations of the position and sizes of
elements, their z-height etc. This works for us since we have to do
this in other parts of our application anyway.

Thank you for your time.

Adam

[Mason Freed]

Ok, I understand. If you do eventually feel like there is a bug in Chromium around this use case, please do submit a bug. A reproduction is fairly important, but it doesn't necessarily have to be minimized. (Though minimized is certainly nicer.) Good luck!

Thanks,

Mason

[Robert Flack]

Does your site use a virtual DOM? I recall seeing an issue with some react sites where because changing an attribute meant rebuilding the DOM the old mouse target DOM node was removed and a new one added in the same place which meant that the mouse was not technically over the newly inserted element, and fired a new event on the next movement.

[Adam Kalisz]

Hi Robert,

yes, that could be it. Thanks for the heads-up. So it is perhaps a combination of React and Chrome. The element should still be the same, only the class changes, which we can observe in dev-tools. Maybe it doesn't matter and the DOM changes either way.

Handling the mouse pointer ourselves adds some overhead and we basically do some of the things the browser does again. But the physical animations we implemented using differential equations instead of simulation (yes, our solution is quite a bit faster) are a similar topic. This could be a standard implemented in CSS so everybody can benefit, instead we have to resort to a combination of JS+CSS which of course is not as efficient as it could be. The problems I describe are just the result of there being no pretty (physical) animations in CSS even though the implementation wouldn't be hard at all. ;-)

We deployed the first rather limited version with the new animations at https://orgpad.com/list

If you want to have a look. The OrgPage tiles z-height and some other things use it. It is rather rough currently because some things could be orchestrated better and the spring parameters for the animation could use more fine-tuning but we did some performance tuning and wanted our users to get the benefit of that as soon as possible.

Best wishes

Adam