Closed Bug 104522 Opened 23 years ago Closed 23 years ago

QuickLaunch: There is no longer a dialog letting user know app is running in memory

Categories

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: tpreston, Assigned: law)

Details

(Whiteboard: [PDT])

Steps to reproduce:
1. Install NS and check the Use Quicklaunch for faster startup times when possible
2. If profile manager dialog appears, delete all but one profile
3. After NS comes up close the app by clicking the x in upper right or exit


Expected results: A dialog should appear to let the user know the app is running
in memory

Actual results: No dialog appears letting the user know the app is running in memory
duh, this was using w2k build 2001-10-12-05-0.9.4, working on when the 
regression occurred
I am seeing this also on WinNT.

This dialog is important to let users know that the program is still in resident.
Summary: There is no longer a dialog letting user know app is running in memory → QuickLaunch: There is no longer a dialog letting user know app is running in memory
nominate nsbranch. Should try to understand what happened to this dialog.  
Keywords: nsbranch
You sure you don't just have the pref off? (See about:config,
browser.turbo.enableDialog)
My about config shows:
browser.turbo.enableDialog is false.

I don't remember setting this to false.   How do I turn this back on?   Then, I
will test it some more.

However, Terri's finding on a new profile shows this dlg doesn't show up. 
nsbranch+
Keywords: nsbranchnsbranch+
This pref is set to false on my machine as well, changing to true and will 
continue to test (lchiang->you can change by opening file in any text editor, 
edit and then save)
Now I'm really confused.

Using today's commercial branch (2001-10-15) on Win98, I am not seeing the turbo
warning dialog on exit. I have 1 profile, and I used "Edit | Preferences |
Advanced" to enable turbo. 

I rebooted twice, and turbo runs after each reboot.

I cannot find a preference in about:config called "browser.turbo.enableDialog".

I did find 2 turbo preferences:
     browser.turbo.enabled - the value says "false" even though turbo is running
(I see the icon in the sys tray)

     browser.turbo.showDialog - the value also says "false" - but I have never
seen, nor dismissed, the turbo warning dialog.
I changed the pref for showing the Turbo Dialog on exit back to true.  However,
the mystery remains how this pref got set to false.
Sol: the browser.turbo.enabled pref is no longer used; the default entry needs 
to be removed from all.js but it should have no effect.

As for the dialog pref, I'll look into this when I get home.  It seems that 
all.js has no entry for browser.turbo.showDialog, which would mean it has no 
default value.  I don't remember if I just never added it (I assume I had, this 
used to work) or if someone inadvertently replaced it, but it sounds like the 
fix is as easy as adding the pref to all.js.

