[Webkit-unassigned] [Bug 72589] [GTK] Expose accessibility hierarchy in WebKit2 to ATK/AT-SPI based ATs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=72589





--- Comment #18 from Mario Sanchez Prada <msanchez at igalia.com>  2012-01-09 07:11:23 PST ---
(In reply to comment #16)
> (In reply to comment #15)
> > Thanks for the suggestion and the code snippet Carlos. However I have a doubt: do you think this solution 
> >(using another thread to kill the main one on timeout) is better/cleaner than the current approach?
> 
> Yes, I think so, and it's less error prone. 

Hmm... there's another reason *not* to use g_spawn_sync() that I forgot to mentino before, and it's quite important: I need the AccessibilityTestServer to keep running as a different process while I test all the a11y related stuff from TestWebKitAccessibility, so I can't synchronously spawn that process as you suggest with that snippet of code.

The thing about blocking and having the timeout, that perhaps I explained poorly before, is that I don't want to wait forever in case the AccessibilityTestServer doesn't works as expected (starts a basic app, load some HTML and notify the parent process), so I need a mechanism to kill that child process from TestWebKitAccessibility not to continue with the unit tests.

But, if the a11y server runs and starts fine (so it sends the "OK" message to its parent), I want it to keep running as a separate process while I perform all the a11y-related unit test over it (checking the a11y hierarchy through ATSPI), and will exit only once the parent process exits.

> For example your patch doesn't handle EINTR when reading, I think it should use select, since the descriptor
> is non-blocking to know when to read, and it's leaking the stdout desriptor that should be closed after
> reading. All of that (and more) is correctly handled by g_spawn_sync() and you have the output directly in
> a variable. But I'm fine with your solution (fixing the problems I mentioned) if you think it's better.

Because of the reasons exposed (and sorry for not bringing this last -very important- point up before), I think it's better to keep doing what I did, perhaps adding some extra checks as you suggest, and reviewing the code not to leak anything.

What do you think?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.