PEP skipping second pointerdown event after mouseover event on Chrome

[rj33]

There was a previous bug filed against this bheaviour here:
#279

But it was closed with a potential fix. Unfortunately I don't think the fix handles all the cases under which this can occur.

Specifically, I'm still seeing the problem with code checked out from master, and it looks like
the issue in my case is related to mouseover inserting entries in the pointer map on Chrome latest ( 52.0.2743.116 Mac OS X - May be Mac specific).

From the mousedown code:

   mousedown: function(inEvent) {
      if (!this.isEventSimulatedFromTouch(inEvent)) {
        var p = pointermap.get(this.POINTER_ID);
        var e = this.prepareEvent(inEvent);
        if (!HAS_BUTTONS) {
          e.buttons = BUTTON_TO_BUTTONS[e.button];
          if (p) { e.buttons |= p.buttons; }
          inEvent.buttons = e.buttons;
        }
          pointermap.set(this.POINTER_ID, inEvent);

          if (!p || p.buttons === 0) {
          dispatcher.down(e);
        } else {
          dispatcher.move(e);
        }
      }

 mouseover: function(inEvent) {
      if (!this.isEventSimulatedFromTouch(inEvent)) {
        var e = this.prepareEvent(inEvent);
        if (!HAS_BUTTONS) { this.prepareButtonsForMove(e, inEvent); }
        e.button = -1;
        pointermap.set(this.POINTER_ID, inEvent);
        dispatcher.enterOver(e);
      }
    }

So what happens in my case is that after receiving a pointerdown/pointerup combination on a DOM element, I add a new UI element right under the mouse pointer (basically at the poinerup location - the pointerdown/pointerup sequence is triggering a menu display). This then triggers a 'mouseover' event, which PEP's mouse over handler inserts into the pointermap. Normally this would be ok, because of the p.buttons === 0 check in the mousedown code that allows mousedown's to trigger pointerdown with an existing pointermap entry with no buttons held. However in this case, Chrome is generating a mouseover event with e.buttons = 1.

This is despite the fact that the last event processed was mouseup so buttons should now be 0. I suspect Chrome is generating the mouseover event inside the mouseup handler which displays the new element, and so still thinks buttons =1 from the state previous to mouseup, even though the mouseover event is processed (at least in PEP) AFTER the mouseup event.

I don' really understand the event semantics enough to know if this is a bug in PEP or Chrome. I'm guessing it is a Chrome bug, but given the polyfill's job is to provide the correct event firing despite browser differences, I figured it is probably worth filing as a bug here.

For now, I'm working around this in my code by hacking the PEP mousedown/mouseover to explicitly mark the pointermap entry as being derived from a mouseover, and then allowing mouseover pointermap entries to trigger pointerdown , even if buttons > 0. I would imagine there are side effects to this for some cases that matter to others, so it doesn't provide a long term solution, but it works in my use case.

Note that this doesn't happen on at least Firefox, which further suggests that the buttons = 1 for mouseover after mouseup behaviour of Chrome in this case is probably a Chrome bug.

[bethge]

That very much sounds like the mouseover comes out of nowhere. When I worked on fixing #279 I did not think of this scenario tbh.

Could you by chance create a simplified demo of the behaviour? I tried to whip something up but the mouseover wouldn't occur.

[rj33]

I'll have a look at creating a standalone demo tomorrow. Is there a convenient external link point for the development version of the library? The only externally linkable version built from master I have right now has my hacky workaround in place, so will not exhibit the problem.

I also just noticed this issue:
#200

And while that report seemed to be touch specific, which isn't relevant to my case, the item I am revealing after the mouse up, that is triggering the mouseover with buttons=1 does involve CSS transform, so I wonder if Chrome generally has some strange timing interactions between rendering with transforms and event processing.

I'm also not sure if it is relevant, but I have separate 'over' listeners at the document level to handle page wide tooltips, so that might also change how things get processed by Chrome.

[scottgonzalez]

ping @RByers

[RByers]

I'd agree that it's a Chrome bug to ever dispatch a mouseover with buttons=1 after the mouseup event has been dispatched. Looking at the code in blink I don't see how this could be possible. If you can provide a repro (ideally a stand-alone repro not involving PEP, but if that proves difficult we can probably still debug one involving PEP), then I can get someone to take a look.

[rj33]

Sorry, I've done some more testing, and there was an inaccuracy in my original report.

The mouseover is not getting fired after the mouseup, but rather before the mousedown.

The trigger conditions seem a bit complicated, because it doesn't happen every time, but I can fairly reliably reproduce the problem without PEP here by clicking on the open/close on the goey menu:
http://codepen.io/rj33/pen/PzrQkd

Initially I get output like this (first number is e.buttons, second is a counter of number of events) as I toggle the 'goey' menu open and closed:
mousedown: 1 40
mouseup: 0 41
mousedown: 1 42
mouseup: 0 43

However if I reposition the mouse so that it is directly over the drawn elements of the hamburger/close button after a few initial clicks, the behaviour changes to this:
mouseover: 1 51
mousedown: 1 52
mouseup: 0 53

It keeps cycle through this sequence even though I am not moving the mouse. This appears to be the sequence I am seeing in PEP where the mouse down is ignored due to the mouseover
firing with buttons=1 just before the mouse down (so PEP assumes this is a mouse move), and dispatches a move event instead of a down event.

The codepen code isn't exactly the same as my code, as it is triggering the transformations with CSS only, whereas my code is using mouse/pointer events to trigger the transformations, but the principal of mouseover preventing mousedown firing a down event due to the buttons!=0 case seems to be the same. I also don't use the 'goey' svg transformation, and only animate the springing out of the menu items, so I don't think that is relevant either. Sorry this example isn't as simple as it could be, I tried a simpler example with scale transforms, and had trouble reproducing the problem (it is still not 100% reliable, as it can take a few attempts to get the mouseover:1 firing reliably).

I'm running this on Mac OS X 10.9.5, just in case the older Mac OS version is relevant.

let me know if you need more clarification.

[patrickhlauke]

PEP has now entered emeritus status at the OpenJS Foundation. This repository is now archived.