Bug 7956 - web browser showing empty page (+high cpu usage by browserd)
: web browser showing empty page (+high cpu usage by browserd)
Status: RESOLVED WORKSFORME
Product: Browser
User interface
: 5.0/(2.2009.51-1)
: All Maemo
: Unspecified major (vote)
: ---
Assigned To: unassigned
: browser-bugs
:
: moreinfo, performance
:
:
  Show dependency tree
 
Reported: 2010-01-14 12:50 UTC by Andrej Krutak
Modified: 2010-12-13 18:14 UTC (History)
3 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Andrej Krutak (reporter) 2010-01-14 12:50:06 UTC
SOFTWARE VERSION:
51-1...

EXACT STEPS LEADING TO PROBLEM: 
1. Upgrade from 44-1
2. open a page in browser (any)

EXPECTED OUTCOME:
page is displayed

ACTUAL OUTCOME:
Progress bar shows something is happening (downloading the page?), but in the
end I end up with an empty page..

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:
nothing important, I would guess (though it seems important enough, as others
didn't probably see this behavior). Also, a browserd (-n browserui) daemon
shows about 40% cpu usage (combined with Xorg, it's ~100%)

OTHER COMMENTS:
I'm going to reflash the device - can't use it without browser, and can't wait
2 months to get it fixed by updates... Thus I probably won't be able to provide
further assistance (I'll keep the device with current firmware for today, if
any developer is interested in debugging)
Comment 1 timeless 2010-01-14 23:26:39 UTC
please check to see if you've installed anything like browser-switchboard.

You should be able to look in Application Manager to see what you've installed.
a list would be helpful, or you could try to slowly remove things.
Comment 2 Eero Tamminen nokia 2010-02-22 12:41:38 UTC
So rebooting the device doesn't help?

You could try:
 mv /home/user/.mozilla/microb/ mv /home/user/.mozilla/microb.orig/
 <close browser windows>
 kill <PID of browserd browserui instance>

And if that helps, send the differences in the orig and new/recreated microb
directory contents. I encountered an issue (once during past half year) where
one of the files (compreg.dat) had corrupted and contained binary data instead
of ASCII.
Comment 3 Antti Salminen 2010-03-07 11:26:14 UTC
I have a similar issue that has just gotten worse recently. At some point
microb will stop working and behaves as described here. Last time it happened
was right after having to force quit it after it stopped responding. Rebooting
does help. I will try what Eero Tamminen suggested next time it happens.
Anything else I could do to help find out more?
Comment 4 Eero Tamminen nokia 2010-03-08 17:33:18 UTC
(In reply to comment #3)
> I have a similar issue that has just gotten worse recently. At some point
> microb will stop working and behaves as described here. Last time it happened
> was right after having to force quit it after it stopped responding. Rebooting
> does help.

If rebooting helps, then it's a different issue.

Which release do you have?

The issue you have might be related to connectivity handling.  Then closing all
browser windows, disconnecting from internet (from statusbar) and connecting
again could fix it.
Comment 5 Antti Salminen 2010-03-08 17:51:31 UTC
(In reply to comment #4)

> If rebooting helps, then it's a different issue.

I guess so, the reporter never confirmed that rebooting would not solve it  but
then again it's rather unlikely that he did not try it.

> Which release do you have?

3.2010.02-8

> The issue you have might be related to connectivity handling.  Then closing all
> browser windows, disconnecting from internet (from statusbar) and connecting
> again could fix it.

I will try this.
Comment 6 Antti Salminen 2010-04-11 14:25:43 UTC
(In reply to comment #4)

> The issue you have might be related to connectivity handling.  Then closing all
> browser windows, disconnecting from internet (from statusbar) and connecting
> again could fix it.
> 

Only got around writing about it here now, but when this happened again a while
ago, I tried your suggestion and disconnecting from the WLAN AP & closing all
browser windows did not fix this for me.
Comment 7 Eero Tamminen nokia 2010-04-12 12:07:33 UTC
(In reply to comment #6)
> Only got around writing about it here now, but when this happened again
> a while ago, I tried your suggestion and disconnecting from the WLAN AP &
> closing all browser windows did not fix this for me.

If that doesn't help, after closing WLAN AP (and not having autoconnect on) and
closing all browser windows, you could wait a bit and do "killall -9 browserd"
also.

(Don't do it multiple times, master browserd being terminated multiple times
too fast will trigger the SW watchdog.)
Comment 8 Antti Salminen 2010-04-14 10:55:33 UTC
(In reply to comment #7)

> If that doesn't help, after closing WLAN AP (and not having autoconnect on) and
> closing all browser windows, you could wait a bit and do "killall -9 browserd"
> also.
> 
> (Don't do it multiple times, master browserd being terminated multiple times
> too fast will trigger the SW watchdog.)

OK, that did help but only after I retried it and also killed instances of
/usr/bin/browser. For my case the problem seems to usually (always?) appear
after the browser freezes and I have to force quit it.
Comment 9 Eero Tamminen nokia 2010-04-14 17:19:41 UTC
(In reply to comment #8)
> OK, that did help but only after I retried it and also killed instances of
> /usr/bin/browser.

Ok, so it was an issue on the UI side.  I think for startup performance reasons
the UI doesn't restart when it goes away, only the browser engine exits.

But I don't understand why killing the UI helps, connection handling should be
done by the browser engine.

When this happens next time, could you try just killing the /usr/bin/browser
process?  Maybe it has somehow screwed up it's connection to the browserd 
engine process. Then I don't understand why browserd is using a lot of CPU
though (unless the issue is caused by something browserd does to the
connection).

Do you have any browser extensions installed?  (see comment 1)
Comment 10 Andre Klapper maemo.org 2010-08-01 12:39:36 UTC
Please answer comment 1.
Comment 11 Andre Klapper maemo.org 2010-12-13 18:14:49 UTC
Unfortunately, without more information, as requested in one of the last
comments, we are unable to do anything more about this report. Until more
information is available, I'm resolving the report as INVALID.
Please feel free to reopen this bug if you can provide the information asked
for in comment 1, and if you can still reproduce this in 20.2010.36-2.