Quick Launch does not start

VERIFIED FIXED in mozilla1.0

Status

Core Graveyard
QuickLaunch (AKA turbo mode)
P1
critical
VERIFIED FIXED
16 years ago
6 years ago

People

(Reporter: Nagi Peters, Assigned: Bill Law)

Tracking

({regression})

Trunk
mozilla1.0
x86
All
regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt1][eta ??/??])

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020322
BuildID:    2002032203

In my Pref the QuickLaunch is checked. But after the start mozilla isn't started.
If i go to the pref do uncheck;check;OK -> Mozilla is in the taskbar.

Reproducible: Always

Comment 1

16 years ago
Seeing this for the past day or so as well.  Even choosing quick launch in
installer now doesn't enable it on startup either, though does place the
checkmark next to the item in preferences.  No matter what though quick launch
doesn't stick.  This is a very recent regression.  Saw this the same day as the
checkin that required a restart when chancing themes - don't know if that had
anything to do with it though.

Comment 2

16 years ago
confirming on build 2002032603
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

16 years ago
same been happenning to me for the last 3-4 nightly build on win2k

Comment 4

16 years ago
jelwell was the last person to touch quicklaunch, as part of bug 128377. If that
fix caused this, it needs to be backed out *immediately*.
Assignee: law → jelwell
Severity: major → critical
Keywords: mozilla1.0, nsbeta1, regression

Comment 5

16 years ago
investigating. i had QA test that quicklaunch still works before I checked in.

Comment 6

16 years ago
worksforme. tested on winXP build 2002032603.

Someone who it's not working for, please run regedit, and tell me what the value
for this key is:
HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Run/Mozilla Quick Launch

After I run the installer and select Quick Launch, my key says, '"J:\Program
Files\mozilla.org\Mozilla\Mozilla.exe" -turbo'. And when I reboot mozilla loads
in the System Tray just fine.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 7

16 years ago
um, I hope resolving as "worksforme" was a mistake.  Four people, including the
QA for this feature, have reproduced this.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 8

16 years ago
I just tested this on win2000 build 2002032603, and it works there as well. Even
over an existing Mozilla installation.

Comment 9

16 years ago
Blake: since when is it OK for you to reopen a bug if you don't even bother to
test? At least test it. Resolving WORKSFORME was not a mistake, standard
procedure says you need to reproduce in order to reopen. re-marking as WORKSFORME.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 10

16 years ago
the registry entry is correct, but the icon still doesnt appear. 
it only appears when i go into preferences and turn it off and on and press ok.
then its there.
if i exit mozilla and quick launch completly and start mozilla it again, it
doesnt come up again.

Comment 11

16 years ago
2002032603 comm build gives me this:

open perfs, enable quicklaunch
icon appears
close all windows
right click quicklaunch icon and exit
start moz/nscp again
no quicklaunch icon, pref is still checked.
seems broken to me.  -> REOPEN.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 12

16 years ago
oh, win2k also.

Comment 13

16 years ago
Turbo icon displays when reboot after an install-but it is not coming up after a 
relaunch. 
The registry entry is proper- installdir\netscp6.exe -turbo, pref is enabled 

this was not tested on test build as no install of test build was done- pref was 
saved and once viewed in prefs/advanced to confirm, icon was displayed. 

Comment 14

16 years ago
Jason: this never worked. I tried this with a 2002031503 build, from before my
checkin. If you DO NOT launch with -turbo, you won't get quicklaunch support
until you go visit the pref panel again.

open perfs, enable quicklaunch
icon appears
close all windows
right click quicklaunch icon and exit
start moz/nscp again
no quicklaunch icon, pref is still checked.
seems broken to me.  -> REOPEN.

So either this is INVALID, or a new bug and not a regression. Because mozilla
doesn't support quicklaunch unless you launch with the -turbo argument (which
normally only happens from the registry key).
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → INVALID

Comment 15

