Notices

Originally Posted by steven676

For Fremantle users, binary packages of Browser Switchboard 3.1-2fremantle3 are now available on Garage and in Fremantle extras-devel.

Again, the "only" change in this release is a change in the way we detect the last MicroB window being closed; this should now work regardless of whether the Conversations application is (pre)started or not. Many thanks to jukey for providing the detailed feedback that produced this change.

Hopefully the following should now work 100% of the time:

1. Configure Browser Switchboard with any default browser other than MicroB.
2. Restart the device.
3. Open a link from an application or a desktop widget; the link should open in the default browser you configured.
4. Open MicroB by using the Web menu entry (you don't need to change the default browser setting or restart the device).
5. Open a link from an application or a desktop widget; the link should open in MicroB.
6. Close all the MicroB browser windows.
7. Open a link from an application or a desktop widget; the link should open in the default browser you configured.
8. Open MicroB by using the Web menu entry (it should come up).

Please let me know whether this works consistently now or not, and whether or not you notice any other inconsistent or strange behaviors. If anything doesn't work as expected along the way, please let me know; if you can, open an xterm, run "killall browser-switchboard; browser-switchboard", go through the sequence of steps, and then provide the output that browser-switchboard produces in the terminal when reporting your problem.

Also, please report any problems you have with MicroB losing bookmarks, history, or settings when it's closed; a change to more heavy-handed measures for killing MicroB in the last release may have introduced such bugs.

Assuming everything works, this should be the last release before 3.2 (for both Diablo and Fremantle).

Originally Posted by qwerty12

4. Closed Tear and opened MicroB from the Web entry in the menu. Bookmarks showed up along with empty window (not a problem for me at least - I really like it doing that [the opening of the new, blank window] but it's not standard behaviour when opening MicroB using the Web menu entry - only the Bookmarks window should show up)

Originally Posted by qwerty12

The only oddity that exists, I would have to say, is that closing the last browser window while still having the Bookmarks window open automatically closes the Bookmarks window. Not a problem for me, personally, as I rely upon the history feature.

Originally Posted by qwerty12

After doing the above steps once, opening the Browser from the menu again and noticing that oddity above, I closed the browser. When I went to open the Browser using the menu entry, Tear popped up so I closed it. Using the menu entry subsequently opened up MicroB but it wasn't through Browser Switchboard as I did not get the blank window.

Originally Posted by qwerty12

Here's the ps output while it's in this state:

~ $ ps | grep browser
1236 user 39964 S /usr/sbin/browserd -d
1630 user 65400 S /usr/sbin/browserd -s 1630 -n RTComMessagingServer
1785 user 3936 S browser
1786 user 33068 S browser
1827 user 72076 S /usr/sbin/browserd -s 1827 -n browserui
1855 user 2092 S grep browser
~ $

Originally Posted by steven676

Both of these are because we have no reliable way of detecting when the bookmarks window closes. These will be release noted (whenever I get around to revising the release notes).

Originally Posted by steven676

Okay, THAT is strange -- I have no idea how that could possibly happen. To make sure I understand you correctly: you used the Web menu entry, and Tear (the Browser Switchboard default browser) came up; then you closed Tear, opened the Web menu entry again, and the MicroB bookmarks window (without the about:blank window that Browser Switchboard opens) came up?

Originally Posted by steven676

That looks like Browser Switchboard launched MicroB (otherwise the browser processes would show as "/usr/bin/browser"). I realize this might be difficult to reproduce, but can you try to reproduce it with browser-switchboard running in a terminal, and show the debug output?

~ $ browser-switchboard
continuous_mode: 0
default_browser: 'tear'
other_browser_cmd: 'NULL'
Starting main loop
launch_microb with uri 'new_window'
Waiting for MicroB to start
Checking to see if MicroB is ready
Message has only 0 arguments, but more were expected

^C
~ $ ps | grep bro
1166 user 39964 S /usr/sbin/browserd -d
2032 user 65284 S /usr/sbin/browserd -s 2032 -n RTComMessagingServer
2360 user 3936 S browser
2361 user 29464 S browser
2475 user 55408 S /usr/sbin/browserd -s 2475 -n browserui
2496 user 2092 S grep bro
~ $

Originally Posted by qwerty12

Sorry, but my attempts to reproduce it were to no avail. (Could you maybe add an option to have it log to syslog, instead? [AFAIK, GLog's default handler under Fremantle outputs to syslog.])

Originally Posted by qwerty12

P.S. As a pedant and a GLib-whore lover, I have to ask to satisfy my feeling of nosiness: Why use the DBus-GLib bindings to provide the dbus-switchboard service but use the libdbus functions to listen to signals?

Originally Posted by qwerty12

Code:

~ $ browser-switchboard
continuous_mode: 0
default_browser: 'tear'
other_browser_cmd: 'NULL'
Starting main loop
launch_microb with uri 'new_window'
Waiting for MicroB to start
Checking to see if MicroB is ready
Message has only 0 arguments, but more were expected

^C
~ $ ps | grep bro
1166 user 39964 S /usr/sbin/browserd -d
2032 user 65284 S /usr/sbin/browserd -s 2032 -n RTComMessagingServer
2360 user 3936 S browser
2361 user 29464 S browser
2475 user 55408 S /usr/sbin/browserd -s 2475 -n browserui
2496 user 2092 S grep bro
~ $

Originally Posted by qwerty12

When I opened the browser using the menu entry and then closed the Bookmark window along with the blank window (trying to use it to browse failed - it stayed blank), I didn't recieve any "killed" messages from the running browser-switchboard process.

Originally Posted by steven676

Hm, so the blank window did come up, then? Browser Switchboard doesn't bring up the blank window until after it detects that MicroB is open, and the above suggests it didn't, so I'm not sure why the window appears here. The failure to actually use the browser suggests that something's wrong with the connection between it and the browserd too -- lots of strange stuff going on here.

Originally Posted by steven676

Because I have no idea how to eavesdrop on D-Bus traffic using the GLib API (the present code does the same thing that dbus-monitor does).

Originally Posted by steven676

Looking at the code again, it looks like there could be a race here between MicroB connecting to the bus and the installation of our eavesdropping filter on the bus. (That would also explain why this is so difficult to reproduce!)