Bug 3705 – Browserd is a Problem Rather Than Solution and May Have To Be Reworked

Bug 3705 - Browserd is a Problem Rather Than Solution and May Have To Be Reworked


Summary:	Browserd is a Problem Rather Than Solution and May Have To Be Reworked

Status:	RESOLVED INVALID

Product:	Browser
Component:	MicroB engine
Version:	4.1.1 (4.2008.30-2)
Platform:	ARM Maemo

Importance:	Medium normal with 3 votes (vote)
Target Milestone:	---
Assigned To:	unassigned
QA Contact:	microb-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2008-09-13 13:04 UTC by luarvique
Modified:	2008-10-18 17:00 UTC (History)
CC List:	2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description luarvique (reporter) 2008-09-13 13:04:49 UTC

SOFTWARE VERSION:
4.2008.30-2

STEPS TO REPRODUCE THE PROBLEM:
See bugs
https://bugs.maemo.org/show_bug.cgi?id=3703
https://bugs.maemo.org/show_bug.cgi?id=3704

ADVANTAGES OF BROWSERD:
Browser startup measurement times, between clicking the icon and showing the
"Connecting..." message, no AdBlock:

6.48s with browserd running
8.73s without browserd running (i.e. it has to be started)

This is a 2.25 second difference, negligible when compared with page loading
times. In other words, browserd does not provide any significant advantages in
terms of browser startup time.

DISADVANTAGES OF BROWSERD:

1. Difficulty killing hung browserd. It is not a real application and can only
be killed using 3rd party tools (CPU load applet, etc) not available to novices
on stock tablets.

2. Memory leaks. By its nature, browserd has to share big amounts of memory
with its client (MicroB). When browserd dies, the shared memory continues to be
unavailable to other applications.

3. Memory waste. Always-running browserd takes ~5-7MB of memory (htop result),
even when nobody is using it. If we consider shared libraries used by browserd,
we get 11-17MB memory footprint.

EXPECTED OUTCOME:
Browserd should not hang, crash, or leak memory. Browserd should give some
practical advantage in terms of browser startup time.

ACTUAL OUTCOME:
Browserd hangs, crashes, leaks memory. Browserd does not give any practical
advantage in terms of browser startup time.

REPRODUCIBILITY:
always

OTHER COMMENTS:
Please, either get rid of browserd completely or make it optional, in the same
way as Python startup accelerator is optional.

Comment 1 Faheem Pervez maemo.org

2008-09-13 19:06:36 UTC

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

Comment 2 luca 2008-09-13 20:47:43 UTC

I suspect that bug #3504, bug #3627 and bug #3506 are a byproduct of a
miscommunication between the daemon and the front ends, so they're probably
related to this bug.

Comment 3 timeless 2008-09-13 23:20:13 UTC

sorry. this isn't the way the bug system is supposed to be used.

Comment 4 luarvique (reporter) 2008-09-13 23:25:23 UTC

(In reply to comment #3)
> sorry. this isn't the way the bug system is supposed to be used.
Please elaborate why you do not consider this a valid bug report, given that it
describes an actual problem with the current MicroB.

Comment 5 timeless 2008-09-13 23:46:45 UTC

1. the summary is meaningless and has Super Duper Caps.
that's just bogus.
2. it has a spelling error, which means you aren't even asking for anything
3. It has May, which if you bother to read the RFC you'd find means that
perhaps "it may not ...". And we've chosen that.
4. bugs should be about a single item, not multiple items (you list three
disadvantages, each of which is a distinct item)
5. go look at google chrome's design, they too use browser engines out of
process. We're only using one rendering process today unlike chrome which has 1
per tab, but it's still the standard design for the future (note that ie8 also
does this).

ignoring that, you're making a statement, not describing a problem. bugzilla is
about bugs, this isn't a bug (INVALID).

about your description, you actually do describe a number of distinct bugs
under disadvantages:
1 - browserd isn't easily killable, and yes, the ui should offer a way to kill
the daemon if it isn't responsive, that'd be a perfectly reasonable bug to
file)
now please don't reopen this bug.
2 - you claim browserd needs to share a lot of memory with the client which btw
is not microb, microb is the engine, the ui is called tablet-browser (i should
know, i named both), discussing whether this is true deserves its own bug plus
evidence in the form of output from sp-memusage or sp-smaps-measure or some
other real tool which can show such "sharing".
3 - this is a design choice, we've made it, you are free to uninstall the
browser if you like (yes, it voids your warranty, and yes it'll make upgrading
a pain, however if you enable swap, and don't use the browser then it'll be
swapped out and cost nothing)

one of our requirements is that the browser ui be responsive while the
browser-engine is hung, this isn't practical w/o a distinct process (see again
chrome and ie8)

Comment 6 luarvique (reporter) 2008-09-13 23:52:11 UTC

I am sorry, but none of your arguments for closing this bug sound valid.
Instead, they seem to indicate that you have some personal stake in the current
MicroB design. Given that I have been threatened to be banned from the bug
tracker, I will not reopen or comment on this bug any more. Thanks for
clarifying things though.

Comment 7 Kamen Bundev 2008-09-14 03:02:31 UTC

You seem to mention Chrome and IE8 several times. Do they tend to leave their
processes running after closing?

Comment 8 Andre Klapper maemo.org

2008-09-15 13:46:08 UTC

Ah, lovely edit wars. After reading this I assume there have been some
conflicts in opinion before, guys? :-)

General comments: If a developer states that it's a design choice a report can
be indeed closed as WONTFIX or INVALID.

@timeless:
> it has a spelling error, which means you aren't even asking for anything
You know that this style unappropriate and does not really help tracking the
underlying issues down.

@luarvique:
IMO it's valid criticism that the original report is vague and covers several
things. See https://bugs.maemo.org/page.cgi?id=bug-writing.html .
I don't consider #1 as a bug either. Not everything needs to be killable by a
user, instead the bugs that trigger the problems you see should be tracked
down.
"Browserd should not hang, crash, or leak memory." is a perfect state that we
want to have for EVERY application. To help tracking memory issues down it
would be very helpful to get valgrind (http://maemo.org/development/tools/)
logs of the memory leaks you face.

I'd like to encourage you to file those issues seperately after investigating a
bit more, but "Kill browserd!" is something I would close as INVALID, too,
because it's been a design decision that won't be changed.

Can we now get back to normal mode, please? Thanks.