16 years ago
we are making heavy use of this feature, it always worked SURELY upto 0.9.8, not
100% sure about 0.9.9. you could start mozilla like normal and if quick launch
was enabled it stayed in the taskbar. no need to reboot or start with with a
special parameter.

Comment 16

16 years ago
If you'd like a feature where -turbo is not required to load quicklaunch (which
would be the case if you quit out entirely and relaunched) then reopen this bug,
assign it to law@netscape.com and mark it as a feature.

That would entail basically getting rid of the -turbo argument, and instead
always just checking the registry key for some value.

Comment 17

16 years ago
Law, Gbush: I'm not the owner of quicklaunch, so is this the desired behaviour?
I'm really just assuming it didn't ever work, because the builds I've been
working on haven't worked like this since I began working on the code in early
february.

I noticed blake also touched quicklaunch code, which would have been checked in
before the 2002031503 build I tested with that was also "broken". Blake, have
you looked at this?:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsNativeAppSupportWin.cpp&root=/cvsroot&subdir=mozilla/xpfe/bootstrap&command=DIFF_FRAMESET&rev1=1.57&rev2=1.58

Comment 18

16 years ago
but how can it be a new feature when it worked before ? i often killed
mozilla.exe via taskmanager, restarted mozilla.exe and quick launch was there.
was it taken out somewhere after 0.9.8 ?

Comment 19

16 years ago
ok. tested with 0.9.8 and it looks like this broke sometime between 0.9.8 and
March 15th 2002. reopening and reassigning to law.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 20

16 years ago
You have to specify a comment on this change. Please give some words on the
reason for your change.
Assignee: jelwell → law
Status: REOPENED → NEW

Comment 21

16 years ago
> Blake: since when is it OK for you to reopen a bug if you don't even bother to
> test?

Since four other people reproduced it already within the past 3 days, including
QA, who reproduced it with *today's build*.

> Resolving WORKSFORME was not a mistake, standard procedure says you need to 
> reproduce in order to reopen. re-marking as WORKSFORME.

And stated procedure (or just logic?) states that marking a bug WORKSFORME when
4 people can reproduce it doesn't make sense.  Where's the rule that a bug
doesn't exist if a developer can't reproduce it?

> Jason: this never worked.

It most certainly did work; I implemented it myself.

This works fine for me in my 3/20 nightly.  I'm going to try now in a 3/26
nightly.  Your checkin is in the timeframe and was a big overhaul of turbo, I'm
genuinely surprised by your apparent refusal to even review your changes.

Comment 22

16 years ago
law has been kind enough to point out the problem, and has asked me to take a look.
Assignee: law → jelwell

Comment 23

16 years ago
Created attachment 76366 [details] [diff] [review]
fixes this bug.

I apologize for marking this bug worksforme so hastily, but i could not
reproduce on my machines given the lack of a good testcase. Apparently
procedure has changed since I was QA Contact of Browser General so many years
ago, when it was ok to mark a bug worksforme if it didn't "work for me". ;)

Thanks to kerz for a reliable testcase and thanks to law for pointing out that
this "feature" even existed, and for pointing to the code where this feature
lives.

Comment 24

16 years ago
nsbeta1+, blocks 108795. 
Blocks: 108795
Keywords: nsbeta1 → nsbeta1+

Comment 25

16 years ago
Just so y'all know, 'worksforme' is defined as " All attempts at reproducing
this bug were futile, reading the code produces no clues as to why this behavior
would occur. If more information appears later, please re-assign the bug, for
now, file it. "

Comment 26

16 years ago
Created attachment 76444 [details] [diff] [review]
check file name and for -turbo
Attachment #76366 - Attachment is obsolete: true

Comment 27

16 years ago
Created attachment 76445 [details] [diff] [review]
last patch had some garbage in it.
Attachment #76444 - Attachment is obsolete: true
(Assignee)

Comment 28

16 years ago
Joe,

