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 04:55:19 +0000 (20:55 -0800)
commite7bb0f3e07ebcb347539f050b229f4d88e7d3205
treec58c91fbb4d487c1cf92f88ef8cc187a8f0c3e53
parentc17db1caa3a6cda69776d40bb3292d42e112aa21
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