Spun off bug 1809082. Causes problems in LinkedIn and Google Bard.

From bug 1809082 comment 38:

data:text/html,<div style="height:100px; overflow:scroll;"><div id="text"></div></div><button onClick="let html=''; for (let i = 1; i <= 20; ++i) { html += i; html += '<br>'; } document.getElementById('text').innerHTML = html;">Add Text</button>

Click the "Add Text" button, then note the bounds of the "text" id. Scroll the scrollable region to the bottom. Note that the bounds of the text id have not changed accordingly. At this point, hit testing the scrolled text will report results as if it's unscrolled.

The contenteditable bit doesn't matter, but it does seem important that the text be entered after page load.

From bug 1809082 comment 39:

1. What's happening here is that the overflow div isn't getting an Accessible, so we can't cache scroll data on it.
2. Normally, when something is scrollable, it gets an Accessible because its scrollability makes it focusable and focusable things always get Accessibles.
3. In this case, the div wasn't scrollable initially, so we didn't create an Accessible for it.
4. Often, when something becomes scrollable, it causes reflow, in which case we would re-evaluate the div and create an Accessible for it.
5. In this case, I guess it doesn't get reflowed, perhaps because the size of the div itself doesn't change. Thus, we don't create an Accessible for it.

We can fix this by always creating an Accessible for elements which have overflow: scroll or overflow: auto. To do that, we should be able to extend Morgan's creation patch over in bug 1825611.

Backed out with Bug 1825611 and Bug 1825411 for accessible failures on on /browser_general.js

• backout: https://hg.mozilla.org/integration/autoland/rev/8d8d99e7581851de698e27339dffd60ee8dc8e32

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/8d8d99e75818

https://hg.mozilla.org/mozilla-central/rev/1d00ca0cca3b

The patch landed in nightly and beta is affected.
:morgan, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox114 to wontfix.

For more information, please visit BugBot documentation.

I think we will want to uplift this, but not yet -- it's a pretty big patch stack and it could use some more time to bake. I'll leave this NI and revisit

We've deemed this too risky to upload at this point in the cycle, marking 114 as wontfix

backed out in 115 beta (115.0rc1) for causing bug 1840200 (backout patch is in bug 1840200)