I'd lean towards leaving regvalue as type (array of) BYTE.  I think that would 
enable you to revert the call to ::RegQueryValueEx so it didn't cast and 
require the addition of the cast when you Assign() to regvalueholder.

Not a substantive change, I don't think.  But it would reduce the scope of your 
patch slightly, which is always good, I think.

And you must have some trailing whitespace or something on that first
"if (!mServerMode)" that shows up in your patch.

Comment 29

16 years ago
Created attachment 76467 [details] [diff] [review]
reducing scope. :)
Attachment #76445 - Attachment is obsolete: true

Comment 30

16 years ago
Created attachment 76468 [details] [diff] [review]
removed some other excess white space at the end of the function.
Attachment #76467 - Attachment is obsolete: true
(Assignee)

Comment 31

16 years ago
Comment on attachment 76468 [details] [diff] [review]
removed some other excess white space at the end of the function.

r=law
Attachment #76468 - Flags: review+

Comment 32

16 years ago
1. Find() I dont think does case insensitive find. Is that ok to do a case
sensitive compare ?

2. Can you add to bug what the cause of breakage was; why are we forcefully
checking for -turbo in your patch now when it wasn't required before.

Comment 33

16 years ago
Case sensitive is great, since we make the same call to get the filename when we
read it as when we write it.

The reason we're checking for -turbo explicitly now is because other
applications may add their own options to the key. So the key might exist, but
not have -turbo in it. Like "C:/foobar/mozilla.exe" -mail

In this case there's no -turbo, so we wouldn't want to load turbo mode.
Status: NEW → ASSIGNED

Comment 34

16 years ago
The reason for the breakage is this hard coded registry check does a filename
compare, rather than using nsIWindowsHook to find out if turbo mode is on.
nsIWindowsHook was recently generalized to allow more applications to add
options to the command line in the registry. As part of that process the
executable stored in the registry is now quoted - so the filename string compare
fails.

Comment 35

16 years ago
Great.

I am still a little unsure about the case senstive compare - eventhough we make
the same call to write and read, these calls are done on different sessions.
Like if the user typed in the name with different capitalization, would this
work ? (possibly wont ever happen). Conceptually, since the windows filesystem
is case insensitive, it seems right to do a case insensitive compare - all this
argument is flawed if GetModuleFilename() will normalize the string for us.

r=dp assuming you will *really* convince yourself that case sensitive compare is
the better thing to do ;-)

Comment 36

16 years ago
Grace: I've posted new builds at 
http://rocknroll.netscape.com/users/jelwell/publish/boot/

133120.zip = Mozilla build with this fix.
ns.zip = Commercial build.

Note that, just like before, you'll need to clear the quicklauch pref and then
turn it back on when you switch builds, or you'll still experience this bug.

Comment 37

16 years ago
*** Bug 134741 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 38

16 years ago
per syd, Mr. ADT today
Whiteboard: [adt1]

Comment 39

16 years ago
It still doesn't work properly with build 2002-04-04(03) on WinNT.
------------------
Here's my testcase:
- close browser
- right-click QuickLaunch taskbar icon and "Exit Mozilla"
- reload Mozilla

The Quicklaunch icon should reload but it doesn't.  If you go into Preferences /
Advanced and press OK, it reloads; you don't have to check or uncheck anything.

P.S.  Is this related to bug 121100 ?

Comment 40

16 years ago
*** Bug 135686 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 41

16 years ago
This fix has not been checked in yet.  Be patient!

Comment 42

16 years ago
Reassigning to Law. This is out of my hands, as the Quicklaunch functional tests
need to be approved in order to make sure enough testing has taken place on this
feature.
Assignee: jelwell → law
Status: ASSIGNED → NEW

Updated

16 years ago
OS: Windows 98 → All
(Assignee)

Updated

16 years ago
Whiteboard: [adt1] → [adt1][eta 4/9/02]

Comment 43

16 years ago
Comment on attachment 76468 [details] [diff] [review]
removed some other excess white space at the end of the function.

