Hey all, I'm working on bug 1075670 ([e10s] event.screenX and event.screenY is wrong), which exposes a hole in the e10s architecture. Quickly, the issue is that the dom behavior in an e10s content process redefines "screen" coordinates to be relative to the tab contents instead of relative to the physical screen (actually, the tab's dimensions are considered the screen dimensions). This is probably in part because the chrome dom objects don't exist in the content process, so the ancestors of tab content are most easily ignored, but it has the unfortunate consequence that screen coordinates in the content process aren't actual screen coordinates. And sometimes, we need real screen coordinates.
This setup works in general and, in places where it doesn't, e10s seems to have been adapted to fit (for example, mouse event coordinates are specially handled by EventStateManager::GetChildProcessOffset via PBrowser, plugins use special routines in nsPluginInstanceOwner for all OOP coordinate-system calculations and the compositor... I'm not sure how it compensates but it must use a different mechanism for Compositors and CrossProcessCompositors, probably at the Layer level?). But the metaphor fails when the content process communicates with objects outside of the engine, like client JS scripts (as in the bug's test case). I have a patch in the bug that fixes the calculation for the event.screenX/screenY and window.mozInnerScreenX/mozInnerScreenY fields but it is delicate. It performs the right calculation in the content proc when the fields are fetched as JS values. Obviously, this makes it easy for someone to use the wrong value in a calculation and get garbage out. But at least we can (fairly easily) calculate the values if we know we need them. So the big picture is that we have introduced a new coordinate system in the content process (TabCoordinates) that are exactly like screen coordinates but located at a different origin. This could possibly be incorporated into UnitTransforms as a new space but that seems like a seriously heavy duty solution. Also, its not clear how to make that useful -- this setup seems to have been chosen so that parent and content processes can share formulas but this would mean that they would target different coordinate systems. On top of all that, the coordinate system framework doesn't seem to have been built for this sort of purpose -- it seems to be for tracking scaling, not general Euclidean operations (so it would be hard to take advantage of). At the other extreme, we could try to remove the TabCoordinates idea altogether. The frame hierarchy could use a placeholder frame to represent chrome objects. I don't know all of the repercussions to that call but it would be a hefty change, seriously affecting a number of components, as mentioned above. I looked for out-of-the-box solutions (like repurposing the 'justification' concept in Units to try to make it clear why the transformation was being applied or augmenting the getters to request the value in the desired coordinate frame) but I didn't come up with anything that was more than cosmetically safer. Is there a medium-scale solution to this problem or do we need one of the two nuclear options (new coord sys vs. e10s dom refactor)? And if so, which one (and how)? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
