Spun off bug 1801756 comment 30.

This is very similar to bug 1797222, but for some reason, the fix there doesn't work in this case.

STR:

1. Open this test case:
   data:text/html,<pre><code>ab%0acd
2. Get the Accessible for the single text container in the document.
3. Call CharBounds on it with offset 0. Note the coordinates.
4. Call CharBounds on it with offset 3.
   • Expected: Larger y coordinate (because offset 3 is on the second line).
   • Actual: The y coordinate is the same as in step 3).

Impact: This breaks NVDA mouse tracking when this occurs; e.g. in Bugzilla comment code blocks.

This also has the effect that the JAWS cursor cannot access the line that has ab in it. Only cd is visible to JAWS. JaWS uses the bounds to create a virtual screen representation for the JAWS cursor from the accessibles in Firefox, since GDI hooking or other screen scraping methods don't work anyway. This would also cause simulated clicks to go to wrong places.

This is not specific to <code>. It also happens with <span>:
data:text/html,<pre><span>a%0ab%0ac
Curiously, if you use a non-inline element, things work as expected:
data:text/html,<pre><div>a%0ab%0ac
So there's something weird going on with intervening inline elements here.

Backed out for causing ancestor related assertion failures.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel&revision=9f8d4babe01d141af1e6a1a63f314d56a5c3b1d8&selectedTaskRun=COIEFHrYSQyidxbf13snJw.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=402103446&repo=autoland
Also this TV failure: https://treeherder.mozilla.org/logviewer?job_id=402107477&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/a59ca89ec14f2f6c7e86f1bcdad00adadc388b74

https://treeherder.mozilla.org/jobs?repo=try&revision=54b5ad4a45ca62d93d770f0809d9ceb2cf469967

https://hg.mozilla.org/mozilla-central/rev/204114ab86ad