See commented out test case in accessible/tests/browser/e10s/browser_caching_text_bounds.js :)

// XXX: There's a fuzziness here of about 8 pixels, implying we aren't taking into
// account some kind of margin or padding.
// /**
//  * Test character bounds in an intervening inline element with margins
//  * and with non-br line breaks
//  */
// addAccessibleTask(
//   `
//   <style>
//     @font-face {
//       font-family: Ahem;
//       src: url(${CURRENT_CONTENT_DIR}e10s/fonts/Ahem.sjs);
//     }
//   </style>
//   <div>hello<pre id="t" style="margin-left:100px;margin-top:30px;background-color:blue;">XX
// XXX
// XX
// X</pre></div>`,
//   async function(browser, docAcc) {
//     await testChar(docAcc, browser, "t", 0);
//     await testChar(docAcc, browser, "t", 3);
//     await testChar(docAcc, browser, "t", 7);
//     await testChar(docAcc, browser, "t", 10);
//   },
//   {
//     chrome: true,
//     topLevel: !isWinNoCache,
//     iframe: !isWinNoCache,
//   }
// );

Are we certain this isn't a weird bug in the test harness (rather than the C++ code)? This fails even when running in the parent process (chrome: true with all others false). I guess it's possible we have exactly the same bug in both local and remote, but it's unlikely.

Could this be because of this?

  // test against parent-relative coords, because getBoundingClientRect
  // is relative to the document, not the screen. this won't work on nested
  // elements (ie. any hypertext whose parent is not the doc).

The HyperText's parent is not the doc in this case because of the <pre>.

https://hg.mozilla.org/mozilla-central/rev/e9b60154557d