I think we need to indicate to some degree how turbo mode really works. The current wording is: Enable QuickLaunch (requires reboot) If anything, it needs to be somewhat explained in Help. (Also, why does it require a system reboot?)

->paw/jrgm, for turbo qa.

That is something for release notes perhaps. Startup folder items only get started on reboot, that's why the reboot. Assigning over to tpringle.

We could very easily run mozilla -turbo when the installer finishes. but that probably belongs in a different bug.

bug 87028 deals with the preferences wording.

Blake already fixed the bug that turbo required a restart (bug 89504). The pref text is now: Enable features that affect performance [ ] Enable Quick Launch Is this bug about text pref text or about documentation? The summary seems to indicate the former but the product/component indicates the latter.

todd - are we gonna do anything about this one?

I thought we already do explain this in Help. Ccing Jatin.

The original bug is a bit obsolete, since we no longer require a reboot for Quick Launch changes. The following passage is from the Netscape online help under "Using Quick Launch" and makes mention of Quick Launch memory consumption: "When you installed Netscape, you were given the option of enabling or disabling Quick Launch. If your computer is low in memory, or if you are have more then one profile, you can temporarily or permanently disable Quick Launch to conserve memory." Is this good enough?

It seems like somewhere we should clearly say that QuickLaunch uses some of your available memory, even when there are no windows open, in order to start the browser more quickly when you need it.

--> evelyn

Jatin - how about modifying the rel notes paragraph you mentioned to something like: "When you installed Netscape, you were given the option of enabling or disabling Quick Launch. When enabled, the Quick Launch feature will use some of your computer's available memory to be able to launch the browser more quickly. If your computer is low on memory, or if you are have more then one browser profile, you can temporarily or permanently disable Quick Launch." I'll also investigate letting users know about the Quick Launch memory usage via some other means - e.g. in the product when they enable/disable the feature.

Do we need to mention profiles? Very few users are aware of them, and there should be no problems with them in QL, so this might confuse people unnecessarily.

Since we are talking about release notes, I think it isn't a problem to state that you cannot access multiple profiles via Quick Launch, but perhaps there's a better place to do it. Jatin, is there a better place in the rel notes (e.g. a section on profiles) where we can mention not being able to use multiple profiles when enabling Quick Launch?

If we don't resolve the problem fully in the UI (and I don't think we should or will), the relnotes aren't the ideal spot for fully documenting the feature. The online help can capture much of the details discussed here, in the relevant sections on profiles and QL. And on the Netscape side, we can elaborate in the printed end-user's guide. CCing jgorham for that. We can also consider a tech article or even a tutorial on QL, for posting at help.netscape.com. Our (Netscape) Help and Product Support page (the page that appears when Help first opens) can direct users there.

Agree, re: solving the problem in the UI. 1) Let's make brief mention in the rel notes as encapsulated by the paragraph below. 2) Let's make sure to include the information in the client-side Help feature. 3) Let's also include the info in the end-user's guide. 4) Steve - the tech article or tutorial sounds like a great idea and a nice way to supplement the Help menu info. It isn't a top priority, but if your team would like to work/coordinate with help.netscape.com on something like that, I think it can only be beneficial to the end-user, while at the same time making the info available on the server-side.

What is the correct milestone to assign to this bug? Leaving it as --- seems wrong. Shouldn't this also be nominated for nsbeta1?

->rudman

-->Jatin. Can't set milestone appropriately yet---will ping Asa to adjust. nsbeta1+.

--> qa tpreston@netscape.com

not much time left, is this going to make mozilla1.0?

As I understand it we're going to fix this in the Help content. So the r/sr/a process and tree branchings don't affect this, it's really only the deadline for help content that matters.

Here is my suggested wording that will revise the Quick Launch section of commercial online help: -- REVISED TEXT -- When you installed Netscape, you were given the option of enabling or disabling Quick Launch. Quick Launch loads part of Netscape into memory when Windows first starts, and a part of Netscape will stay in memory after you close all Netscape windows. This lets Netscape quickly start up when you need it, without having to load all of Netscape. If your computer is low in memory, you can temporarily or permanently disable Quick Launch to conserve memory. -- END REVISED TEXT -- For the existing section that this wording revises, copy and paste the following URL in the commercial build: chrome://help/locale/nav_help.html#nav_quicklaunch I think this wording resolves the need for release notes on Quick Launch, especially given that profiles are less of a problem with Quick Launch now then previously.

If this is not a UI fix, then I don't think the nsbeta1+ is valid. Removing keyword (as "nsbeta1-" is not appropriate, either). Leaving bug open for now for tracking. Will mark as resolved when help content is checked in.

Steve, I'm not sure I understand your comment. We are using nsbeta1+ for all work that is needed for MachV, UI or otherwise. While you may have some arrangement that makes it unnecessary for help text changes, I don't think it is invalid.

Peter, if we were tracking every discrete bit of content that really needed to be added to the help content for Mach V, we'd have a helluva lot of nsbeta1+ bugs that currently don't exist, and I don't think we want them to exist. I thought I'd be doing you a favor by getting the bug off of the nsbeta1+ radar. It's only historical accident that the bug evolved into a purely doc bug (seems like the original bug might have been for UI as well). In any case, I'll reinstate nsbeta1+. But if this bug is nsbeta1+, then there are potentially many other bugs that should (or could) be opened with the same designation.

Steve- sorry, I wasn't trying to change your method, and certainly didn't mean to imply you should be marking doc bugs any differently. As I said, if you have some arrangement for doc bugs that obviates use of nsbeta, that's fine with me, it just sounded to me like you might be calling it invalid for other reasons. I guess I was still thinking this involved a UI change. One more reason why I try to avoid morphing...

accepting QA for mozilla developer docs. some of these bugs have been around for a _long_ time. Reporters, would you please review the bugs, see if the issues have been resolved, and close bugs appropriately. I will do a full review of all bugs not touched in one week (8th April). Thanks. </spam>

Changing component to user. Trying to get milestones updated for this product. Will update when able to.

The help now contains more information about how Quick Launch stays in memory. Copy and paste the following link in commercial trunk builds to see the updated section: chrome://help/locale/nav_help.html#nav_quicklaunch Marking FIXED

v