Active Topics

 



Notices
Page 8 of 20 « First 67 8 91018 Last »
Reply
Thread Tools
qwerty12's Avatar
qwerty12 is offline qwerty12
2010-02-15 , 02:41
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#71
Originally Posted by steven676 View Post
Is this problem reproducible with the attached patch applied? (I'll tag a release tomorrow with this fix anyway, but it'd be nice to know whether it works or not before.)
OK, after installing a build with that patch applied and rebooting, I couldn't reproduce the problem. This was with starting it from the menu entry ~20 times under different conditions (Tear already open with a link provided to it by Browser Switchboard, closing the Browser windows [Bookmarks, blank window and - sometimes - a window with a link given to it by Browser Switchboard], kill -9'ing browser (the UI part) and just plain opening and closing it).
Last edited by qwerty12; 2010-02-15 at 02:47.
 

The Following User Says Thank You to qwerty12 For This Useful Post:
qwerty12's Avatar
qwerty12 is offline qwerty12
2010-02-15 , 03:15
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#72
I spoke too soon. Sorry, but this bug rears its head randomly.

I did what I had done before - firing up browser-switchboard when the bug popped up again, and this was the 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
This was my ps output:

~ $ ps | grep bro
1225 user 39964 S /usr/sbin/browserd -d
3328 user 65160 S /usr/sbin/browserd -s 3328 -n RTComMessagingServer
3362 user 3936 S browser
3363 user 28656 S browser
3385 user 81092 S /usr/sbin/browserd -s 3385 -n browserui
3420 user 3336 S browser-switchboard [the one I've started manually]
3449 user 3936 S browser
3450 user 28652 S browser
3478 user 2092 S grep bro
But when I did "killall browser", launching the Browser from the menu worked fine again.

And, FWIW, despite having these four browser processes running, I had no browser window upon my screen.
Last edited by qwerty12; 2010-02-15 at 03:24.
 

The Following User Says Thank You to qwerty12 For This Useful Post:
steven676 is offline steven676
2010-02-15 , 03:44
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#73
Originally Posted by qwerty12 View Post
This was my ps output:

Code:
~ $ ps | grep bro
1225 user 39964 S /usr/sbin/browserd -d
3328 user 65160 S /usr/sbin/browserd -s 3328 -n RTComMessagingServer
3362 user 3936 S browser
3363 user 28656 S browser
3385 user 81092 S /usr/sbin/browserd -s 3385 -n browserui
3420 user 3336 S browser-switchboard [the one I've started manually]
3449 user 3936 S browser
3450 user 28652 S browser
3478 user 2092 S grep bro
Two sets of browser processes, both launched by browser-switchboard, and one browser-switchboard process. Did MicroB close "normally" (bookmarks window closed when the last browser window closed) on the last run? If you had browser-switchboard running in the terminal for that one, did you see anything out of the ordinary? (If "yes" and "no", we come to the disturbing implication that sending SIGTERM to MicroB doesn't reliably end the process ... I'm highly reluctant to send SIGKILL here.)

EDIT: This looks like part of the hildon-desktop related failure mode discussed below. browser-switchboard #1 starts MicroB #1; hildon-desktop asks dbus-daemon to start browser-switchboard #2, which receives the load_url request from browser-switchboard #1, launches Tear, and then goes away. Meanwhile, MicroB #1 goes into the queue for com.nokia.osso_browser, and takes the name when browser-switchboard #2 exits.

Then, when you start browser-switchboard #3 from the terminal, it steals com.nokia.osso_browser from MicroB #1 (which goes back into the queue for the name). Opening the Web menu entry then causes browser-switchboard #3 to try to launch MicroB #2. But in the process, it releases com.nokia.osso_browser, which then gets taken immediately by MicroB #1 (before we start looking for changes in the ownership of the name). Thus browser-switchboard #3 never detects MicroB #2 starting, and despite having two MicroBs open at this point, no browser windows will open.

Does this sound reasonable? (And since when did the failure modes for browser-switchboard get so complicated??)

Originally Posted by qwerty12 View Post
But when I did "killall browser", launching the Browser from the menu worked fine again.
To be honest, I've given doing this before attempting to start MicroB some thought -- it shouldn't hurt, and it would deal with at least some of these cases. On the other hand, it wouldn't help the continuous mode case, and papers over real bugs.
Last edited by steven676; 2010-02-15 at 07:57.
 

The Following User Says Thank You to steven676 For This Useful Post:
steven676 is offline steven676
2010-02-15 , 06:10
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#74
Originally Posted by qwerty12 View Post
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.
Okay, I understand this now. Occasionally, dbus-daemon decides that it has to have something handling com.nokia.osso_browser at all times; thus, when we release the name (waiting for MicroB to pick it up), it starts the program in the service definition (another copy of browser-switchboard). This results in the second browser-switchboard handling the load_url request coming from the first -- which causes the browser-switchboard default browser (in this case Tear) to come up.

EDIT: no, hildon-desktop is requesting this:
Code:
$ dbus-monitor
[snip]
method call sender=:1.35 -> dest=org.freedesktop.DBus serial=291 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "com.nokia.osso_browser"
   uint32 0
[snip]
$ dbus-send --session --print-reply --type=method_call --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID string:":1.35"
method return sender=org.freedesktop.DBus -> dest=:1.535 reply_serial=2
   uint32 1123
$ ps -ef | grep 1123
 1123 user      108m S    /usr/bin/hildon-desktop
Not sure how to stop this from happening, but I suppose we could use some form of locking to make sure that the second browser-switchboard doesn't get in the way.
Last edited by steven676; 2010-02-15 at 07:08.
 

The Following User Says Thank You to steven676 For This Useful Post:
steven676 is offline steven676
2010-02-15 , 07:42
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#75
Originally Posted by steven676 View Post
Not sure how to stop this from happening, but I suppose we could use some form of locking to make sure that the second browser-switchboard doesn't get in the way.
Okay, let's try this: try to acquire org.maemo.garage.browser-switchboard from D-Bus and quit if someone already owns it.

Is the Tear-launching behavior reproducible with the attached patch? (Again, I'll cut a release tomorrow with this patch, but feedback would be nice.)
 

The Following User Says Thank You to steven676 For This Useful Post:
qwerty12's Avatar
qwerty12 is offline qwerty12
2010-02-15 , 10:20
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#76
Originally Posted by steven676 View Post
Okay, let's try this: try to acquire org.maemo.garage.browser-switchboard from D-Bus and quit if someone already owns it.

Is the Tear-launching behavior reproducible with the attached patch? (Again, I'll cut a release tomorrow with this patch, but feedback would be nice.)
I couldn't reproduce it when using a build with that attached patch, but then again, I can't control when hildon-desktop requests for it to be started so if I see it later on, I'll let you know.

OK, after opening and closing it for 40 minutes and not seeing the bug, I'd have to say that it is, indeed, fixed. Thanks!

It's definitely fixed: It's been ~6 hours and continuing to open the browser from the Web menu entry works fine.
Last edited by qwerty12; 2010-02-15 at 15:27.
 

The Following User Says Thank You to qwerty12 For This Useful Post:
steven676 is offline steven676
2010-02-16 , 06:29
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#77
For Fremantle users, there's now a 3.1-2fremantle4 release on the Garage download page and in Fremantle extras-devel.

Changes in this release:
  • Fix a race condition between our installing a watch for MicroB startup and the startup itself, which might cause us to loop forever waiting for MicroB to start. (commit 1, commit 2)
  • Make sure only one browser-switchboard process is active at any one time; this prevents a failure mode where hildon-desktop asks dbus-daemon to start another browser-switchboard in the window between our releasing the com.nokia.osso_browser D-Bus name and MicroB acquiring it, which was causing bewildering startup failures. (commit)

Many, many thanks to qwerty12, who provided feedback and eventually remote access to a device to help resolve these bugs.

Once again, the aim is for the following to 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 a previous release may have introduced such bugs.

Assuming no one experiences problems (knock on wood), there should be a 3.2 release (for both Diablo and Fremantle) towards the end of this week.

Speaking of 3.2, I'm still looking for feedback regarding the proposed change in this post; if I don't hear any, I'll assume that no one objects and go ahead with it.
 

The Following User Says Thank You to steven676 For This Useful Post:
qwerty12's Avatar
qwerty12 is offline qwerty12
2010-02-16 , 10:10
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#78
Originally Posted by steven676 View Post
  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).
1. Configured to use Tear as the default browser. Continuous mode turned off.
2. Rebooted.
3. Opened link from the RSS Reader; link opened in Tear.
4. With Tear still open and the default browser still set to Tear, MicroB started from the "Web" menu entry with the Bookmarks window and a blank window.
5. Opened the same link from the RSS Reader; link opened in MicroB, in a new window.
6. All MicroB browser windows closed.
7. Opened the same link from the RSS Reader; link opened in Tear, in a new window.
8. With Tear still open and the default browser still set to Tear, MicroB started from the "Web" menu entry with the Bookmarks window and a blank window.

Originally Posted by steven676 View Post
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.
It's been working consistently for ~12 hours for me.

Originally Posted by steven676 View Post
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 a previous release may have introduced such bugs.
Went to Reddit using the URL entry, added a bookmark and went to the settings to set the text size to "very large". Closed the Reddit window; the Bookmark window (as expected) closed automatically.

Loaded up MicroB using the Web entry in the menu. Reddit bookmark is showing in the Bookmarks window, the toolbar history shows "http://www.reddit.com" when I type "www.redd" and "Complete browsing history" shows I went on Reddit at 10:04 am. The setting for text size is still set to "Very large".
Last edited by qwerty12; 2010-02-16 at 10:19.
 

The Following User Says Thank You to qwerty12 For This Useful Post:
qwerty12's Avatar
qwerty12 is offline qwerty12
2010-02-16 , 10:15
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#79
Originally Posted by steven676 View Post
  • Make the Web menu entry launch the user's selected default browser.
  • Make running "browser" from the shell launch the user's selected default browser.
  • Install a new menu item labeled "MicroB" that can be used to launch MicroB no matter what the default browser is set to.
  • Install a new "microb" script that can be used to launch MicroB no matter what the default browser is set to.
I was going to argue with points 1 and 2 until I saw points 3 and 4. Just one note: In Fremantle, from a user's viewpoint, the browser is not really referred to as "MicroB" but just as "Web". The only time I've seen it referred to as MicroB is in the package names and in "about:"...

That said, it is probably going to take me time to realise that I should stop hitting the "Web" menu entry if I want MicroB!
 

The Following User Says Thank You to qwerty12 For This Useful Post:
steven676 is offline steven676
2010-02-17 , 09:40
Posts: 114 | Thanked: 201 times | Joined on Apr 2009
#80
Originally Posted by qwerty12 View Post
Just one note: In Fremantle, from a user's viewpoint, the browser is not really referred to as "MicroB" but just as "Web".
The concepts of "the default browser" and "the browser that ships with the device (MicroB)" are conflated in many places in Maemo, though. With Browser Switchboard installed, we have to separate the two, so the question is whether users expect the item named "Web" to bring up the browser shipped with the device, or whether they expect it to bring up the default browser they've chosen using Browser Switchboard.
 

The Following User Says Thank You to steven676 For This Useful Post:
Reply
Page 8 of 20 « First 67 8 91018 Last »

Tags
browser, default, microb, opera

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 20:45.

Contact Us - Home - Archive - Top