Take a different approach to detecting MicroB browser window close
authorSteven Luo <steven+maemo@steven676.net>
Sun, 14 Feb 2010 04:55:19 +0000 (20:55 -0800)
committerSteven Luo <steven+maemo@steven676.net>
Sun, 14 Feb 2010 05:02:44 +0000 (21:02 -0800)
commitd1664d84713a1b9731e8c726cd0e69fe38eb5872
treeb5d5529e304ba28fa34f4b3077dd9ce0272d9f5d
parent4ff578a00cae1d0be96e337b2971df6821331435
Take a different approach to detecting MicroB browser window close

As it turns out, the Fremantle IM/SMS application also spawns a
browserd; this browserd also attempts to claim the Mozilla.MicroB or
com.nokia.microb-engine D-Bus name, which means that we cannot count on
the MicroB browserd actually having ownership of this name.

Assuming that this D-Bus name is actually needed by anything else, this
is broken by design (since only one connection can own a name on the bus
at any time, and which browserd owns the name appears to be
nondeterministic); of course, I haven't observed any actual use of this
name in my testing either.  Who comes up with this stuff?!?!!?!

In any event, take a different approach to detecting when the MicroB
browserd closes: get the browserd PID from its profile lockfile, then
ptrace() the process to learn when it closes.  There are various
complications which make this more involved than we'd like, but this
should be a foolproof method of detecting the browserd close.
launcher.c