Provide open_new_window and load_url methods with boolean fullscreen argument MicroB implements an optional boolean argument to the open_new_window and load_url methods in the com.nokia.osso_browser interface, which allows the application to request that the new page be loaded in a fullscreen window. We need to provide this as well -- otherwise, applications that use the argument will receive an error. Provide versions of open_new_window and load_url with a fullscreen argument, which is ignored for the moment. It's not going to be possible to implement the fullscreen behavior for all supported browsers, but we should implement it for MicroB, at least. Fixes the launching of the Flickr new account page from the Sharing control panel in Fremantle: https://garage.maemo.org/tracker/index.php?func=detail&aid=6444&group_id=1159&atid=4348 Thanks to Tom G for reporting.
Eliminate trailing whitespace from lines
Treat failure to acquire osso_browser name on system bus as non-fatal This makes testing on regular Linux systems (where the system bus is restricted to privileged processes) easier.
Listen on D-Bus system bus as well as session bus Discussion on https://bugs.maemo.org/show_bug.cgi?id=8369 (Hermes doesn't work when Browser Switchboard is installed) revealed that MicroB listens on the D-Bus system bus as well as the session bus. While it's not appropriate for applications to request opening a browser via the system bus (which is supposed to be for requesting system services, not applications), the fact that MicroB listens there means that we need to too. This fixes Browser Switchboard bug 5910. Thanks to Andrew Flegg and Marcin Juszkiewicz for providing the information needed to track down this bug.
Revert "Make startup notification work for MicroB menu entry" This behaves very badly if you try to use the MicroB menu entry while MicroB is already open (a new MicroB will open after you close the MicroB). This reverts commit 846e68b8ffa979d30ed331c43020212ffdee2bf2.
Make startup notification work for MicroB menu entry To have working startup notification, we have to provide a D-Bus service with a top_application method; hildon-desktop will then use that to launch the application instead of invoking the binary directly. Co-opt the org.maemo.garage.browser_switchboard name previously used for locking for this (replacing a - with a _ to get around D-Bus naming restrictions). While we're at it, remove the non-standard switchboard_launch_microb method from the com.nokia.osso_browser interface we implement, instead providing a launch_microb method in our own interface.
Make "Web" menu entry and /usr/bin/browser open the default browser Currently, no matter what the default browser is set to, the "Web" menu entry opens MicroB, and running /usr/bin/browser does the same. This is done to make sure that there's always a way of opening MicroB regardless of the default browser setting. However, this behavior would seem to be less than intuitive (why does the entry marked "Web" not open the default browser? on Diablo, why do the Web sidebar panel and Web menu entry do completely different things?). Therefore, do the following: * Make the top_application method in the D-Bus interface open the default browser, not MicroB, and therefore make the "Web" menu entry open the default browser. * Ship a new microb.desktop file which provides a MicroB menu entry that launches MicroB. * Rename the existing /usr/bin/browser script to /usr/bin/microb. * Ship a new /usr/bin/browser script which launches the default browser. This has one primary disadvantage: none of the standard methods of launching a browser on Maemo can be guaranteed to bring up MicroB (with the old behavior, invoking /usr/bin/browser was guaranteed to bring up MicroB, just as if Browser Switchboard weren't installed).
Convert existing code to use the new logging infrastructure
Force the Fremantle Ovi Store bookmark to open in MicroB The Ovi Store apparently only comes up if you visit with MicroB, so force the link in the Ovi Store bookmark to open in MicroB. Reported by maemo.org talk user ToJa92; additional details provided by Faheem Pervez (qwerty12).
Update copyright notices
Ensure reconfig signal doesn't interrupt request dispatch when (!continuous_mode) If SIGHUP is sent to a browser-switchboard process with continuous mode off, the process will quit. This is the right thing to do in most cases (the next request will relaunch the process, at which point it'll read the new config), but if we're in the middle of dispatching a request when the signal arrives, quitting immediately will cause the request to be lost. Since browser-switchboard quits upon completion of a request when continuous mode is off anyway, fix this by just ignoring SIGHUP while handling requests when continuous mode is off.
Add some comments to the code Restore some of the comments from the Python script, plus a few other points that might make the code clearer.
Fix thinko in open_address if (!uri && uri[0] = '/') is obviously never going to be true ... Fix by just giving up in the !uri case. Strangely enough, I'm not hitting this in testing on the tablet -- perhaps gcc is optimizing out the test?
Clean up string handling Revise the handling of strings in several places to be less confusing and safer. Fix at least two definite bugs in launcher.c concerning integer overflows and realloc() possibly moving memory. Also a few indentation changes.
Style changes
Commit a plain C reimplementation of browser-switchboard The C implementation has a ~2 second startup time advantage over the Python version, very noticeable when continuous_mode is disabled. For now, the config file format is incompatible with the Python implementation.