Closed
Bug 768378
Opened 12 years ago
Closed 12 years ago
UpdateShortcutAppUserModelIds helper.exe operation creates a second taskbar icon when installed to a non standard location.
Categories
(Firefox :: Installer, defect)
Tracking
()
VERIFIED
FIXED
mozilla19
People
(Reporter: TheOne, Assigned: bbondy)
References
(Blocks 1 open bug)
Details
Attachments
(3 files, 1 obsolete file)
459.29 KB,
application/x-zip-compressed
|
Details | |
2.08 KB,
patch
|
jimm
:
review+
lsblakk
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta-
|
Details | Diff | Splinter Review |
1.09 KB,
application/octet-stream
|
Details |
Afer updating Aurora using the built-in updater, a new Windows 7 taskbar icon is shown (with the same icon), instead of using the icon I already pinned. This happens for every update, not just upgrading from one branch to another. This also happens on Thunderbird Beta builds.
Reporter | ||
Updated•12 years ago
|
Summary: Aurora and Beta build updates create a new Windows 7 taskbar icon instead of using the already pinned ones → Aurora and Beta build updates create a new Windows 7 taskbar icon instead of using the already pinned one
![]() |
||
Comment 2•12 years ago
|
||
For anyone running into this please check to see if the following registry key exist: 64-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\TaskBarIDs (installpath) = "hex string" HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\Mozilla\Firefox\TaskBarIDs (installpath) = "hex string" 32-bit systems: HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Firefox\TaskBarIDs (installpath) = "hex string" HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\TaskBarIDs (installpath) = "hex string" I noticed one odd taskbar id entry for my system, probably unrelated to this bug, named: "C:\Program Files (x86)\Nightly\updated" rs, bbondy, do we run an install update from within this sub directory?
Reporter | ||
Comment 3•12 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #1) > Andreas is your system 32 or 64 bit? My system is 64 bit. (In reply to Jim Mathies [:jimm] from comment #2) > For anyone running into this please check to see if the following registry > key exist: > > 64-bit systems: > > HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\TaskBarIDs > (installpath) = "hex string" This key does not exist. > > HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\Mozilla\Firefox\TaskBarIDs > (installpath) = "hex string" This key does not exist. > > 32-bit systems: > > HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Firefox\TaskBarIDs > (installpath) = "hex string" This key does not exist. > > HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\TaskBarIDs > (installpath) = "hex string" There are four entries: C:\Program Files (x86)\Aurora = 1E05176855CC7D2F C:\Program Files (x86)\Mozilla Firefox = E7CF176E110C211B D:\Programme\Mozilla\Firefox = 63EFDEFB3FF7EC0 D:\Programme\Mozilla\Firefox-beta = E8A04BEA0C0B2D52 The first two entries are clearly bogus, because I *never* installed Firefox into the default program files directory. The latter two paths are correct. Should I delete all the entries and let them get recreated?
Reporter | ||
Comment 5•12 years ago
|
||
(In reply to Siddhartha Dugar [:sdrocking] from comment #4) > This may be related to bug 734628. Indeed, my Aurora instance (D:\Programme\Mozilla\Firefox) had a leading space. However, removing it did not resolve the issue. I deleted the whole key, now the issue is resolved. However, the key did not get recreated (or maybe I won't see it until I reboot the machine?) Now, lets wait for the next Aurora update and see if it's happening again.
![]() |
||
Comment 6•12 years ago
|
||
These keys do not recreate unless an install or update runs. So if you delete them, firefox will revert to default grouping on the taskbar. (Meaning, Windows will choose how to handle the grouping based on factors like exe path and application name. The exact methodology isn't documented AFAICK.) Instead of deleting, leave the appropriate key based on your current install. If you have pinned shortcuts on the taskbar that don't match up with running instances, unpin them and repin the running instance.
Reporter | ||
Comment 7•12 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #6) > Instead of deleting, leave the appropriate key based on your current > install. If you have pinned shortcuts on the taskbar that don't match up > with running instances, unpin them and repin the running instance. That's what I did until now. But I had to do this on every Aurora update, which is several times a day.
![]() |
||
Comment 8•12 years ago
|
||
(In reply to Siddhartha Dugar [:sdrocking] from comment #4) > This may be related to bug 734628. I don't see why the space would matter. The string is just a random unique id. A space is just part of the ID we pass to windows. As long as this id gets set via the widget code here - everything should work. Now we have updated the logic here a couple times, so across a couple versions grouping may have broken. The last change we made was in Fx 14 in bug 740233. That change though should cause existing shortcuts to get updated shortly after first launch. Either way, after Fx 14 is installed and pinning is set correctly, there shouldn't be any new issues.
![]() |
||
Comment 9•12 years ago
|
||
Forgot the mxr link to widget code - http://mxr.mozilla.org/mozilla-central/source/widget/windows/WinTaskbar.cpp#240
![]() |
||
Comment 10•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #7) > (In reply to Jim Mathies [:jimm] from comment #6) > > Instead of deleting, leave the appropriate key based on your current > > install. If you have pinned shortcuts on the taskbar that don't match up > > with running instances, unpin them and repin the running instance. > > That's what I did until now. But I had to do this on every Aurora update, > which is several times a day. I don't see how this would break on every aurora update. If you have the key set and the key name equals your install location, the id set in widget will always be the key in the registry. Unless something is going wrong with the key retrieval code. If you have the ability to debug I'd love to know if the value is being set correctly. One way to do this would be to get the extension developer extension installed and query for the default id being used in the js shell - const Cc = Components.classes; const Ci = Components.interfaces; var taskbar = Cc["@mozilla.org/windows-taskbar;1"] .getService(Ci.nsIWinTaskbar); "'" + taskbar.defaultGroupId + "'"
Reporter | ||
Comment 11•12 years ago
|
||
Entering the following in the error console alert("'" + Components.classes["@mozilla.org/windows-taskbar;1"].getService(Components.interfaces.nsIWinTaskbar).defaultGroupId + "'"); returns Error: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIWinTaskbar.defaultGroupId] Source file: javascript:%20alert("'"%20+%20Components.classes["@mozilla.org/windows-taskbar;1"].getService(Components.interfaces.nsIWinTaskbar).defaultGroupId%20+%20"'"); Line: 1
Assignee | ||
Comment 12•12 years ago
|
||
The installdir/updated entry is probably left over from Bug 759615 where the PostUpdate process which re-creates all this shell integration stuff was running in error from the installdir/updated directory. How updates work since background updates landed in bug 307181 is that it runs the install into installdir/updated, then swaps in the installdir/updated to installdir afterwards when you restart the browser. The PostUpdate process then runs from installdir since the fix in the above bug landed.
![]() |
||
Comment 13•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #11) > Entering the following in the error console > Error: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff > (NS_ERROR_UNEXPECTED) [nsIWinTaskbar.defaultGroupId] How about the interface only? alert(Components.classes["@mozilla.org/windows-taskbar;1"].getService(Components.interfaces.nsIWinTaskbar)); unexpected would mean that: 1) The nsIXULAppInfo service cannot be retrieved 2) The app name cannot be retrieved from the app info service 3) GetModuleFileNameW failed 4) There is no back slash in the path retrieved from GetModuleFileNameW 5) The key (root)\Software\Mozilla\(appname)\TaskBarIDs\(path) doesn't match what's the installer set in your registry. 1-4 are unlikely, so I'm guessing the key path building might be at fault.
Reporter | ||
Comment 14•12 years ago
|
||
Sorry, I forgot to reimport the registry key I deleted earlier. alert("x" + Components.classes["@mozilla.org/windows-taskbar;1"].getService(Components.interfaces.nsIWinTaskbar).defaultGroupId); returns "x 63EFDEFB3FF7EC0" so, including the leading space. But now, the problem is (of course) back. I unpinned my current icon and pinned the new one. Now let's wait for a Aurora update and then query nsIWinTaskbar again.
Reporter | ||
Comment 15•12 years ago
|
||
So, Aurora update just ran. The snippet in comment 14 still returns the same. But, I have a new taskbar icon again :(
![]() |
||
Comment 16•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #15) > So, Aurora update just ran. The snippet in comment 14 still returns the same. > > But, I have a new taskbar icon again :( That is odd. The registration happens on first window creation, so, I don't think extensions could play a role. Possibly the registration is failing, but we don't have any way to debug that aside from building a debug build and stepping through the code with the debugger. http://mxr.mozilla.org/mozilla-central/source/widget/windows/WinTaskbar.cpp#326
![]() |
||
Comment 17•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #15) > So, Aurora update just ran. The snippet in comment 14 still returns the same. > > But, I have a new taskbar icon again :( Are you running Fx in compatibility mode?
![]() |
||
Comment 18•12 years ago
|
||
Also, in about:config, do you have a pref names 'browser.taskbar.lastgroupid' and if so, what's the value?
Reporter | ||
Comment 19•12 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #17) > Are you running Fx in compatibility mode? No. (In reply to Jim Mathies [:jimm] from comment #18) > Also, in about:config, do you have a pref names > 'browser.taskbar.lastgroupid' and if so, what's the value? " 63EFDEFB3FF7EC0"
![]() |
||
Comment 20•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #19) > (In reply to Jim Mathies [:jimm] from comment #17) > > Are you running Fx in compatibility mode? > > No. > > (In reply to Jim Mathies [:jimm] from comment #18) > > Also, in about:config, do you have a pref names > > 'browser.taskbar.lastgroupid' and if so, what's the value? > > " 63EFDEFB3FF7EC0" Ok so this is good, we aren't running the shortcut updater on first run.
![]() |
||
Comment 21•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #19) > (In reply to Jim Mathies [:jimm] from comment #17) > > Are you running Fx in compatibility mode? > > No. > > (In reply to Jim Mathies [:jimm] from comment #18) > > Also, in about:config, do you have a pref names > > 'browser.taskbar.lastgroupid' and if so, what's the value? > > " 63EFDEFB3FF7EC0" Andreas, if you go into the registry and remove that extra leading space from the string, does it fix the taskbar problem?
Reporter | ||
Comment 22•12 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #21) > Andreas, if you go into the registry and remove that extra leading space > from the string, does it fix the taskbar problem? No.
![]() |
||
Comment 23•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #22) > (In reply to Jim Mathies [:jimm] from comment #21) > > Andreas, if you go into the registry and remove that extra leading space > > from the string, does it fix the taskbar problem? > > No. Hmm, then this is something different from bug 734628. If anyone has this problem and has the ability to debug a build, please post. I'm interested in debugging this code - http://mxr.mozilla.org/mozilla-central/source/widget/windows/WinTaskbar.cpp#326
Reporter | ||
Comment 24•12 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #23) > Hmm, then this is something different from bug 734628. If anyone has this > problem and has the ability to debug a build, please post. I'm interested in > debugging this code - > > http://mxr.mozilla.org/mozilla-central/source/widget/windows/WinTaskbar. > cpp#326 I can setup an aurora debug build. Can you tell me what exactly to debug? Aren't there already precompiled nightly builds with debug enabled?
![]() |
||
Comment 25•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #24) > (In reply to Jim Mathies [:jimm] from comment #23) > > Hmm, then this is something different from bug 734628. If anyone has this > > problem and has the ability to debug a build, please post. I'm interested in > > debugging this code - > > > > http://mxr.mozilla.org/mozilla-central/source/widget/windows/WinTaskbar. > > cpp#326 > > I can setup an aurora debug build. Can you tell me what exactly to debug? > Aren't there already precompiled nightly builds with debug enabled? Yes, here's the most recent - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-06-27-mozilla-aurora-debug/ Place a breakpoint at the start of the method above and step through it to see what id actually gets set. The id is pulled from the registry in the function GetAppUserModelID.
![]() |
||
Comment 26•12 years ago
|
||
Reporter | ||
Comment 27•12 years ago
|
||
Jim and me found out that this happens if you install Firefox to another directory than the default one. When Firefox gets updated, the updater does not respect the install location and just updates the registry key for the default install location. Jim, any updates on this? Is there any chance we could this get fixed and checked in before the next merge?
Comment 28•12 years ago
|
||
I've been reporting the "double taskbar icon" at random since 27 May 2012 on mozillaZine Nightly build thread[1]. There's a duplicate icon right now on the taskbar on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120709035118 Is there anything I could provided to get this resolved? Should the bug be updated to include Nightly? 1 | http://forums.mozillazine.org/viewtopic.php?p=12015611&sid=d68f41cefe9a1bd81e3140a58d95921c#p12015611
Reporter | ||
Comment 29•12 years ago
|
||
Alex, thank you for your comment. Jim, correct me if I'm wrong, but I think we have all the information we need. We identified the cause of the problem, now it "just" needs to be fixed. :)
![]() |
||
Comment 30•12 years ago
|
||
(In reply to Andreas Wagner [:TheOne] from comment #29) > Alex, thank you for your comment. > > Jim, correct me if I'm wrong, but I think we have all the information we > need. We identified the cause of the problem, now it "just" needs to be > fixed. :) Yes, rstrong was going to look at the app id variable in the installer to be sure it was getting updated properly when someone changes the default install location. An easy work around is to let the installer choose the default location and install there.
Reporter | ||
Comment 31•12 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #30) > Yes, rstrong was going to look at the app id variable in the installer to be > sure it was getting updated properly when someone changes the default > install location. It would be really awesome if you fixed this before the next branch migration on July 16th, otherwise people would have to wait another six weeks. Especially for the people on Aurora, this is *very* annoying. Let me know if there's anything I can do to speed it up. > An easy work around is to let the installer choose the default location and > install there. For some users or in some environments, this is not really an option.
![]() |
||
Updated•12 years ago
|
Updated•12 years ago
|
Component: Widget: Win32 → NSIS Installer
Product: Core → Toolkit
Reporter | ||
Comment 33•12 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #30) > Yes, rstrong was going to look at the app id variable in the installer to be > sure it was getting updated properly when someone changes the default > install location. > > An easy work around is to let the installer choose the default location and > install there. As it seems no one is working on this, how can I check/fix this myself? Any hints about where to start are appreciated!
Reporter | ||
Updated•12 years ago
|
Summary: Aurora and Beta build updates create a new Windows 7 taskbar icon instead of using the already pinned one → Updates create a new Windows 7 taskbar icon instead of using the already pinned one
Comment 34•12 years ago
|
||
I thought this bug was specific to alpha/beta releases and bug 684477 was the general bug for normal releases.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → netzen
Reporter | ||
Comment 36•12 years ago
|
||
So, apparently this has been fixed somwhere in the Aurora 17 cycle. I don't know who did it, and I don't know whether it happened by accident, as a side effect of another bug or for purpose. But whatever changed didn't make it to the Thunderbird repository where this bug is still affecting all channels. As a lot of things are going to change with the Tb 17 release, let's try to find the fix asap, and maybe we can get this in before 17 ships.
Assignee | ||
Comment 37•12 years ago
|
||
I'm thinking based on Comment 36, this is probably a dupe of Bug 789743. I'm going to mark it as a duplicate of that, but if someone disagrees please un-dupe it.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•12 years ago
|
Assignee: netzen → nobody
Comment 38•12 years ago
|
||
I'm using FIREFOX_17_0b2_RELEASE now and saw this problem in the update from b1 to b2. But the problem of bug 789743 is solved ( the extra uninstall entry was removed). So, to me, the problem is steal there.
Assignee | ||
Comment 39•12 years ago
|
||
Was closed based on Comment 36. But re-opening now based on Comment 38. I'm curious to see if the fix in bug 734628 will solve this once it lands.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Comment 40•12 years ago
|
||
It is definitely fixed on current Aurora (18). The change that fixed this bug already landed in Aurora 17 as I couldn't reproduce it anymore after a few weeks on Aurora 17.
Assignee | ||
Comment 42•12 years ago
|
||
If you can reproduce with Nightly, can you confirm if it is fixed now?
Assignee | ||
Comment 43•12 years ago
|
||
Mak mentioned on IRC that he was getting a second icon now. It's probably due to the fix for the whitespace before the appusermodel id. I think we can probably fix this by always regenerating the shortcut files, I think when they already exist we skip it currently.
Comment 44•12 years ago
|
||
Yes this just happened to me today, the old icon is not used, tried restarting multiple times, just in case.
Assignee | ||
Comment 45•12 years ago
|
||
More info on Mak's problem. If the browser is closed there is only one icon. If he clicks the icon it opens a second taskbar icon.
Assignee | ||
Comment 46•12 years ago
|
||
So I confirmed that if you change the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\TaskBarIDs entry appusermodelid without the shortcut being updated, then it reproduces what Mak was getting. So for sure the problem is just that we need to re-create the shortcut.
Assignee | ||
Comment 47•12 years ago
|
||
For anyone that still has this problem: Could you check properties -> Compatibility tab For this file: "C:\Program Files (x86)\YOURINSTALLDIR\uninstall\helper.exe" Is the Run this program in compatibility mode turned on? Is it disabled or does it allow you to modify the value?
Assignee | ||
Comment 49•12 years ago
|
||
Sorry to bug you again Mak but could you get me this last piece of info? It'll allow me to check the properties on the shortcut and verify the hash length was less than 16. 1. Go to this location: C:\Users\Brian\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar 2. Right click on Nightly.lnk and select Send to -> Compressed (zipped) folder 3. Open regedit and navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\TaskBarIDs 4. Right click on it and select Export, save it to a reg file, and add it to the above zip. 5. Attach that zip to this bug
Assignee | ||
Comment 51•12 years ago
|
||
This took me a long time ot understand, but now it all makes sense :) In Bug 629275, we added code to fix LNK file AppUserModelID values inside browser/modules/WindowsJumpLists.jsm. The bug has been present since we did that, but the real problem wasn't caused by that bug. > // Win shell shortcut maintenance. If we've gone through an update, > // this will update any pinned taskbar shortcuts. Not specific to > // jump lists, but this was a convienent place to call it. > try { > // dev builds may not have helper.exe, ignore failures. > this._shortcutMaintenance(); <------------------------------------ > } catch (ex) { > } This code is fine, but it launches helper.exe with the command line args /UpdateShortcutAppUserModelIds, and that has a bug in it. > Function .onInit > ; We need this set up for most of the helper.exe operations. > !ifdef AppName > ${InitHashAppModelId} "$INSTDIR" "Software\Mozilla\${AppName}\TaskBarIDs" > !endif > ${UninstallOnInitCommon} The problem is that UninstallOnInitCommon is the thing that properly sets $INSTDIR, so if we call InitHashAppModelId before properly setting $INSTDIR then we get the hash of the default path. The bug was introduced in bug 577867 where we introduced all of this AppUserModelID hashing. The bug DOES NOT happen on /PostUpdate operations because we call ${InitHashAppModelId} both in .onInit and then again inside /PostUpdate in shared.nsh. The second call gets the correct value. The bug DOES happen for /UpdateShortcutAppUserModelIds because we only call ${InitHashAppModelId} in .onInit. Unfortunately I could only sometimes reproduce this, and that was the times that I left my browser open so that the jump list code would execute which calls /UpdateShortcutAppUserModelIds. The old InitHashAppModelId used to use the last saved value, but that created duplicate icons when you had a 15 char hash. With the 15 char hash, the appusermodelid on the lnk file was a correct 15 char hash, but the one in registry was a 16 char hash, and on startup we set the value to what's in the registry, creating a second icon.
Assignee: nobody → netzen
Attachment #675954 -
Flags: review?(jmathies)
Assignee | ||
Comment 52•12 years ago
|
||
For reference, this code inside UninstallOnInitCommon is what sets the value of INSTDIR correctly away from the default installation path:
> ${GetParent} "$EXEDIR" $INSTDIR
> ${GetLongPath} "$INSTDIR" $INSTDIR
Assignee | ||
Comment 53•12 years ago
|
||
...And since UninstallOnInitCommon is the thing that handles the command line args, we have to set the AppUserModelId in the middle of that function right after we get the correct value for the INSTDIR.
Attachment #675954 -
Attachment is obsolete: true
Attachment #675954 -
Flags: review?(jmathies)
Attachment #675955 -
Flags: review?(jmathies)
![]() |
||
Updated•12 years ago
|
Attachment #675955 -
Flags: review?(jmathies) → review+
Assignee | ||
Comment 54•12 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/26d9f5a3c57e
Target Milestone: --- → mozilla19
Comment 55•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/26d9f5a3c57e
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•12 years ago
|
Assignee | ||
Comment 56•12 years ago
|
||
If this is marked for tracking you should also take bug 734628. I'm not sure if this fix will work without that one.
Comment 57•12 years ago
|
||
Just to be sure, was this supposed to just fix the possibility of the issue to happen again, or should it also fix already "broken" situations by using again the original icon? Cause today's nightly is still not using the old icon, but that may be expected, depending on the above (I didn't touch anything from when it happened to avoid polluting any eventually needed test).
Assignee | ||
Comment 58•12 years ago
|
||
There is definitely a chance to have more than one different problem with the same side effects. I know of a couple different cases already. If you still have 2 taskbar icons afater keeping the browser open for a couple minutes, then closing, then re-opening, then please do the steps in Comment 49 and post the results here. We'll probably do a spin off bug to investigate your issue more. I can tell you a couple of things to do that may fix it, but I'd rather keep your machine in the bad state so we can get the needed info first.
Comment 59•12 years ago
|
||
here it is. I don't have issues with fixing the problem by myself, I explicitly didn't fix it to ensure testing this bug fix, so don't worry I can survive with 2 icons yet :)
Assignee | ||
Comment 60•12 years ago
|
||
Mak: So we get double taskbar icons when the registry AppUserModelID != AppUserModelID of the shortcut. Your Nightly.lnk has the following: - Points to the Mozilla Firefox installation dir: C:\\Program Files (x86)\\Mozilla Firefox - AppUserModelID: EEFEA8717BC47F65 Your registry has the following for the path C:\\Program Files (x86)\\Mozilla Firefox: - AppUserModelID: E7CF176E110C211B So the problem is that your lnk should have been updated to E7CF176E110C211B But instead it's using the appusermodel id of "C:\\Program Files (x86)\\Nightly"="EEFEA8717BC47F65". I'm going to move this into its own bug for further investigation.
Assignee | ||
Updated•12 years ago
|
Summary: Updates create a new Windows 7 taskbar icon instead of using the already pinned one → UpdateShortcutAppUserModelIds helper.exe operation creates a second taskbar icon when installed to a non standard location.
Comment 61•12 years ago
|
||
Tracking for 17 - can you nominate for branch uplift and provide details on the risk involved here as well as how many users we're talking about - is this just 64 bit windows 7 users?
Assignee | ||
Comment 62•12 years ago
|
||
(In reply to Lukas Blakk [:lsblakk] from comment #61) > Tracking for 17 - can you nominate for branch uplift and provide details on > the risk involved here as well as how many users we're talking about - is > this just 64 bit windows 7 users? If you take this and bug 734628 into account, I think it depends on what the path hash works out to. If it works out to less than 16 chars then I think you can reproduce. I think installs to Windows x86 with Firefox 86 will reproduce and maybe Thunderbird is more often.
Comment 63•12 years ago
|
||
On further review this looks like it has been in the code since 16 or maybe even 15 and with no dupes and support reports I suspect it's not affecting users too widely. The fix in this bug and bug 734628 can ride the trains unless there's something I'm missing here.
Assignee | ||
Comment 64•12 years ago
|
||
Comment on attachment 675955 [details] [diff] [review] Patch v2. [Approval Request Comment] Bug caused by (feature/regressing bug #): Unknown, I think it's been there since we started pinning taskbar icons User impact if declined: If the user installs to an alternate directory, other than the default install location, they can have 2 icons in the taskbar. Testing completed (on m-c, etc.): Has been on m-c for a bit. Risk to taking this patch (and alternatives if risky): Low String or UUID changes made by this patch: none.
Attachment #675955 -
Flags: approval-mozilla-beta?
Attachment #675955 -
Flags: approval-mozilla-aurora?
Comment 66•12 years ago
|
||
Comment on attachment 675955 [details] [diff] [review] Patch v2. Risk might be low, but I'm not convinced there's enough cause to take this up to beta so late in the cycle. Approving for Aurora.
Attachment #675955 -
Flags: approval-mozilla-beta?
Attachment #675955 -
Flags: approval-mozilla-beta-
Attachment #675955 -
Flags: approval-mozilla-aurora?
Attachment #675955 -
Flags: approval-mozilla-aurora+
Updated•12 years ago
|
Assignee | ||
Comment 67•12 years ago
|
||
http://hg.mozilla.org/releases/mozilla-aurora/rev/0e92ef50811e
status-firefox19:
--- → fixed
Reporter | ||
Updated•12 years ago
|
Reporter | ||
Updated•12 years ago
|
Status: RESOLVED → VERIFIED
Comment 68•11 years ago
|
||
Hi all I have installed FF on a non-default path (Windows 7 64-bit), and use the auto-updater. This problem with pinning has been going on for at least one year, probably even longer (I guess at least since FF16, maybe earlier). The "solution" is to unpin the original icon and pin FF again to the taskbar. This is the same bug as 729930 and 806309, and this bug has not been fixed as of yet (FF27). I hope this information helps. Thank you. -- Danai
Updated•1 year ago
|
Component: NSIS Installer → Installer
Product: Toolkit → Firefox
You need to log in
before you can comment on or make changes to this bug.
Description
•