(Also, yes, the pref is showDialog not enableDialog, I was speaking from [bad] 
memory).
I'm not sure what the problem is.  The code seems to show the dialog by default,
for a new profile (you do have to delete all your profiles first, though,
because you can't turn Quick Launch on if you have more than one profile).

Once you have seen the dialog and dismissed it with the "Don't show this again"
checkbox checked, then the pref gets set and you no longer see the dialog. 
Ever, for that profile.

Now that might be the problem.  Should we turn that pref back to true when the
user turns Quick Launch back on?  Should we add another checkbox to the pref
panel so that the user can turn the warning back on?

The other thing is that the default setting on the dialog is to check the "Don't
show this again" checkbox, so the default is to only ever see the dialog once. 
That's probably why everybocy's prefs have browser.turbo.showDialog="false".
I always uncheck the checkbox whenever I dismiss the dialog so that I can see
this warning dlg over and over again.  And, I noticed one day, I never saw this
dlg again which is when I asked Terri to investigate.

If you were to follow Terri's original steps in this bug report on a branch
build, do you see the problem?
grace, pls turn trubo on, in a completely new profile (i.e. the system has never
had a profile on it), and test on all platforms. bill thinks this is working as
designed.
I don't think we need another checkbox. I think we should just make the default
for the 'Don't show me this again' checkbox be unchecked, so that the user has
to explicitly opt out of the warnings, even though I suspect most will want to
turn it off right away.  This would be an easy one line fix if we can confirm
that that's the problem.
I think you must have accidentally dismissed the warning dialog without
unchecking the check-box.  I do it myself all the time.  The only code that sets
the pref is in the dialog .xul file and if you have
user_pref("browser.turbo.showDialog",false) in your prefs.js, then you had to
have shown the dialog and closed it with the checkbox checked.

Another thing I just noticed is that we only show the dialog once per "session".
 I.e., if you run with Quick Launch and close the last window, you see the
dialog.  If you uncheck the checkbox and then open some more windows (without
exiting from the systray icon), then when you close the last of those windows,
you *don't* see the dialog.  If you exit via the systray, and then restart,
you'll see the dialog when the last window closes.  Probably we should show the
dialog all the time, when the last window closes.

Anyway, I opened a new bug to change the default for that checkbox: bug 104910.
 That would help, regardless of any other bugs.
My previous comment was to Lisa.

Blake, do you remember why we only show that dialog the first time the last
window closes in a session?
BTW, the problem of only one dialog per session seems to be bug 104872.
The problem of us only showing it once per session was filed in bugscape not
long before 6.1 shipped.  It was a one line fix, but I think the consensus was
that it wasn't important enough for 6.1, and possibly annoying.  We can revisit
that decision now if desired, hopefully in a public forum (104872 sounds good).
Grace is out. Let me get it checked out on a branch new system/profile.
Build: 2001-10-15-05-0.9.4(WIN)

Pinch hitting for Grace while she's out.

With no profiles established before installing, I do get the info dialog about
the browser running resident when I click the close box of the browser.  This
was successful on Win 2000, Win NT, and Win 98.

I cannot reproduce the problem as originally described.  This worksforme.
But wait there's more...

However, if you follow the exact steps as Terri describes, then the info dialog
does not appear upon exiting the browser.

Try it!

Thanks for proving I'm not crazy :-)
Blake's suggestion is a good one - we should leave the "Don't ask me again"
checkbox unchecked - we need to make it an explicit user action to deselect
seeing this warning.  Not sure why it wasn't that way before.

As for seeing this problem with Terri's steps, I'm not sure her steps are
representative.  I doubt many multi profile users are going to select Quick
Launch and then delete all their other profiles.  If the problem occurs in a
single profile (already existing) scenario, that would be a big problem.  Have
we tested that?
is this ready for tonight?
I deleted all profiles and reinstalled, the dialog does now appear w2k build 
2001-10-15-05-0.9.4, so if we made the change to have the dialog unchecked by 
default I believe we could close out this bug
With single profile from 6.1RTM, upgrading to next version does show me the info
dialog about QuickLaunch when exiting browser after starting up first time.
I think I know what I ran into - can someone confirm?

Many weeks ago, I ran 6.1 RTM with turbo "on" for a particular profile. I
dismissed the warning dialog that is the subject of this bug upon closing the
last window, and left the "don't show me this again" checkbox checked. 

I stopped using turbo for some time, and added a couple of test profiles. I then
upgraded to recent branch builds, and deleted all but 1 of my profiles - the
same profile in which I originally ran turbo. I then turned turbo on again - in
the recent branch build. 

If I'm understanding the comments in the bug correctly, the decision I made in
6.1 many weeks ago about not showing the dialog was remembered and respected in
recent branch builds. Correct?
Let's pls make the change per Blake's suggestion in tonight. 

"I think we should just make the default
for the 'Don't show me this again' checkbox be unchecked, so that the user has
to explicitly opt out of the warnings, even though I suspect most will want to
turn it off right away. "

Tentative PDT+, pending positive reviews.
who can work some magic tonight and get this one fixed?
Whiteboard: [PDT]
So, we've determined that this works the same as 6.1/0.9.2, and there is no
dataloss and no crash. PDT-
Whiteboard: [PDT] → [PDT-]
Hmm.  That seems random.  
Please, let's not morph this bug to change the checkbox; any such change
deserves a new bug, and some discussion. Please do *not* just check in a patch
without that.
Whiteboard: [PDT-] → [PDT]
Syd, this does not work the same way as in 6.1, the checkbox was unchecked by
default then.

The net result is that most users probably won't explicitly uncheck the checkbox
and so they won't be warned about information still being available to others in
the future.
Peter: okay, then it sounds like this bug is to reset the show dialog pref to
true upon turning off turbo mode.  Are that many users turning this on and then
going into Advanced prefs and then turning it off and then turning it back on?
Resolve this as Invlaid because it works as designed. A new Bug 104910 to change
the deafult has been opened and has a patch.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Looks good to me, marking verified
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.