On Fri, Jan 16, 2015 at 9:24 AM, Handyman <david...@gmail.com> wrote:
> 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). > Yeah, we don't want this. I thought, given bug 1002354, that we could quite easily use the correct screen coordinates for all PuppetWidget APIs. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
