Luke,
Jenny wrote, "... Just to clarify, simulate event bugs should be filed under YUI Test for now."
If you agree, please move this ticket.

Nicholas,

Feel free to assign this back to me if you don't have time to take care of it.

pageX and pageY were only added to IE as of IE9. The DOM events interface doesn't provide initialization for pageX/pageY either (I believe they're calculated internally rather than set).

So, seems like perhaps the right thing to do is to allow pageX/pageY but not for IE < 9. I want to make sure event simulation is actually doing the same thing as the real browser, otherwise the tests using it won't behave correctly.

Does that make sense?

Many of my Dial unit tests are using simulate(mousedown, {clientX: ..., clientY:...}).
The method in Dial.js that received this event was getting valid values for e.pageX and e.pageY. When run in *IE6*, FF, Chrome, Safari
but when run in IE9, e.pageX and e.pageY were always == 0.

Maybe this doesn't block me. Now I'm changing the receiving method to use clientX and clientY instead of pageX and pageY.

I no longer need e.pageX and e.pageY support in Simulate.

Accepting this, but it may fall out of 3.5.0, since you have a workaround. If you're reading this and aren't Jeff, but are blocked by this, please chime in and I'll readdress the priority.

Bug scrub. Moving to 3.NEXT with the intention to pull into 3.6.0. 3.5.0 is all DataTable for me, so I can't afford the split bandwidth.

Just reviewing this bug in light of the functional example tests we're adding ...

Jeff : I don't think we should be updating development-side code to handle this (it's probably fine as a short term workaround - we shouldn't make a habit of it). pageX, pageY is what we normally work with, when listening for events (on developement side), since most of our positioning logic, and utils, are page co-ordinate based (that is, we're complicating the implementation code, to work around the simulate issue).

To Nicholas' point : I think it's reasonable to populate the event payload with a calculated pageX, pageY for IE9. This implicitly happens for IE6/7/8 already on the listener side of things (so for example in IE 7 Jeff's repro example works fine).

It's fundamentally a bug in IE9, where they've added support for pageX/pageY in general, but forgot to tie in the dispatchEvent layer. People coding pageX/Y based assertions on the other side of this code will otherwise all have the same if (IE9) {} else {}, if we don't normalize it for them.

I imagine (haven't looked at the code yet) what's going on is that for IE6/7/8 even though the simulated event doesn't create a Event object with pageX/pageY, we create these properties on the listener side. However for IE9, since it says it supports pageX/pageY (but doesn't support them properly) we don't bother creating/normalizing the properties.

We can either try normalizing it on the simulation side (between initMouseEvent and dispatchEvent, if that works) or on the listener facade normalization side of things if we can identify this facade coming from a dispatchEvent call (by sticking something on it during dispatch).

The prior solution would be preferred, again, so we're not modifying development side code for simulation, however it does mean that for tests not using the YUI event listener normalization they would suddenly start to see the correct pageX, pageY (Nicholas' point) which seems fine IMO. We're fixing what appears to be an IE9 bug which is what we do.

[ no idea why the owner changed, changing to me ]

Looked into this. Setting pageX, pageY on the event object before dispatchEvent still results in the values being over-ridden to 0 by the time it gets to the listener.

So, looks like we're left with setting a flag during dispatchEvent, and reacting to it in the YUI DOM event facade creating code ...

e.initMouseEvent(...);
e._fixSimulatedPageXY = (Y.UA.ie === 9); // or feature test [ listen for mousedown, simulate mousedown, test ]
target.dispatchEvent(e);

In event-dom-facade:

if (e._fixSimulatedPageXY && (e.pageX == e.pageY == 0)) {
this.pageX = this.clientX + doc.get("scrollLeft");
this.pageY = this.clientX + doc.get("scrollTop");
}

Will dig into some more post 3.6.0. Too late to mess with this level of code in 3.6.0.

Moving from 3.NEXT to BACKLOG.

NOTE: I'm not entirely convinced it's worth adding the code (cruft?) I mentioned above to event core, to fix this (if it could be contained purely on the event-simulate side of the fence, then I wouldn't have any doubts). If there's consensus on this, then it may just need to be a known issue, especially if it's fixed in IE10.