Closed Bug 111714 Opened 23 years ago Closed 14 years ago

Integrate Preferences Toolbar into the main Mozilla tree

Categories

(SeaMonkey :: Preferences, enhancement)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: nikolai, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: helpwanted, perf) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.6+) Gecko/20011122
BuildID:    

Preferences Tree is a really cool feature, which adds functionality, which is
often mentioned as an advantage of the Opera browser - ability to turn the
images on&off, control onLoad popups, turn Java/Javascript on&off and many more.

Reproducible: Always
Steps to Reproduce:
1.Go to the URL above
2.Install the XPI
3.Enjoy and add comments to this bug :))
Keywords: helpwanted
This would be a performance hit for window opening.
Priority: -- → P5
Target Milestone: --- → Future
Are there proofs for this? I'm running CVS compiled mozilla with pref-bar and
it's running smoothly (on my k6-2 350/256 mb). I don't open new windows though
:)) Only tabs....
Yes, Bill Law has done some startup cost analysis.  We haven't analyzed the cost
of the pref-bar per se, but it can only add to window open and startup cost, not
help it.  :o)
> We haven't analyzed the cost of the pref-bar per se

Please do not condemn it without doing so.  And bear in
mind that it could be hidden via View->Show/Hide, could
even be hidden by default.  



You know, it really would have been nice if someone had CC'd me on this bug. :]
OK, here's the story.  I wrote my prefbar XPI because I really wanted this
feature and I didn't think it would ever be fixed if I didn't do it.  If anyone
has looked at my source code, you probably realize that I can't really check it
in in its present form.  And yes, I think it does add a fair amount to navigator
startup time, but not unless you have it enabled.  The onload function checks to
see if you have the toolbar showing, and if you don't it immediately exits
without doing anything.  So if this were enabled defaulting to off, the increase
in startup time that non users would see is that amount of time required to load
the toolbar (but not display it), one function call, and one if statement.  I
really don't know how long that is, but I don't think it is a whole lot.

I don't right now know what all the mozilla coding guildlines are, but if I we
had a developer willing to check this in (I have neither the authority nor the
CVS account required to do so) I would go through and optimize the entire
codebase to make it checkinable and faster.

If startup time is the issue preventing this from being put in, then if someone
could define what the limits are (i.e.,"it has to add less than x milliseconds
disabled, and y milliseconds enabled") I could rework this and try to make it
fit under such limits.  If there is currently a freeze on startup time such that
nothing which increases it by any amount is allowed in then I don't think there
is much I can do.

This is one of those bugs (maybe we need a keyword for this) where the fix is
pretty much sitting there waiting for us, we just have to decide if we (well,
actually the developers in charge) what to have it or not.

Aaron
Aaron,
Thanks for the comments.

> If there is currently a freeze on startup time such that
> nothing which increases it by any amount is allowed in then I don't think there
> is much I can do.

There is not only a "freeze" on increasing startup time but a large effort from
folks across the application front-end and back-end who are trying to reduce
startup time.  

> This is one of those bugs (maybe we need a keyword for this) where the fix is
> pretty much sitting there waiting for us, we just have to decide if we (well,
> actually the developers in charge) what to have it or not.
There is such a keyword: patch.  Add your patch here and then add the keyword if
you would like to take this bug.  You're welcome to reassign it to yourself.  

The performance problem is not just one of speed: it is one of footprint as
well.  The more code we add, the larger the jar files become.  The jar files are
held in memory during through the browser session lifetime.
I don't mean to sound discouraging.  I'm sure some folks would make good use of
this functionality.  Just presenting arguments in advance of you embraking on
work to integrate it into the browser.  At any rate, feel free to take this bug
if you'd like.
>There is not only a "freeze" on increasing startup time but a large effort from
>folks across the application front-end and back-end who are trying to reduce
>startup time.  

How does one measure the effect of a certain item on startup time?  I would like
to get some data on this before discussing the point any further.

>There is such a keyword: patch.  Add your patch here and then add the keyword if
>you would like to take this bug.  You're welcome to reassign it to yourself.  

Not quite.  I don't actually have a patch, I have a XPI add-on that doesn't
always work right.

The question is, should I even bother to make a patch.  You have provided some
good arguments for not checking this in, while others say it should be.  I don't
really care that much one way or the other.  Perhaps you could venture a guess,
if I had a patch that was relatively fast and light, what are the odds that it
would just site here in bugzilla for the rest of its natural life?

Also, I don't have the bugzilla permissions to take this bug, but if you would
like to assign it to me (and figure out what to do with 38521 while you're at
it) that would be great.

Aaron
See the performance pages on mozilla.org, specifically:
<http://www.mozilla.org/performance/startup-perf-brownbag.html>
Assignee: sgehani → kc7gza
>See the performance pages on mozilla.org, specifically:

Question: Is MOZ_TIMELINE enabled in the nightlys, or do I have to compile my
own build to use it?
Status: NEW → ASSIGNED
I'm sure dp can answer the question in comment 10.
MOZ_TIMELINE is not enabled in optimized builds and I think nightly builds are
optmized. So NO. You would have to build your own.
In that case, I won't be able to do any startup time tests unless someone knows
of a place I can acquire a build with MOZ_TIMELINE enabled without having to
compile my own, which I do not currently have time to do.

Aaron
> compile my own, which I do not currently have time to do.

If time is the only issue, just let it compile overnight
while you sleep or somesuch.  My problem is not having the
compiler needed (MSVC++ IIRC).  (Weird, that it will 
compile on Linux but on Windows requires a commercial
compiler...)
>If time is the only issue, just let it compile overnight
>while you sleep or somesuch.

My issue is that I've never compiled mozilla before, and I don't think I could
get all the stuff downloaded and GNU tools installed, and everything set up
correctly right now.
Keywords: perf
QA Contact: sairuh → nobody
I'm a bit confused. The Browser product in Bugzilla is for stuff in the Mozilla
tree. I filed bug 38521 because I thought Mozilla would be more usable overall
if there was a Preferences Bar in the Mozilla tree. This bug is about
integrating Aaron's Preferences Toolbar into the Mozilla tree. Surely, then,
this is a dup of bug 38521.

(I installed the XPI ten minutes ago, and I'm in love with it already.)
Throwing my $0.02 into the mix: I've recently been suggesting to a few friends
(some technically inclined, others less so) to try Mozilla, and the reluctance
to at least download the thing has consistently turned on one point: the
existence of the preferences toolbar.

This toolbar *empowers* users: a site has unreadable colors?  Turn them off!
Obnoxious javascript?  Off!  Etc.  It tells the user "you're in control",
instead of other browsers which convey a different attitude.

I think this should be part of the default distribution, and if the decision
were up to me it would be on by default (with an option in its context menu to
turn it off).  (Of course, if it were up to me, the personal toolbar would be
off by default, so the vertical crunch wouldn't be any worse.)

Bug 131518 is similar but distinguishable in having no user configurability.
*** Bug 189083 has been marked as a duplicate of this bug. ***
*** Bug 190707 has been marked as a duplicate of this bug. ***
*** Bug 190707 has been marked as a duplicate of this bug. ***
Quitting Evangelism due to lack of time...
Assignee: kc7gza → nobody
Status: ASSIGNED → NEW
Product: Browser → Seamonkey
Priority: P5 → --
QA Contact: nobody → prefs
Target Milestone: Future → ---
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
Extension Fodder. And the Prefbar extension works in SeaMonkey 2.0 so WONTFIX
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX

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