Bug 6819 (int-146481)

Summary:	High CPU usage for 15 seconds after page loaded (Deleting History helps)
Product:	[Maemo Official Applications] Browser	Reporter:	Oskar <mail>
Component:	MicroB engine	Assignee:	tuukka.tolvanen
Status:	RESOLVED FIXED	QA Contact:	microb-bugs
Severity:	normal
Priority:	Low	CC:	andre_klapper, eero.tamminen, guy.salazar, marat, martin, petechap, sharedpp
Version:	5.0/(2.2009.51-1)	Keywords:	performance, use-time
Target Milestone:	5.0/(10.2010.19-1)
Hardware:	All
OS:	Linux

Description Oskar (reporter) 2009-12-10 18:21:49 UTC

SOFTWARE VERSION:
1.2009.42-11

EXACT STEPS LEADING TO PROBLEM: 
1. Start right after a fresh boot. Be sure you never opened the browser before
step 2.
2. Open any web page, e.g. 
http://www.google.com/m?client=ms-nokia-maemo&channel=bookmarks
3. Close the browser.
4. Re-open the same or any other web-page, e.g.
http://www.google.com/m?client=ms-nokia-maemo&channel=bookmarks

EXPECTED OUTCOME:
CPU usage is high while web page loads the second time, but drops back close to
idle as soon as web page is fully loaded.

ACTUAL OUTCOME:
CPU usage is high while web page loads the second time and remains high for
about 15 seconds after the page has rendered completely. During these 15
seconds, the CPU bar in the load applet hits the red area, "top" shows the
browser process at ~60% and the browserd at ~25% although there's nothing
happening the user would be aware of.
Also, during these 15secs, the browser is practically not responding to any
user interaction.


REPRODUCIBILITY:
Always on devices that are affected (like mine).
It seems a lot of people don't *ever* see this, though.

EXTRA SOFTWARE INSTALLED:
no ad-blockers or browser-plugins other than the pre-installed ones.

OTHER COMMENTS:
Note that for me, when I open the browser for the very first time after a
re-boot, this 15-sec-freeze does *not* occur. That's why I described the four
steps the way I did. The first time I use the browser, CPU usage always drops
as soon as the page is loaded - as it should.
I tried to work through various settings (cache size up/down, cache off,
javascript on/off, flash on/off), nothing changes this behavior.
There's a thread at t.m.o. about this:
http://talk.maemo.org/showthread.php?t=36569


User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.9.1.4)
Gecko/20091109 Gentoo Shiretoko/3.5.4

Comment 1 Per 2009-12-10 18:30:17 UTC

I can CONFIRM this exact behavior.

Comment 2 mvladu 2009-12-10 19:17:17 UTC

*** This bug has been confirmed by popular vote. ***

Comment 3 Oskar (reporter) 2009-12-11 15:10:04 UTC

More info:

User crail from t.m.o. reported he could solve the problem by clearing the
private data from the browser.

Reading that, I tried to go through the options in "clear private data" step by
step. I found out that deleting the "browsing history" is enough to solve this
for me. No need to touch cache, cookies etc.
(In fact, I started with deleting the cache first because I thought the cache
is more likely to be the culprit. Deleting the cache didn't help at all. It was
the history.)

Comment 4 PeteC 2009-12-11 16:16:54 UTC

My experience is similar, clearing out the history really made a difference to
my CPU load and general responsiveness.
I just wanted to point out another user's thread on TMO where (presumably) this
high CPU was hurting interactivity, again solved by clearing history:
http://talk.maemo.org/showthread.php?t=36703

Comment 5 Andre Klapper maemo.org

2009-12-31 17:06:03 UTC

Thanks for the investigations!

Comment 6 Guy Salazar 2010-01-05 06:08:36 UTC

I can confirm this issue with my N900. If the music is playing you can bet the
music will stutter.

Comment 7 Nagineni Sudarsana Babu nokia

2010-01-07 12:48:50 UTC

thanks for the report, we believe we have a fix for this.

we do not expect it will be available in the coming service release (which
people can test as 51-1), but hopefully it will be in the following one.

Comment 8 Per 2010-01-08 00:49:39 UTC

Good to see progress is being made on this.

Does this fix also correct the problems with history and thumbnails, that were
documented in the original thread for this problem ?(
http://talk.maemo.org/showthread.php?t=36569 )

Also, does this bug also correlate to the high cpu usage for 5-10 seconds after
placing the cursor in text boxes on websites, or does that need to be created
as a separate bug ?

Comment 9 PeteC 2010-01-08 02:33:43 UTC

(In reply to comment #8)
> Does this fix also correct the problems with history and thumbnails, that were
> documented in the original thread for this problem ?(

Do you mean https://bugs.maemo.org/show_bug.cgi?id=5684 ? I don't see any
progress on that one.

Best to assume that all issues are separate (& need separate bug reports)
unless a developer tells us otherwise

Comment 10 timeless 2010-01-08 02:46:43 UTC

This bug is very clearly related to history. A problem with text fields would
almost certainly be entirely unrelated. Cluttering this bug with questions
about it is unwelcome and hurts the ability for this bug to be fixed or
analyzed or whatever. If you have questions about how to use Bugzilla, please
ask on irc.freenode.net in #maemo-bugs

One thing we absolutely do *not* want is one generic bug "Browser is slow" and
one generic bug "Browser crashes". If we did that, we'd only need 5 bugs, and
we'd never be able to close them. There are a couple of system (reboot) bugs
which have been hijacked and suffer from this problem.

Oskar: thank you very much for your bug report and the analysis. I'm very sorry
to have had to pollute this bug and I hope never to have to do it again in this
bug tracker (although this is unrealistic).

PeteC: when we have a happier update, we'll indeed provide it in that bug.
Thank you for your patience.

Comment 11 Eero Tamminen nokia

2010-01-11 15:28:52 UTC

> My experience is similar, clearing out the history really made a difference to
> my CPU load and general responsiveness.

-> performance keyword.

Comment 12 tuukka.tolvanen nokia

2010-01-20 02:48:00 UTC

fixed @ 2010.02-6

Comment 13 Andre Klapper maemo.org

2010-03-15 20:51:23 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).