Issue 127431 in chromium: AX information for textareas can get out of date with threaded compositing / animations

[chro...@googlecode.com]

Status: Untriaged
Owner: ----
CC: nd...@chromium.org, dmaz...@chromium.org, jsc...@chromium.org,
ana...@chromium.org, dts...@chromium.org, voll...@chromium.org
Labels: Type-Bug Pri-2 Area-Internals OS-Windows Hotlist-Windows8

New issue 127431 by jam...@chromium.org: AX information for textareas can
get out of date with threaded compositing / animations
http://code.google.com/p/chromium/issues/detail?id=127431

The Accessibility tree contains information about the location and size of
various interactive elements on the page. This is used for AX everywhere
and the text area information is used for on screen keyboard activation on
Win8. Currently this data is collected and synchronized from the WebKit
main thread by the content::RenderView's content::RendererAccessibility
object and synced to the browser UI thread via IPC. This mechanism uses
some hand-rolled batching to get the data out of WebCore's RenderObject
tree.

Unfortunately, with threaded compositing and animations this data can get
arbitrarily out of date with respect to the frame that the users sees. For
instance, consider a long page with a text area in win8. If the WebKit
main thread is blocked and the user scrolls the page with their finger and
then taps on where they visually see the text area, we won't pop the OSK up
even though we've presented new frames showing the text area at the new
location.

I think that to fix this we need to push at least the text area geometry
information to the compositor layer tree and have the compositor be
responsible for pushing this information to the browser whenever the
compositor updates the corresponding layer geometry.

[chro...@googlecode.com]

Comment #1 on issue 127431 by dmaz...@chromium.org: AX information for

textareas can get out of date with threaded compositing / animations
http://code.google.com/p/chromium/issues/detail?id=127431

If the WebKit main thread is blocked, won't the user experience will still
be just as bad either way? Even if the OSK pops up, the text box won't get
focus, the insertion point won't appear, and it won't be able to receive
keystrokes. So I'm not convinced this is the right solution.

If anything, I'd say it might be better to try to use the layer compositor
information to learn if the accessible tree is significantly out of sync
with what's displayed (like, by more than 100 ms) and return E_FAIL from
AccessibleObjectFromPoint when they're out of sync so the page appears
unresponsive (which it is) rather than popping up a useless OSK.

[chro...@googlecode.com]

Comment #2 on issue 127431 by jam...@chromium.org: AX information for

textareas can get out of date with threaded compositing / animations
http://code.google.com/p/chromium/issues/detail?id=127431

If the WebKit main thread is blocked we can still scroll. I think we want
the user to be able to tap on any place where they visually see a text area
and have the OSK pop up, even if it only gets the focus ring at some point
later.

[chro...@googlecode.com]

Comment #4 on issue 127431 by jam...@chromium.org: AX information for

textareas can get out of date with threaded compositing / animations
http://code.google.com/p/chromium/issues/detail?id=127431

That sounds pretty plausible to me at first glance. Is this something you
can work in for m22?

[chro...@googlecode.com]

Updates:
Status: WontFix

Comment #7 on issue 127431 by dmaz...@chromium.org: AX information for

textareas can get out of date with threaded compositing / animations
http://code.google.com/p/chromium/issues/detail?id=127431

This isn't needed anymore, now that we can trigger popping up the OSK after
the tap event.