Active Topics

 



Notices


Reply
Thread Tools
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#41
Originally Posted by jlacombe View Post
After installing the Browser Switchboard App, my homescreen widgets (twitter, facebook, etc.) no longer open correctly.
Firstly, did you restart your device after installing Browser Switchboard? If not, try that before doing anything else.

If restarting doesn't help, then try the following:
  1. Upgrade to Browser Switchboard 3.1-2fremantle1. (This shouldn't solve your problem, but it will make finding the problem easier.)
  2. Open an X Terminal, then type the following, pressing Enter after each line (the $ is a prompt that will be displayed to you, not something you type):
    Code:
    $ killall browser-switchboard
    $ browser-switchboard
    You should get output that looks something like this:
    Code:
    continuous_mode: 0
    default_browser: 'fennec'
    other_browser_cmd: 'NULL'
    Starting main loop
  3. Try to open one of your home screen bookmarks.
  4. Assuming it doesn't work, copy all of the stuff Browser Switchboard writes to the xterm and post it here so that I can have a look at it.
 

The Following 2 Users Say Thank You to steven676 For This Useful Post:
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#42
Okay, can someone running Fremantle please try the following:
  1. Install or upgrade to 3.1-2fremantle1 (you could use an older release, but there'll be a lot more noise in the debugging output).
  2. Reboot the device.
  3. Start Browser Switchboard from an xterm or ssh session on the device:
    Code:
    $ killall browser-switchboard
    $ browser-switchboard
  4. Open MicroB, then close all the MicroB browser windows.
  5. Post the output from browser-switchboard here, along with the output from "ps -ef | grep browser".

Thanks!

Originally Posted by jukey View Post
Do you have plans to get a device anytime?
A N900? No, for reasons that have been discussed to death elsewhere on this forum. As for a future Fremantle or Harmattan device ... we'll have to see.
 

The Following 3 Users Say Thank You to steven676 For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#43
*After installing and rebooting*:
1206 user 37712 S /usr/sbin/browserd -d
1659 user 2088 S grep browser

*killall browser-switchboard ; browser-switchboard*
Starting main loop

*After opening MicroB from application menu and closing blank window and bookmarks window: *
Starting main loop [same message above - this is not a duplicate.]
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
Checking to see if MicroB is ready
MicroB ready
Checking to see if we should kill MicroB
Checking to see if we should kill MicroB
Closing MicroB

1206 user 37712 S /usr/sbin/browserd -d
1797 user 39960 S /usr/sbin/browserd -d -b
1824 user 2088 S grep browser
The fact that you're not getting an N900 but still doing all this work is nice.

*Thanking you in the hope that you eventually accrue enough Karma to be able to apply for the next Developer Discount Program*

Last edited by qwerty12; 2010-02-05 at 11:44.
 

The Following User Says Thank You to qwerty12 For This Useful Post:
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#44
Originally Posted by qwerty12 View Post
*After opening MicroB from application and closing blank window and bookmarks window: *
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
Checking to see if MicroB is ready
MicroB ready
Checking to see if we should kill MicroB
Checking to see if we should kill MicroB
Closing MicroB

1206 user 37712 S /usr/sbin/browserd -d
1797 user 39960 S /usr/sbin/browserd -d -b
1824 user 2088 S grep browser
Huh, so this actually (mostly) works properly for you? (You can check by setting the default browser to something other than MicroB and verifying that links open in that browser.)

Really puzzled by why the second browserd starts, though; what does "pidof /usr/sbin/browserd" show?
 

The Following 2 Users Say Thank You to steven676 For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#45
Originally Posted by steven676 View Post
Huh, so this actually (mostly) works properly for you? (You can check by setting the default browser to something other than MicroB and verifying that links open in that browser.)

Really puzzled by why the second browserd starts, though; what does "pidof /usr/sbin/browserd" show?
It does, actually. Just set the default to Tear, opened up MaePad and pressed "Visit website" in its About dialog box (and I know that it uses MicroB's D-Bus calls) and the correct site opened up in Tear. Set it to MicroB (without having any MicroB windows already open) and the "Visit website" link correctly opened in MicroB. This is with Browser Switchboard's default of "Lower memory usage".

~ $ pidof /usr/sbin/browserd
~ $ pidof browserd
2071 2051 1840 1797 1206
~ $

For reference:
1206 user 37712 S /usr/sbin/browserd -d
1797 user 39960 S /usr/sbin/browserd -d -b
1840 user 65372 S /usr/sbin/browserd -s 1840 -n RTComMessagingServer
2046 user 3336 S /usr/bin/browser-switchboard
2051 user 39964 S /usr/sbin/browserd -d -b
2052 user 3936 S browser
2053 user 29368 S browser
2071 user 55408 S /usr/sbin/browserd -s 2071 -n browserui
2149 user 2092 S grep browser

[No MicroB windows are visible on my screen; tho, I guess that some browserd's can be attributed to the preloading of the Conversations app which also uses a browserd for its interface]

Last edited by qwerty12; 2010-02-05 at 11:57.
 

The Following User Says Thank You to qwerty12 For This Useful Post:
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#46
Originally Posted by qwerty12 View Post
~ $ pidof /usr/sbin/browserd
~ $ pidof browserd
2071 2051 1840 1797 1206
~ $

For reference:
1206 user 37712 S /usr/sbin/browserd -d
1797 user 39960 S /usr/sbin/browserd -d -b
1840 user 65372 S /usr/sbin/browserd -s 1840 -n RTComMessagingServer
2046 user 3336 S /usr/bin/browser-switchboard
2051 user 39964 S /usr/sbin/browserd -d -b
2052 user 3936 S browser
2053 user 29368 S browser
2071 user 55408 S /usr/sbin/browserd -s 2071 -n browserui
2149 user 2092 S grep browser

[No MicroB windows are visible on my screen; tho, I guess that some browserd's can be attributed to the preloading of the Conversations app which also uses a browserd for its interface]
Oookay, so now we have three browserd -d master processes -- it seems to be launching one for each time you start MicroB using Browser Switchboard. That's just odd -- "pidof /usr/sbin/browserd" doesn't return a nonzero exit code, by any chance?

EDIT: Okay, I see why that's happening, never mind -- we should be doing just "pidof browserd".

Even more strangely, we now have "browser" processes -- I'm guessing if you change the default browser back to something other than MicroB, links still open in MicroB? Do those browser processes quit if you run
Code:
dbus-send --session --type=method_call --print-reply --dest="com.nokia.osso_browser" /com/nokia/osso_browser/request com.nokia.osso_browser.exit_browser
? Any chance you can reproduce this (having browser processes open after launching MicroB with Browser Switchboard and then closing the browser windows) starting from a freshly booted device, and provide the debug output coming from browser-switchboard along the way?
 

The Following 3 Users Say Thank You to steven676 For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#47
Originally Posted by steven676 View Post
Even more strangely, we now have "browser" processes -- I'm guessing if you change the default browser back to something other than MicroB, links still open in MicroB?
Bingo.

Here's my ps output whilst this is happening:
1186 user 39964 S /usr/sbin/browserd -d
1722 user 65320 S /usr/sbin/browserd -s 1722 -n RTComMessagingServer
1952 user 39964 S /usr/sbin/browserd -d -b
1953 user 3936 S browser
1954 user 29604 S browser
2119 user 65808 D /usr/sbin/browserd -s 2119 -n browserui
After running "dbus-send --session --type=method_call --print-reply --dest="com.nokia.osso_browser" /com/nokia/osso_browser/request com.nokia.osso_browser.exit_browser":
Nokia-N900-51-1:~# dbus-send --session --type=method_call --print-reply --dest="com.nokia.osso_browser" /com/nokia/osso_browser/request com.nokia.osso_browser.exit_browser
Error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
Nokia-N900-51-1:~# ps | grep browser
1186 user 39964 S /usr/sbin/browserd -d
1722 user 65320 S /usr/sbin/browserd -s 1722 -n RTComMessagingServer
1952 user 39964 S /usr/sbin/browserd -d -b
2593 user 3336 S /usr/bin/browser-switchboard
2595 root 2092 S grep browser
Nokia-N900-51-1:~#
Originally Posted by steven676 View Post
Any chance you can reproduce this (having browser processes open after launching MicroB with Browser Switchboard and then closing the browser windows) starting from a freshly booted device, and provide the debug output coming from browser-switchboard along the way?
------------------------------------

OK, trying after rebooting and browser-switchboard running in the X Terminal...

Just rebooted; no attempts to open any browser:

Nokia-N900-51-1:~# ps | grep browser
1252 user 37712 S /usr/sbin/browserd -d
1692 user 3336 S browser-switchboard
1694 root 2088 S grep browser

~ $ browser-switchboard
continuous_mode: 0
default_browser: 'microb'
other_browser_cmd: 'NULL'
Starting main loop
Opening link from MaePad's about dialog (link opens in MicroB sucessfully):
~ $ browser-switchboard
continuous_mode: 0
default_browser: 'microb'
other_browser_cmd: 'NULL'
Starting main loop
open_address 'http://thpinfo.com/2010/maepad/'
launch_microb with uri 'http://thpinfo.com/2010/maepad/'
Waiting for MicroB to start
Checking to see if MicroB is ready
Message has only 0 arguments, but more were expected
Checking to see if MicroB is ready
MicroB ready
Checking to see if we should kill MicroB
Checking to see if we should kill MicroB


Nokia-N900-51-1:~# ps | grep browser
1252 user 37712 S /usr/sbin/browserd -d
1698 user 3336 S browser-switchboard
1735 user 45976 S /usr/sbin/browserd -d -b
1736 user 3936 S browser
1737 user 30772 S browser
1738 user 104m R /usr/sbin/browserd -s 1738 -n browserui
1749 root 2088 S grep browser
With the windows closed:
~ $ browser-switchboard
continuous_mode: 0
default_browser: 'microb'
other_browser_cmd: 'NULL'
Starting main loop
open_address 'http://thpinfo.com/2010/maepad/'
launch_microb with uri 'http://thpinfo.com/2010/maepad/'
Waiting for MicroB to start
Checking to see if MicroB is ready
Message has only 0 arguments, but more were expected
Checking to see if MicroB is ready
MicroB ready
Checking to see if we should kill MicroB
Checking to see if we should kill MicroB
Closing MicroB
sh: you need to specify whom to kill [It was Ctrl-C'd by me]

Nokia-N900-51-1:~# ps | grep browser
1252 user 37712 S /usr/sbin/browserd -d
1735 user 46104 S /usr/sbin/browserd -d -b
OK, so I couldn't reproduce it again. So I then opened the link again (in the same Browser Switchboard session). Success!

~ $ browser-switchboard
continuous_mode: 0
default_browser: 'microb'
other_browser_cmd: 'NULL'
Starting main loop
open_address 'http://thpinfo.com/2010/maepad/'
launch_microb with uri 'http://thpinfo.com/2010/maepad/'
Waiting for MicroB to start
Checking to see if MicroB is ready
Message has only 0 arguments, but more were expected
Checking to see if MicroB is ready
MicroB ready
Checking to see if we should kill MicroB
Checking to see if we should kill MicroB
Closing MicroB
sh: you need to specify whom to kill [I didn't Ctrl-C it; Browser Switchboard closed of its own accord]
~ $

Nokia-N900-51-1:~# ps | grep browser
1255 user 37712 S /usr/sbin/browserd -d
1762 user 46108 S /usr/sbin/browserd -d -b
1820 user 3336 S /usr/bin/browser-switchboard
1825 user 39832 S /usr/sbin/browserd -d -b
1826 user 3936 S browser
1827 user 29368 D browser
1828 user 66096 R /usr/sbin/browserd -s 1828 -n browserui
1852 root 2088 S grep browser
 

The Following User Says Thank You to qwerty12 For This Useful Post:
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#48
Originally Posted by qwerty12 View Post
After running "dbus-send --session --type=method_call --print-reply --dest="com.nokia.osso_browser" /com/nokia/osso_browser/request com.nokia.osso_browser.exit_browser":

[snip]
Hm, okay, so that suggests that (1) browser-switchboard isn't picking up the cue to send the exit_browser method call, (2) MicroB doesn't always close in response to the exit_browser call, or (3) the method call is getting lost in transit.

Originally Posted by qwerty12 View Post
OK, trying after rebooting and browser-switchboard running in the X Terminal...

Just rebooted; no attempts to open any browser.

[snip]
Yet there seems to be a browser-switchboard running before you start one from the shell? Somewhat strange.

Originally Posted by qwerty12 View Post
With the windows closed:

[snip]
With continuous mode off, it's normal for browser-switchboard to exit after closing MicroB (and possibly trying to kill browserd), so I'm not sure why you had to Ctrl-C it here.

Originally Posted by qwerty12 View Post
OK, so I couldn't reproduce it again. So I then opened the link again (in the same Browser Switchboard session). Success!

[snip]
Bother; that supports idea (2) or (3) above ("Closing MicroB" should be printed right before the method call, and the error message comes from the attempt to kill browserd, which occurs after the method call is issued). I was hoping to avoid a straight kill() for fear of data loss, but it looks like we'll have to see if that works more reliably.
 

The Following User Says Thank You to steven676 For This Useful Post:
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#49
For Diablo users, Browser Switchboard 3.1-2 is now in Diablo extras (finally!) and on the Garage download page. The only change between 3.1-1 and this release is a small change to dependencies which shouldn't affect any users, and allows this release to land in extras. See the first post in the thread (now updated!) for details of the changes between 3.0 and this release.

For Fremantle users, Browser Switchboard 3.1-2fremantle2 is now on the Garage download page and in Fremantle extras-devel.

Changes between 3.1-2fremantle1 and 3.1-2fremantle2:
  • Make sure an already-running browserd is detected correctly; fixes a problem reported by qwerty12.
  • Be less polite about killing MicroB when we detect that the last browser window has closed; hopefully makes this a more reliable process.

MANY thanks to jukey and qwerty12 for providing the extensively detailed feedback which produced the changes in this release.

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).

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.

(If this release is still broken, I have one more trick up my sleeve; if that doesn't work, we'd need more drastic measures to make Fremantle MicroB play nicely with Browser Switchboard.)

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

TODO list before releasing 3.2 (mainly for my own benefit, but also useful if you're curious):
  • Finish making MicroB and Browser Switchboard behave nicely together on Fremantle. (should make it possible to push Browser Switchboard to Fremantle extras-testing)
  • Clean up the build system.
  • Refactor the launch_microb mess to make it more readable.
  • Introduce a more flexible logging system which allows logging to syslog, to make debugging intermittently occurring problems easier.
  • Make the "Web" menu entry launch MicroB and provide an alternate way of launching MicroB, to make the behavior more intuitive for new users (see this post for details).

TODO list post-3.2:
  • Do something intelligent when the user's configured browser isn't installed.
  • In the UI, don't let the user configure a browser that's not installed.
  • Provide a command-line tool for configuring browser-switchboard which can be used by browser developers to set their browser as the default.

Last edited by steven676; 2010-04-21 at 09:49.
 

The Following 4 Users Say Thank You to steven676 For This Useful Post:
luca's Avatar
Posts: 1,137 | Thanked: 402 times | Joined on Sep 2007 @ Catalunya
#50
I can't thank you enough for browser-switchboard, but at the same time I cannot forget that on a sane platform all this contortions shouldn't be necessary.
 
Reply

Tags
browser, default, microb, opera


 
Forum Jump


All times are GMT. The time now is 23:05.