(In reply to Kartikaya Gupta (email:email@example.com) from comment #6)
(In reply to Henri Sivonen (:hsivonen) from comment #2)
Option #1 is the closest to the plan, but when writing the plan, I mistakenly thought that event coordinates were already floats.
Note that currently when we do a hit-test on the main thread across a transform, we should be maintaining precision to the nearest app unit - see code here. So if instead start rounding to nearest LayoutDevice pixel that will probably be a regression of sorts. Not sure if it will be user-detectable but I'm guessing yes.
Even though the type currently says LayoutDevicePixel, the rounding would be to integer in the coordinate space of the out-of-process iframe. I assume that if the iframe has a scale transform applied to it, the integer rounding wouldn't actually correspond to rounding to device pixel precision.
But I really don't know properly how the top-level coordinate space of an out-of-process iframe works at present.
(In reply to Henri Sivonen (:hsivonen) from comment #3)
Furthermore, it seems that only mRefPoint of the event is translated to the content process coordinate space in e10s and mLastRefPoint is never translated. It looks like mLastRefPoint is only used for DOM movementX/movementY values, which appear to be in screen space scaled to CSS pixels. Superficially, it looks like movementX/movementY are computed in the content process, yet only one input to the computation (mRefPoint) is translated. smaug, what mechanism makes the movementX/movementY correct when mRefPoint is translated to the content process coordinate space but mLastRefPoint is not?
It looks like the mLastRefPoint is updated in EventStateManager from the mRefPoint value. Presumably this happens in both the UI process and the content process. When it happens in the content process, the mRefPoint value being used is the translated one, so mLastRefPoint will also be in the translated coordinate space.
Thanks. Clearing ni for smaug.
(In reply to Ryan Hunt [:rhunt] from comment #7)
Yeah this code is pretty broken with oop-iframe's.
I just did some light reading through the code, not an expert on all the requirements. I agree that (1) seems like a good option for standing things up, but I'd also be concerned about precision.
I've got to go away for a bit, so I'll keep the ni? and try and think more about it.
Thanks. I'll proceed with option 1.