I think it is returning the coordinates of the toplevel window + the child iframe without accounting for any of the intervening frames.

My testing on WidgetToTopLevelWidgetTransform().TransformPoint() seems to return the extra offset that should be applied, at least in the one case I'm testing, but I'm not sure how or where it should be applied.

This is affecting drag and drop in out-of-process frames, which use GetScreenRectInAppUnits to calculate the placement of the drag feedback image, so the image appears in the wrong place.

This is also a problem for accessibility. Accessibility tools such as screen readers and magnifiers need screen coordinates for mouse routing, visual highlighting, etc. nsFrame::GetScreenRectInAppUnits is used by Accessible::BoundsInAppUnits, which is called by Accessible::Bounds, which is what gets called by OS specific accessibility code.

We probably need to audit the callers of GetScreenRectInAppUnits to determine which would want to cross OOP-iframe boundaries, and which wouldn't.

Roll some unfixed bugs from Fission Milestone M4 to M5

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Jamie, can you assign someone to look into auditing the callers of GetScreenRectInAppUnits?

(In reply to Neha Kochar [:neha] from comment #4)

Jamie, can you assign someone to look into auditing the callers of GetScreenRectInAppUnits?

I think this needs to be assigned to someone in layout. From the a11y side, I can say that our calls to GetScreenRectInAppUnits definitely need to cross OOP-iframe boundaries.

Filed new bug 1602987 for the a11y issue noted in comment 1.

Would someone mind providing an example (a mochitest would be preferable) to make sure nsIFrame::GetScreenRectInAppUnits works in OOP iframes? I can probably fix the function to work in OOP iframes, but writing automated tests in unfamiliar areas takes too much time for me. I am currently working on a similar issue for fission (bug 1599795), so my memory about coordinate system in fission world is pretty fresh now. After a while later, I definitely need to re-learn it. :)

We can't do automated tests for drag and drop, so I don't have a test for that specifically. You can test manually at https://hsivonen.fi/fission-host.html with fission enabled, then enter some text in one of the child frame textboxes and try to drag it. The drag feedback image will appear in the wrong place.

The attached is a test for the <select> element which has a similar issue with the dropdown popup appearing offset at the wrong place. I don't recall whether it uses GetScreenRectInAppUnits though, but the issue is similar.

Thank you Neil. I can start with the drag and drop case, and I will see whether the test works with the fix GetScreenRectInAppUnits in comment 9.

In this bug I am not going to just make GetScreenRectInAppUnits in fission world.

I happened to know there is an issue on SetFocus in OOP iframes (bug 1556627). The bug is (probably) the reason why Element.focus() call in the test in comment 9 doesn't work in fission. Though without the focus call the test passed on a try run, I am going to defer the test into a follow up bug.

The client offset, browser window title bar and window decorated frame width,
is necessary to get element positions in OOP iframes in screen coordinates
for drag-and-drop etc.

This change also fixes event.screen{X,Y}. A mochitest in this commit fails
without this change at least on Linux. Note that in the mochitest we have to use
nsIDOMWindowUtils.synthesizeNativeMouseClick instead of
nsIDOMWindowUtils.sendMouseEvent since sendMouseEvent doesn't work in fission
world (bug 1528935).

A mochitest for this change will be landed in bug 1550800 which needs
a work to make Element.focus() work in OOP iframes (bug 1556627).

Depends on D62190

This bug will cover wider area than we initially planned.

https://hg.mozilla.org/mozilla-central/rev/d46719614943
https://hg.mozilla.org/mozilla-central/rev/238df84a23d4