On Jun 22, 2011, at 4:29 PM, James Robinson wrote: > On Wed, Jun 22, 2011 at 4:21 PM, Chris Fleizach <cfleiz...@apple.com> wrote: > > On Jun 22, 2011, at 3:34 PM, Dominic Mazzoni wrote: > > > I just had another thought: how would this work in a multi-process browser? > > > > As you may know, Chrome runs an instance of webkit in a separate > > renderer process for each tab, but the GUI and all accessibility > > handling happens in the main browser process. Because accessibility > > calls are synchronous, we cache accessibility information in the > > browser process and respond to queries from that cache, rather than > > sending an IPC to the renderer process and getting a response. I > > realized that we wouldn't be able to use this search function very > > easily as you've proposed it. If NSAccessibility gets such an API, > > we'd have to write our own implementation that could run in Chrome's > > browser process. > > > > I think this is one drawback of Chrome's approach, the inability to retrieve > dynamic information. I suspect Chrome has similar issues for the > NSAccessibilityParameterizedAttribute attributes, and that it doesn't support > the AXTextMarker APIs that Safari does for the same reason. > > To support this (along with the other things I mentioned) Chrome would need > to synchronously called into WebCore, wait for the answer, and then return > that information. > > Assuming that the data is needed from the browser process (or UI process in > WebKit2 terminology) that's not acceptable from either a performance or bug > point of view. In a multi-process browser, you can never let the browser (or > UI) process block on a synchronous message from the renderer (or web) process. >
While this policy decision may be important, the downside is that it sacrifices the correctness of Accessibility, on Mac at least. Luckily, there are now hooks in WebKit2 that allow true cross process accessibility. The AT talks directly to the "web process" when it needs to and the hierarchy between the two apps appears seamless. > - James > > > > > My understanding was that WebKit2 and Safari are moving to a > > multi-process model as well. Is this design going to be compatible > > with this? > > > > Yes, WebKit2 works with accessibility. You'll be able to see the code to > support that strewn throughout WebKit2. Let me know if you need more pointers. > > > - Dominic > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
