Hello,
In one of our apps, we listen for the eventmouseover and eventmouseout events to display and close some custom popovers. Since we don't want these to instantly open up, we debounce the eventmouseover event. Of course, we have some filtering logic to isolate specific events. We've noticed that sometimes these hover popovers do not show up.
After a bit of debugging, we've ended up with the conclusion that these event objects mutate. This is pretty obvious when you also debounce the eventmouseover event.
We've managed to reproduce this in the Bryntum Scheduler examples.
We've used the big data set demo: https://bryntum.com/products/scheduler/examples/bigdataset/
At the end of the demo code, please add the following lines:
scheduler.on('eventmouseover', (event) => console.log('eventmouseover -> ', { ...event }));
scheduler.on('eventmouseover', (event) => setTimeout(() => console.log('timed out eventmouseover -> ', event), 500));
scheduler.on('eventmouseout', (event) => console.log('eventmouseout-> ', { ...event }));
scheduler.on('eventmouseout', (event) => setTimeout(() => console.log('timed out eventmouseout-> ', event), 500));In order to reproduce the issue, you'll need to hover the events in the scheduler. Sometimes, you will be able to see in the console that the event object that's instantly printed is the eventmouseout event. However, if you check the event object that's linked to the same event and printed after 500 milliseconds, you can see that it's actually a schedulemouseenter event. This is really weird because we're explicitly listening for eventmouseover events.
Notice that we're using spread when instantly printing the event in the console. That's because sometimes it seems that the event mutates even before that.
The eventmouseout event doesn't seem to be plagued by the same issue.
This is really frustrating because if we have stacked events and resource time ranges, it feels like it's even worse. It takes multiple hover tries for the users to get to see the popovers.
Kind regards,
Armand
