Bug 1673140 - Wait for screen coords to be ready in browser_datetime_datepicker.js. r=handyman

As per comments in the bug I never managed to reproduce this locally or
in pernosco, but given the structure of the test (open tab, get element
position, show picker, check picker position in screen coords), it makes
some amount of sense that it could hit this race.

I'm confirming on try that this reduces or fixes the intermittent race
but given it's a oneliner I don't feel too bad sending it for review
early :)

Differential Revision: https://phabricator.services.mozilla.com/D145305

testing/specialpowers/content/SpecialPowersChild.jsm

@@ -2245,12 +2245,18 @@ class SpecialPowersChild extends JSWindowActorChild {
    * we need to wait for the updated data.
    */
   contentTransformsReceived(win) {
-    try {
-      // throw if win is not a remote browser.
-      return win.docShell.browserChild.contentTransformsReceived();
-    } catch (e) {
-      return Promise.resolve();
+    while (win) {
+      try {
+        return win.docShell.browserChild.contentTransformsReceived();
+      } catch (ex) {
+        // browserChild getter throws on non-e10s rather than returning null.
+      }
+      if (win == win.parent) {
+        break;
+      }
+      win = win.parent;
     }
+    return Promise.resolve();
   }
 }
 

toolkit/content/tests/browser/head.js

@@ -200,6 +200,11 @@ class DateTimeTestHelper {
       });
       bc = bc.browsingContext.children[0];
     }
+    await SpecialPowers.spawn(bc, [], async function() {
+      // Ensure that screen coordinates are ok.
+      await SpecialPowers.contentTransformsReceived(content);
+    });
+
     if (openMethod === "click") {
       await BrowserTestUtils.synthesizeMouseAtCenter("input", {}, bc);
     } else if (openMethod === "showPicker") {