sr=blake

This whole file is woefully inconsistent in (foo) vs. ( foo ) style.
Attachment #76468 - Flags: superreview+
(Assignee)

Comment 44

16 years ago
Yes.  That's because the (foo) zealots never think to do it the right way when 
adding lines to files that are done the right way, and the ( foo ) adherents 
are too outnumbered (I think I'm the only one) to fight them off.

When the file gets so bad that I'm no longer permitted to add ( foo ), then 
that will be a sad day.

Comment 45

16 years ago
adding adt1.0.0 nomination
Keywords: adt1.0.0

Comment 46

16 years ago
adt1.0.0+ 
Keywords: adt1.0.0 → adt1.0.0+

Comment 47

16 years ago
Ading nsdogfood as this is touching several people in-house.
Keywords: nsdogfood

Comment 48

16 years ago
Comment on attachment 76468 [details] [diff] [review]
removed some other excess white space at the end of the function.

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #76468 - Flags: approval+

Comment 49

16 years ago
This seems very similar to bug 121100...worth a look.
(Assignee)

Comment 50

16 years ago
Fix checked in, branch and trunk.
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 51

16 years ago
I tried it again with todays nigthly 2002041503 Win98
and it doen't work (like #0).
Is it to early (fix not yet in this nigthly) or should i reopen the bug?
to reproduce:
1. start mozilla
2. set pref. = enable QuickLaunch
3. Close Mozilla (window and taskbar)
4. Start Mozilla => a new mozilla window, but no icon in the taskbar

Comment 52

16 years ago
this is fixed on branch 2002041512 and trunk 2002041603
added verified 1.0.0 keyword for branch, marking verified because working on both
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0

Comment 53

16 years ago
confirming WFM on build 2002-04-15 (1.0 branch) on WinNT
(Reporter)

Comment 54

16 years ago
Reopend, because it doen't work for me.
Tested like in #51 on Win98SE and Win2kProf.
Tested with:
latest 2002041803
latest-1.0.0 2002041814
rc1 2002041711
all talkback version
result: no icon in the taskbar and no mozilla.exe in the taskmanager
i'm trying with the wrong versions or isnt it fixed?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 55

16 years ago
wfm 1.0 rc1 on win2k, behaves just like it did pre0.9.8
(Reporter)

Comment 56

16 years ago
now i used the install-version and it worked.
i never used a installversion before, only talkback-version.
sorry for reopening
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 57

16 years ago
re verifying
Status: RESOLVED → VERIFIED

Comment 58

16 years ago
Please reopen the Bug,
the same error with the last nightly 2002042706 from the latest1.0.0

edit preference advanced enabled quicklaunch is enabled 
stop mozilla complett close quicklaunch
start mozilla - quick launch button is not displayed

OS:NT4
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 59

16 years ago
I'm not seeing the QL icon after installing NS build 2002042806 (latest
commercial 1.0 branch) either. ->p1/1.0, need new eta.
Priority: -- → P1
Whiteboard: [adt1][eta 4/9/02] → [adt1][eta ??/??]
Target Milestone: --- → mozilla1.0

Comment 60

16 years ago
confirming the regression.  On WinNT, the 2002-04-26 branch was ok, the
2002-04-29 pre-1.0 branch is broken again.
(Assignee)

Comment 61

16 years ago
OK, this is fixed on the branch again.  I screwed up when I landed this the 
first time and the fix got removed due to some CVS fixing-up.  I've just 
applied the fix again and tomorrow's build should be back to normal.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 62

16 years ago
verified on branch 2002043006
Status: RESOLVED → VERIFIED

Comment 63

16 years ago
adding as blocker to meta/tracking bug 75599.

Even though this bug is fixed, someone might want to clarify the Summary, e.g.
"regression in QuickLaunch restarting"
Blocks: 75599
Component: QuickLaunch (AKA turbo mode) → QuickLaunch (AKA turbo mode)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.