Follow-up to bug 1489653. Right now, the code for calculating CSS coordinates to relative to the screen uses the target's window. The getResolution and getVisualViewportRelativeToLayoutViewport methods off the windowUtils instance will only return relevant results for the target's root content window.

This bug will ensure that we are obtaining the correct windowUtils instance when simulating tap gestures.

Some suggestions from Botond on how to solve this:

An alternative way to handle iframes that's Fission-compatible would be:

• Modify getResolution() and getVisualViewportOffsetRelativeToLayoutViewport() to return these quantities even if invoked on an iframe's >windowUtils. (Or, if some callers need the current behaviour of e.g. iframes always returning 1 getResolution(), we can add new methods like >getRootResolution()).
• Implementing these methods for OOP iframe windows will require something like bug 1518908.

Bug 1625925 will be relevant here. That bug is building a solution that uses the BrowserChild::GetChildToParentConversionMatrix() via a call to getBoxQuadsFromWindowOrigin. One of the bugs will likely be resolved as a duplicate of the other.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

(In reply to Brad Werth [:bradwerth] from comment #2)

Bug 1625925 will be relevant here. That bug is building a solution that uses the BrowserChild::GetChildToParentConversionMatrix() via a call to getBoxQuadsFromWindowOrigin. One of the bugs will likely be resolved as a duplicate of the other.

Agreed, bug 1625925 addressed this by moving the relevant calculations from touch-simulator.js into platform code.