768378 - UpdateShortcutAppUserModelIds helper.exe operation creates a second taskbar icon when installed to a non standard location.

Status: VERIFIED FIXED

(Firefox :: Installer, defect)

Description

[Andreas Wagner [:TheOne] [use NI]]

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.

Comment 1

[Jim Mathies [:jimm]]

Andreas is your system 32 or 64 bit?

Comment 2

[Jim Mathies [:jimm]]

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?

Comment 3

[Andreas Wagner [:TheOne] [use NI]]

(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?

Comment 4

[Siddhartha Dugar [:sdrocking]]

This may be related to bug 734628.

Comment 5

[Andreas Wagner [:TheOne] [use NI]]

(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

[Jim Mathies [:jimm]]

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.

Comment 7

[Andreas Wagner [:TheOne] [use NI]]

(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

[Jim Mathies [:jimm]]

(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

[Jim Mathies [:jimm]]

Forgot the mxr link to widget code - 

http://mxr.mozilla.org/mozilla-central/source/widget/windows/WinTaskbar.cpp#240

Comment 10

[Jim Mathies [:jimm]]

(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 + "'"

Comment 11

[Andreas Wagner [:TheOne] [use NI]]

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

Comment 12

[Brian R. Bondy [:bbondy]]

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

[Jim Mathies [:jimm]]

(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.

Comment 14

[Andreas Wagner [:TheOne] [use NI]]

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.

Comment 15

[Andreas Wagner [:TheOne] [use NI]]

So, Aurora update just ran. The snippet in comment 14 still returns the same.

But, I have a new taskbar icon again :(

Comment 16

[Jim Mathies [:jimm]]

(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

[Jim Mathies [:jimm]]

(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

[Jim Mathies [:jimm]]

Also, in about:config, do you have a pref names 'browser.taskbar.lastgroupid' and if so, what's the value?

Comment 19

[Andreas Wagner [:TheOne] [use NI]]

(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

[Jim Mathies [:jimm]]

(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

[Jim Mathies [:jimm]]

(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?

Comment 22

[Andreas Wagner [:TheOne] [use NI]]

(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

[Jim Mathies [:jimm]]

(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

Comment 24

[Andreas Wagner [:TheOne] [use NI]]

(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

[Jim Mathies [:jimm]]

(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

[Jim Mathies [:jimm]]

Attachment: linktool zip

Comment 27

[Andreas Wagner [:TheOne] [use NI]]

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

[alex_mayorga]

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

Comment 29

[Andreas Wagner [:TheOne] [use NI]]

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

[Jim Mathies [:jimm]]

(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.

Comment 31

[Andreas Wagner [:TheOne] [use NI]]

(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.

Comment 32

[Andreas Wagner [:TheOne] [use NI]]

rstrong, would you mind giving an update on this?

Comment 33

[Andreas Wagner [:TheOne] [use NI]]

(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!

Comment 34

[Onno Ekker [:nONoNonO UTC+1]]

I thought this bug was specific to alpha/beta releases and bug 684477 was the general bug for normal releases.

Comment 36

[Andreas Wagner [:TheOne] [use NI]]

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.

Comment 37

[Brian R. Bondy [:bbondy]]

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.

Comment 38

[Fernando Hartmann]

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.

Comment 39

[Brian R. Bondy [:bbondy]]

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.

Comment 40

[Andreas Wagner [:TheOne] [use NI]]

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.

Comment 41

[Fernando Hartmann]

Today I'm updated from b2 to b3 and the problem happened again.

Comment 42

[Brian R. Bondy [:bbondy]]

If you can reproduce with Nightly, can you confirm if it is fixed now?

Comment 43

[Brian R. Bondy [:bbondy]]

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

[Marco Bonardo [:mak]]

Yes this just happened to me today, the old icon is not used, tried restarting multiple times, just in case.

Comment 45

[Brian R. Bondy [:bbondy]]

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.

Comment 46

[Brian R. Bondy [:bbondy]]

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.

Comment 47

[Brian R. Bondy [:bbondy]]

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?

Comment 48

[Marco Bonardo [:mak]]

for me it's turned off and I can modify the value.

Comment 49

[Brian R. Bondy [:bbondy]]

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

Comment 50

[Brian R. Bondy [:bbondy]]

Ignore comment 49, I found a way to reproduce this.

Comment 51

[Brian R. Bondy [:bbondy]]

Attachment: Patch v1.

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.

Comment 52

[Brian R. Bondy [:bbondy]]

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

Comment 53

[Brian R. Bondy [:bbondy]]

Attachment: Patch v2.

...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.

Comment 54

[Brian R. Bondy [:bbondy]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/26d9f5a3c57e

Comment 55

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/26d9f5a3c57e

Comment 56

[Brian R. Bondy [:bbondy]]

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

[Marco Bonardo [:mak]]

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).

Comment 58

[Brian R. Bondy [:bbondy]]

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

[Marco Bonardo [:mak]]

Attachment: zipped lnk+reg

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 :)

Comment 60

[Brian R. Bondy [:bbondy]]

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.

Comment 61

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 62

[Brian R. Bondy [:bbondy]]

(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

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 64

[Brian R. Bondy [:bbondy]]

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.

Comment 65

[Brian R. Bondy [:bbondy]]

Re bug caused by, it is this one: bug 577867

Comment 66

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 67

[Brian R. Bondy [:bbondy]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/0e92ef50811e

Comment 68

[Danai Sae-Han]

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