Closed
Bug 597387
Opened 14 years ago
Closed 14 years ago
Firefox update does not update the shortcuts in Windows 7
Categories
(Firefox :: Installer, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: a_nut_in, Assigned: jimm)
Details
Attachments
(1 file)
1.53 KB,
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6) Gecko/20100101 Firefox/4.0b6 Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6) Gecko/20100101 Firefox/4.0b6 When updating the firefox using built in update utility, the All Programs and jump list continues showing the old version of Firefox. E.g install firefox 4 beta 1 and upgrade to beta 4. the shortcuts continue showing beta 1 Reproducible: Always
Updated•14 years ago
|
Component: General → Application Update
Product: Firefox → Toolkit
QA Contact: general → application.update
Version: unspecified → Trunk
Comment 1•14 years ago
|
||
This is performed by the installer code as a post update action so changing component.
Component: Application Update → Installer
Product: Toolkit → Firefox
QA Contact: application.update → installer
Comment 3•14 years ago
|
||
I thought we *always* did this? I mean, I'm happy to have it change, and rarely like to override Rob Strong, sooo ... blocking final+!
Status: UNCONFIRMED → NEW
blocking2.0: ? → final+
Ever confirmed: true
Comment 4•14 years ago
|
||
This is for the Windows 7 jumplists that jimm implemented... for an unknown reason the jumplists in the start menu aren't being updated.
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #4) > This is for the Windows 7 jumplists that jimm implemented... for an unknown > reason the jumplists in the start menu aren't being updated. From the description, it sounded like a shortcut naming problem?
Comment 6•14 years ago
|
||
That would be it! We are going to rename the shortcuts for all beta builds to Firefox Beta per a newsgroup discussion so we don't have to one-off the installer code to handle betas differently.
Assignee | ||
Comment 7•14 years ago
|
||
also, fyi, beta 1 is installed in: "C:\Program Files (x86)\Mozilla Firefox 4.0 Beta 1\firefox.exe" upgrading to beta 6 keeps the beta 1 install location.
Comment 8•14 years ago
|
||
Right... per the newsgroup discussion both the shortcuts and the install location will both be named "Mozilla Firefox x.x Beta"
Comment 9•14 years ago
|
||
(In reply to comment #5) > (In reply to comment #4) > > This is for the Windows 7 jumplists that jimm implemented... for an unknown > > reason the jumplists in the start menu aren't being updated. > > From the description, it sounded like a shortcut naming problem? One thing I have personally experienced with the jumplists is that pinning a start menu shortcut to the start menu didn't have the same data (very minimal data to be exact) as when pinning the quicklaunch shortcut to the start menu. That is what I am concerned with in this bug and *think* that is also what the reporter was stating in comment #1 though I may be misinterpreting.
Assignee | ||
Comment 10•14 years ago
|
||
(In reply to comment #9) > (In reply to comment #5) > > (In reply to comment #4) > > > This is for the Windows 7 jumplists that jimm implemented... for an unknown > > > reason the jumplists in the start menu aren't being updated. > > > > From the description, it sounded like a shortcut naming problem? > One thing I have personally experienced with the jumplists is that pinning a > start menu shortcut to the start menu didn't have the same data (very minimal > data to be exact) as when pinning the quicklaunch shortcut to the start menu. > That is what I am concerned with in this bug and *think* that is also what the > reporter was stating in comment #1 though I may be misinterpreting. That would imply the start menu shortcut had the wrong AppUserModelID applied. I've not seen that locally but if you run into it please try and find an STR. FWIW I just pinned my nightly build start menu shortcut to the start menu and it has the right jump list. So it seems to be working in general, although something might be broken with the betas. I'll do some more testing to see.
Comment 11•14 years ago
|
||
It isn't working for me right now. This is with a default install from two days ago and each days it has been updated with a nightly update. The shortcut I pinned C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Minefield\Minefield.lnk The pinned shortcut C:\Users\rstrong\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu\Minefield.lnk Both point to "C:\Program Files (x86)\Minefield\firefox.exe" I have 5 items under frequent that are to say the least not frequent and only Enter private browsing under tasks. I have unpinned it and repinned it using the Start Menu shortcut and it still exhibits the same behavior. When I take my Quick Launch shortcut and pin it to the Start Menu everything shows up.
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → jmathies
Assignee | ||
Comment 12•14 years ago
|
||
Hmm so last night a dragged the shortcut from the startmenu to the taskbar and it didn't group. It had the app id it was ggiven on the initial install. This morning after an update, the taskbar shortcut merged with the running instance. So we seem to be updating the taskbar shortcuts on an update. What we aren't doing is updating the actual shortcut files created in the start menu. I can add some code to do that.
Assignee | ||
Comment 13•14 years ago
|
||
Attachment #485387 -
Flags: review?(robert.bugzilla)
Comment 14•14 years ago
|
||
Comment on attachment 485387 [details] [diff] [review] patch v.1 >diff --git a/toolkit/mozapps/installer/windows/nsis/common.nsh b/toolkit/mozapps/installer/windows/nsis/common.nsh >--- a/toolkit/mozapps/installer/windows/nsis/common.nsh >+++ b/toolkit/mozapps/installer/windows/nsis/common.nsh >@@ -6151,16 +6151,17 @@ > Exch $R9 ; stack: $R9, appid | $R9 = path > Exch 1 ; stack: appid, $R9 > Exch $R8 ; stack: $R8, $R9 | $R8 = appid > Push $R7 ; stack: $R7, $R8, $R9 > Push $R6 > Push $R5 > Push $R4 > Push $R3 ; stack: $R3, $R5, $R6, $R7, $R8, $R9 >+ Push $0 Please use $R2 here and elsewhere
Attachment #485387 -
Flags: review?(robert.bugzilla) → review+
Assignee | ||
Comment 15•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/29cfc088cf53
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•