Re: IPC plans
Trevor Saunders <[email protected]> Thu, 27 Mar 2014 15:38:02 -0400
| Newsgroups | gmane.comp.mozilla.accessibility |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Mar 27, 2014 at 03:24:58PM -0400, Alexander Surkov wrote: > = > = > = > On Wed, Mar 26, 2014 at 7:18 PM, Trevor Saunders <[email protected]> > wrote: > = > On Wed, Mar 26, 2014 at 03:59:35PM -0400, Alexander Surkov wrote: > > > > > > > > On Wed, Mar 26, 2014 at 3:34 PM, Trevor Saunders <trev.saunders@gma= il.com > > > > wrote: > > > > =A0 =A0 On Wed, Mar 26, 2014 at 03:13:58PM -0400, Alexander Surkov = wrote: > > =A0 =A0 > > > =A0 =A0 > > > =A0 =A0 > > > =A0 =A0 > On Wed, Mar 26, 2014 at 2:49 PM, Trevor Saunders < > [email protected] > > =A0 =A0 > > > =A0 =A0 > wrote: > > =A0 =A0 > > > =A0 =A0 > =A0 =A0 On Wed, Mar 26, 2014 at 09:04:36AM -0400, Alexand= er Surkov > wrote: > > =A0 =A0 > =A0 =A0 > Hi. > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > 1) If you plan to make AT to talk to the main p= rocess only > then it > > =A0 =A0 means > > =A0 =A0 > =A0 =A0 the AT > > =A0 =A0 > =A0 =A0 > should see a whole MSAA tree as unique tree, th= e same trick > can be > > =A0 =A0 done > > =A0 =A0 > =A0 =A0 for > > =A0 =A0 > =A0 =A0 > XPCOM. I.e. the way XPCOM tree is implemented s= houldn't be > > =A0 =A0 different from > > =A0 =A0 > =A0 =A0 MSAA > > =A0 =A0 > =A0 =A0 > tree implementation. > > =A0 =A0 > > > =A0 =A0 > =A0 =A0 I agree the xpcom tree *can* all be in one proces= s, but I'm not > sure > > =A0 =A0 I > > =A0 =A0 > =A0 =A0 agree its either desirable or easier than the alt= ernative. > > =A0 =A0 > > > =A0 =A0 > > > =A0 =A0 > AccessFu is not quite different from platform screen read= ers by its > > =A0 =A0 nature. I'm > > =A0 =A0 > pretty sure they will need a mechanism to cross the bound= aries > between > > =A0 =A0 > processes. So either it'll be one tree or multiple trees = with > > =A0 =A0 cross-platform > > =A0 =A0 > bridges. > > > > > > =A0 =A0 aiui they already deal with multiple processes because they= work on > b2g > > =A0 =A0 and they deal with it with content scripts and stuff in JS.= =A0So since > > =A0 =A0 AcessFoo seems to already work in a multiprocess world I ju= st assume > > =A0 =A0 leave it as is unless we have a reason to change it. > > > > > > If it works then fine (I'd love to hear Eitan or Yura on this). One= tree > might > > be useful for tools like DOMi though. But it can be an emulation of= the > unique > > tree I guess on DOMi side. > = > Seems they want it. > = > > =A0 =A0 > =A0 =A0 > 2) I assume that you can have sync access to co= ntent process > DOM > > =A0 =A0 tree > > =A0 =A0 > =A0 =A0 from the > > =A0 =A0 > > > =A0 =A0 > =A0 =A0 you can't unless we add it, and we'd need to add = sync access to > the > > =A0 =A0 > =A0 =A0 frame tree too... > > =A0 =A0 > > > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > main process, so if the main process doesn't du= pe DOM trees > of > > =A0 =A0 content > > =A0 =A0 > =A0 =A0 > processes then it's good to explain why accessi= bility tree is > > =A0 =A0 different. > > =A0 =A0 > > > =A0 =A0 > =A0 =A0 there's just no reason to have general access to = the dom in the > child > > =A0 =A0 > =A0 =A0 process from the parent. > > =A0 =A0 > > > =A0 =A0 > > > =A0 =A0 > I'm curious though how content plugins are implemented. T= heir head > should > > =A0 =A0 be in > > =A0 =A0 > chrome process but they operate on content. > > > > =A0 =A0 I'm not sure what you mean "content plugins" > > > > > > Firefox add-ons that deal with content. I can see they took a diffe= rent > way on > > their implementation so it doesn't look like it requires sync > communications ( > > https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Content_Scri= pts) > = > yeah, the things for addons aren't useful for us. > = > > =A0 =A0 > =A0 =A0 > 3) Didn't you consider a scenario when AT commu= nicates with > each > > =A0 =A0 process? > > =A0 =A0 > > > =A0 =A0 > =A0 =A0 not really, it would be hard to sand box, and it = would require > a > > =A0 =A0 bunch > > =A0 =A0 > =A0 =A0 of tricky platform specific code for each platfor= m, and its not > even > > =A0 =A0 > =A0 =A0 clear to me its possible on mac. > > =A0 =A0 > > > =A0 =A0 > > > =A0 =A0 > The stake is to win in memory and in performance. Even if= it > requires > > =A0 =A0 platfrom > > > > =A0 =A0 it looses on security and it would be a lot of pretty evil = platform > > =A0 =A0 specific code assuming it even works on mac and I'm pretty = sure the > > =A0 =A0 android stuff would need its own special IPC stuff anyway. > > > > > > ATK makes one-tree magic on their side afaik, so if we had disconne= cted > trees > = > Sure, but that assumes no sandbox, we could probably hax the dbus stu= ff > so that it communicated out of the sandbox with fds we sendmesg()ed i= n, > but I'm pretty sure it would be really gross, there was a reason I sa= id > this is non trivial... :p > = > = > I'm not sure I follow your proposal how to implement things for ATK. then don't worry about it. > > in each process then it should be ok for ATK. Windows is HWND based= so > they are > > quite different. If we learned how to let AT to interact with HWNDs= from > > content processes then it'd be awesome since we could have disconne= cted > trees > > again. If that's a security treat then we need to work with securit= y team > to > > figure out how that's bad because otherwise we can end up with > unperformant and > > memory heavy solution. > = > how is it not obvious its bad? afaik the sandboxing plan for windows > means no hwnds in content processes heck, even if we had hwnds any way > stuff in the content process has of communicating with stuff outside = is > a security issue. =A0I'm pretty sure we've been over this a couple ti= mes > already. > = > = > I've never heard any feedback from security team. If the solution we will= end I remember talking about this with you in the room... besides it really isn't hard to see its an issue. Trev > up will be unperfromant or memory heavy then it's quire possible that AT = users > will continue to run Firefox in single process. What I suggest is to make= sure > we considered all alternatives. > =A0 > = > = > > =A0 =A0 > specific code then it's worth to consider the option (it = seems Hub > agrees > > =A0 =A0 on > > =A0 =A0 > it). > > > > =A0 =A0 I haven't seen him say anything... > > > > > > He said: > > "I'm also concerned that using more memory might be a problem on me= mory > > constrained platform like mobile phone (we have less than half a GB= of > > RAM and then we have "containers" for each app). Just to keep that = in > mind." > = > I'm really not that worries about memory, its just another hash table > per document, and of course the smaller the total amount of memory the > fewer the number of documents you can have. > = > Trev > = > > =A0 > > > > > > =A0 =A0 Trev > > > > =A0 =A0 > =A0 > > =A0 =A0 > > > =A0 =A0 > > > =A0 =A0 > =A0 =A0 Trev > > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 Hi, > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0This mail is going to attempt to des= cribe how > accessibility > > =A0 =A0 will > > =A0 =A0 > =A0 =A0 work > > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0in e10ns Gecko. follow ups to dev-ac= cessibility is > probably > > =A0 =A0 best. > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 tldr: > > =A0 =A0 > =A0 =A0 > =A0 =A0 - the operating system level accessibil= ity API will only > talk > > =A0 =A0 to the > > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 main process > > =A0 =A0 > =A0 =A0 > =A0 =A0 - accessibility information will be com= puted in the same > > =A0 =A0 process as > > =A0 =A0 > =A0 =A0 the > > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 content it is for. > > =A0 =A0 > =A0 =A0 > =A0 =A0 - Where it is advantagious we will cach= e information in > the > > =A0 =A0 parent > > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 process instead of blocking on IPC. > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 details: > > =A0 =A0 > =A0 =A0 > =A0 =A0 The main process will have a tree cachi= ng data for each > sub > > =A0 =A0 tree in a > > =A0 =A0 > =A0 =A0 > =A0 =A0 content process. =A0The tree of documen= ts in in each of > these > > =A0 =A0 subtrees > > =A0 =A0 > =A0 =A0 > =A0 =A0 will be updated with PContent::PDocAcce= ssibleConstructor > () and > > =A0 =A0 > =A0 =A0 > =A0 =A0 PDocAccessible::__delete__(), and the t= ree of accessibles > in > > =A0 =A0 each > > =A0 =A0 > =A0 =A0 > =A0 =A0 document will be kept up to date with s= how and hide > events. > > =A0 =A0 =A0This > > =A0 =A0 > =A0 =A0 means > > =A0 =A0 > =A0 =A0 > =A0 =A0 caching the arrangement of accessibles = in the tree is > easy, and > > =A0 =A0 > =A0 =A0 probably > > =A0 =A0 > =A0 =A0 > =A0 =A0 makes things simpler in addition to fas= ter. =A0At least in > theory > > =A0 =A0 we > > =A0 =A0 > =A0 =A0 can > > =A0 =A0 > =A0 =A0 > =A0 =A0 cache everything that always fires an e= vent when it > changes, > > =A0 =A0 but I > > =A0 =A0 > =A0 =A0 > =A0 =A0 expect at first we'll only cache the tr= ee and then add > more > > =A0 =A0 caching > > =A0 =A0 > =A0 =A0 > =A0 =A0 based on performance data. > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 I plan on having a set of ipdl actors p= er document and > then > > =A0 =A0 using > > =A0 =A0 > =A0 =A0 > =A0 =A0 integer ids to refer to accessibles wit= hin that document, > we > > =A0 =A0 can > > =A0 =A0 > =A0 =A0 > =A0 =A0 repurpose the mAccessiblecache which ma= ps pointers to > > =A0 =A0 accessibles to > > =A0 =A0 > =A0 =A0 > =A0 =A0 themselves to map ids to accessibles in= a manor that is > safe. > > =A0 =A0 =A0This > > =A0 =A0 > =A0 =A0 > =A0 =A0 saves the over head we'd have if we had= an actor per > accessible > > =A0 =A0 which > > =A0 =A0 > =A0 =A0 > =A0 =A0 would result in thousands of actors for= sessions with > many > > =A0 =A0 tabs. > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 unresolved issues: > > =A0 =A0 > =A0 =A0 > =A0 =A0 - xpcom API should it be one tree or tr= ee per process? > afaik > > =A0 =A0 > =A0 =A0 AccessFoo > > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 assumes tree per process and our te= st suite assumes one > tree > > =A0 =A0 for > > =A0 =A0 > =A0 =A0 > =A0 =A0 everything, so we need to reconsile thi= s somehow, but I'm > not > > =A0 =A0 sure it > > =A0 =A0 > =A0 =A0 > =A0 =A0 needs to happen immediately. > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 - we need to use the ipc infrastructure= in the platform > layer > > =A0 =A0 to > > =A0 =A0 > =A0 =A0 handle > > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 accessible objects for content in c= hild processes I'm > not > > =A0 =A0 exactly > > =A0 =A0 > =A0 =A0 sure > > =A0 =A0 > =A0 =A0 > =A0 =A0 how this should look some ideas would i= nclude sub > classing > > =A0 =A0 accessible > > =A0 =A0 > =A0 =A0 / > > =A0 =A0 > =A0 =A0 > =A0 =A0 making it more generic and having a pro= xy and local > > =A0 =A0 implementation, > > =A0 =A0 > =A0 =A0 or > > =A0 =A0 > =A0 =A0 > =A0 =A0 maybe it would be better for platform A= PI methods to > explicitly > > =A0 =A0 > =A0 =A0 handle > > =A0 =A0 > =A0 =A0 > =A0 =A0 remote accessibles with something like = if accWrap > accWrap-> > > =A0 =A0 FOobar() > > =A0 =A0 > =A0 =A0 else > > =A0 =A0 > =A0 =A0 > =A0 =A0 remoteDoc->Foobar(accWrapId) but I figu= re we can figure > this > > =A0 =A0 out once > > =A0 =A0 > =A0 =A0 we > > =A0 =A0 > =A0 =A0 > =A0 =A0 have the plumbing either case will need= to call sorted > out. > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 question / comments / whatever welcome! > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 Trev > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > =A0 =A0 _______________________________________= ________ > > =A0 =A0 > =A0 =A0 > =A0 =A0 accessibility mailing list > > =A0 =A0 > =A0 =A0 > =A0 =A0 [email protected] > > =A0 =A0 > =A0 =A0 > =A0 =A0 https://lists.mozilla.org/listinfo/acce= ssibility > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > =A0 =A0 > > > =A0 =A0 > > > =A0 =A0 > > > > > > = > =