[maemo-developers] Browser Switchboard, MicroB, and application prestart in Fremantle

[From: Eero Tamminen]

Hi,

ext Steven Luo wrote:
> I'm the maintainer of Browser Switchboard [1], which is a program
> that's supposed to make it possible for the user to choose the
> default browser on his/her Maemo device.  Packages are available in
> extras for Diablo and extras-devel for Fremantle.
> 
> In order to control the default browser, Browser Switchboard takes
> over handling of the com.nokia.osso_browser D-Bus methods.  Since
> launching MicroB from the menus invokes
> com.nokia.osso_browser.top_application, it has to be able to launch
> MicroB.
> 
> For Diablo, we do this by exec() of /usr/bin/browser(*), but this
> doesn't seem to bring up a browser window in Fremantle (see the
> discussion on talk.maemo.org [2]).
> 
> Also, at least in testing with my half-broken SDK, the Fremantle
> browser process remains in memory even after the last browser window
> closes.  This poses a problem for Browser Switchboard, which releases
> com.nokia.osso_browser before starting MicroB (so that MicroB handles
> the methods while it's open, giving users an easy way to temporarily
> open links in MicroB no matter what their default browser is set to),
> and needs to be able to reclaim the name when the last browser window
> closes.
> 
> I can only assume this behavior is related to the prestarting of the
> browser process in Fremantle, but I'm unclear on how Browser
> Switchboard interacts with prestarting in the first place (is a
> browser process prestarted on boot when Browser Switchboard is
> installed?), and I don't have a Fremantle device to test any of this
> on.
> 
> That leaves me with the following questions:
> 
> * How does one open a new browser window from an application,
>   preferably without using the D-Bus interface?  (If there is no
>   other way to bring up a new window except D-Bus, I assume I'd have
>   to try something like launching the browser process, waiting for it
>   to acquire the com.nokia.osso_browser name, then making the method
>   call, which wouldn't be pretty, and also precludes the possibility
>   of working with a prestarted browser process).
 >
> * Is there a way to ensure the browser process quits when the last
>   browser window closes?  If not, is there a way to receive a signal
>   when the last browser window closes?  (It's probably possible to
>   poll for the existence of a browser window, but I can't think of a
>   way of doing it that doesn't impact battery life and doesn't
>   introduce a potential race condition.)

Browser has normally several processes in the device:
- The UI, which is prestarted
- The master browser daemon which provides it's clients
   with app specific browser daemon instances
- Browser daemon instance for the browser UI
- Browser daemon instance for the messaging UI

The UI pre-starting is controlled from the browser .desktop file.
Comment out the prestart line there and kill browser UI to get
rid of it.

Application specific browser daemon instances are started by a request
from the app to the master daemon.  To get rid all of those daemons,
make sure those apps are not prestarted and kill the apps.

Browser master daemon is started during the X session startup and
restarted by the dsme SW watchdog when it exits.  To make it go
away, use:
	dsmetool -k "/usr/sbin/browserd -d"

If master browser daemon isn't running, I don't think normal Browser UI
or messaging UI to work (they open, but their windows lack useful
content...) though.


	- Eero