[09:45:15] <pep-commit> [PEP] scottgonzalez tagged 0.4.0 at 4f8c567: http://git.io/v8JC7
[09:45:15] <pep-commit> PEP/0.4.0 4f8c567 Scott González: 0.4.0
[09:46:44] <pep-commit> [PEP] scottgonzalez pushed 1 new commit to master: http://git.io/v8Jlt
[09:46:44] <pep-commit> PEP/master a3d8aef Scott González: Build: Updating the master version to 0.4.1-pre.
[10:39:47] <pep-commit> [PEP] scottgonzalez pushed 1 new commit to gh-pages: http://git.io/v8JFI
[10:39:47] <pep-commit> PEP/gh-pages 9c2b213 Scott González: Upgrade to 0.4.0
[12:41:05] <scott_gonzalez> M4rius: Looking at that PR, the `assert_unreached()` is verifying that we're never getting an event where the hit test is different than the event target, right?
[12:41:29] <scott_gonzalez> Shouldn't we be checking that they ARE different at some point, but the event target is still locked on the captured element?
[13:15:55] <scott_gonzalez> ?pepteam
[13:15:55] <b-ot> arschmitz jdalton jrossi jrossi1 jrossi2 jrossi3 jrossi9billion M4rius scott_gonzalez snover
[13:15:59] <scott_gonzalez> Blog post preview: http://blog.jquery.com/?p=3897&preview=1&_ppp=f5d0712e1f
[13:16:06] <scott_gonzalez> Thoughts before I publish?
[14:01:08] <M4rius> scott_gonzalez: Maybe I got it all wrong - I thought of it this way: Our issue is that `pointerover`-events occur, which are attributed to the black box, but actually the mouse cursor was somewhere else. In PEP we redirect these non-black-box-events to the black box, though they should not occur at all. Only `pointermove` and `pointerup` should be redirected.
[14:04:12] <M4rius> One could argue that every kind of pointerevent would need to be checked for whether the cursor is actually at the proper position to trigger a that particular pointervent
[14:05:22] <M4rius> Wait, now I understand your point.
[14:05:27] <M4rius> I think.
[14:08:34] <M4rius> Yet, would that pointerevent actually occur in the first place? I.e. during a capture no pointerover takes place, except for those happening to the capture-target.
[14:17:02] <scott_gonzalez> Yeah, so there's a few things at play here.
[14:17:32] <scott_gonzalez> One is that when you move out of the capturing element, the hit test should not match the event target for the pointermove events.
[14:18:02] <scott_gonzalez> But there's also the boundary events which should only occur if the boundaries are for the capturing element.
[14:18:38] <arschmitz> scott_gonzalez: that sounds good to me
[14:18:57] <scott_gonzalez> So I think the case you wanted to test is element A is set to capture the events. When moving from A to B, you get pointerout, when moving from B to C, you get nothing.
[14:19:17] <M4rius> scott_gonzalez: right
[14:19:18] <scott_gonzalez> So I guess the way to test that is you need an assertion that checks that we get a hit test that results in C.
[14:19:32] <scott_gonzalez> And make sure we don't get over/out events when that happens.
[14:19:40] <scott_gonzalez> Which is a bit trickier to track.
[14:19:56] <scott_gonzalez> I guess you can just check the total number of over/out events that get fired.
[14:20:05] <scott_gonzalez> And the test would fail if the count is > 1.
[14:20:46] <M4rius> scott_gonzalez: that sounds good
[14:20:57] <M4rius> pointerout is easier to track than pointerover
[14:21:18] <scott_gonzalez> yeah
[14:21:48] <M4rius> Just so I get I right, would the current test, work too, or what am I missing that would not work?
[14:23:56] <scott_gonzalez> So the problem with the current test is that it can only tell you if you hit an error condition.
[14:24:10] <scott_gonzalez> It can't tell you if you've properly implemented the boundary event suppression.
[14:25:05] <scott_gonzalez> So you would be able to make this test pass with the current PEP implementation, right?
[14:25:20] <scott_gonzalez> Oh, I guess not.
[14:25:33] <scott_gonzalez> Because you have to leave the element in the first place.
[14:26:26] <M4rius> Sorry?
[14:27:23] <scott_gonzalez> So in order to get to this point of the test, you must have moved the pointer out of the element and then back in.
[14:27:30] <scott_gonzalez> So you'd normally get two over events.
[14:27:43] <scott_gonzalez> And the one on the original element would be the latter of the two.
[14:28:08] <scott_gonzalez> So I think this is actually fine as is, since there's another assertion requiring pointerover to have fired at least once.
[14:29:05] <scott_gonzalez> Sorry for the confusion. I needed more context than the diff showed to figure out that this was actually correct.
[14:29:59] <M4rius> Backing up a little, currently PEP would break on the added test. With https://github.com/jquery/PEP/pull/195 afaik it would work
[14:30:34] <scott_gonzalez> Yeah, after thinking through the whole test, I realized it would fail.
[14:30:37] <scott_gonzalez> So this is good.
[14:31:51] <M4rius> ok cool :)
[15:36:53] <pep-commit> [PEP] csuwildcat opened issue #241: Events fail to fire in Chrome when using a laptop touchscreen http://git.io/v8klC
[20:06:19] <pep-commit> [PEP] scottgonzalez closed issue #241: Events fail to fire in Chrome when using a laptop touchscreen http://git.io/v8klC