633728 - After an update, the Firefox desktop shorcut is moved to the top left corner from a user set custom position

Status: RESOLVED FIXED

(Firefox :: Installer, defect)

Description

[Scoobidiver (away)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110212 Firefox/4.0b12pre

When you apply a Firefox update, the Firefox shortcut on desktop is moved to the top right corner of the screen.
It is a recent issue.

Comment 1

[Robert Strong (they/them - no direct email)]

Can you provide a regression window for when this started happening?

Comment 2

[Robert Strong (they/them - no direct email)]

Unable to reproduce with both 32 and 64 bit Firefox on Win7 64 bit.

Comment 3

[Robert Strong (they/them - no direct email)]

I'll update for the next week with shortcuts for Firefox and other apps on my desktop to try to reproduce.

Comment 4

[Scoobidiver (away)]

I meant left instead of right.

I tried with a fresh profile and I could reproduce it in Minefield (en-US) (during the update download and after the update apply).
It has never happened in 64-bit Minefield (en-US) and Minefield (fr).

Comment 5

[Robert Strong (they/them - no direct email)]

This is likely due to refreshing the shell and the OS shell auto-arranging... we have always performed a refresh of the shell though.

Comment 6

[Robert Strong (they/them - no direct email)]

I am able to reproduce now... I'll try to find the cause later this week.

Comment 7

[Robert Strong (they/them - no direct email)]

Attachment: patch - don't update the app model id for the desktop shortcut

Not sure how we can update the app model id for the desktop shortcut without causing this bug. Since we have other code that updates the pinned shortcuts I think this is the best compromise.

Comment 8

[Jim Mathies [:jimm]]

(In reply to comment #7)
> Created attachment 512919 [details] [diff] [review]
> patch - don't update the app model id for the desktop shortcut
> 
> Not sure how we can update the app model id for the desktop shortcut without
> causing this bug. Since we have other code that updates the pinned shortcuts I
> think this is the best compromise.

If it doesn't get updated, the shortcut won't group correctly if you drag it to the taskbar. Not sure that's what we want.

I can't reproduce this bug. I get nightly updates every day, and my minefield shortcut stays exactly where it is on the desktop. Is this a side effect of some sort of "auto-sort desktop icons" setting?

Comment 9

[Jim Mathies [:jimm]]

Is there any chance we are deleting it a recreating it for some reason?

Comment 10

[Scoobidiver (away)]

> Is this a side effect of some sort of "auto-sort desktop icons" setting?
My desktop shortcuts are only aligned on the grid.
My Windows Task bar is on the left instead of the bottom of the screen.

Comment 11

[Robert Strong (they/them - no direct email)]

(In reply to comment #8)
> (In reply to comment #7)
> > Created attachment 512919 [details] [diff] [review]
> > patch - don't update the app model id for the desktop shortcut
> > 
> > Not sure how we can update the app model id for the desktop shortcut without
> > causing this bug. Since we have other code that updates the pinned shortcuts I
> > think this is the best compromise.
> 
> If it doesn't get updated, the shortcut won't group correctly if you drag it to
> the taskbar. Not sure that's what we want.
> 
> I can't reproduce this bug. I get nightly updates every day, and my minefield
> shortcut stays exactly where it is on the desktop. Is this a side effect of
> some sort of "auto-sort desktop icons" setting?
I wouldn't be surprised if it is due to an auto-sort option since by default Win7 auto-sorts several areas in the UI. Though the desktop shortcut won't get updated the pinned ones do and though I would prefer updating it having the shortcut move after an update is annoying.

btw: we haven't been updating the desktop shortcut app model id prior to the landing of bug 621873.

(In reply to comment #9)
> Is there any chance we are deleting it a recreating it for some reason?
I am quite certain the shortcut isn't deleted / recreated. Also, I am able to reproduce and have also verified that not updating the desktop short app model id fixes this bug.

Comment 12

[Robert Strong (they/them - no direct email)]

Steps to reproduce:
1. Add the default shortcuts using Set program access and defaults by checking the checkbox next to Minefield. If it is already checked uncheck it, apply, recheck it, and apply.
2. Move the desktop shortcut to the right of the desktop
3. Run as Administrator cmd.exe
4. cd to the working directory for the desktop shortcut.
5. cd to the uninstall directory.
6. run helper.exe /PostUpdate from the command shell.

The desktop shortcut moves from the right side of the desktop over to the left side.

Comment 13

[Jim Mathies [:jimm]]

Comment on attachment 512919 [details] [diff] [review]
patch - don't update the app model id for the desktop shortcut

Hmph. In my case my left hand side is full of icons w/minefield half way down; in this situation it doesn't happen.

For users with release builds I don't think it's a big deal. However dragging the icon down like you would do for quick launch and finding the grouping broken, might be annoying. 

On the flip side this will be annoying for beta testers. 

I hate "both options suck" bugs. :)

Maybe ask a driver about this? It's a hard call. Patch looks ok though for what you want to do.

Comment 14

[Robert Strong (they/them - no direct email)]

Comment on attachment 512919 [details] [diff] [review]
patch - don't update the app model id for the desktop shortcut

Drivers, this removes the updating of the app model id for the desktop shortcut after an update which is the way it was before bug 621873 landed. Without this patch if the user has moved the desktop shortcut so it isn't in the left hand side list of desktop shortcuts it will move back to the left hand side list after an update. With this patch we don't update the id in the shortcut that identifies Firefox when using this shortcut to pin via DnD. This is the way it was throughout the beta cycles and we didn't receive any bug reports about pinning Firefox using DnD on the desktop shortcut. This is an extremely low risk patch since it is only code removal and reverts us back to the way things were prior to bug 621873.

Comment 15

[Robert Strong (they/them - no direct email)]

(In reply to comment #14)
>...
> This is an extremely low
> risk patch since it is only code removal and reverts us back to the way things
> were prior to bug 621873.
specifically, the way things were regarding updating the app model id of the desktop.

Comment 16

[Robert Strong (they/them - no direct email)]

Asking for blocking to get on driver's radar though I don't think this should block. Though installer bugs aren't as sexy as other bugs this bug fixes an annoyance for any user that moves the Firefox shortcut on their desktop.

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

I actually think this is a hard blocker, hear me out: if the user's desktop icon moves, they can't start Firefox, and they can't use Firefox, and that's bad.

That's about it. Please land ASAP.

Comment 18

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/4ff3881cac8c

Comment 19

[Nochum Sossonko [:Natch]]

Ftr, a _lot_ of programs are annoying in this way (e.g. Adobe Reader). But I'm fairly certain that's because they delete and recreate the shortcut.

Comment 20

[Jim Mathies [:jimm]]

We should re-enable this on new installs. AFAICT, we don't set the id on the desktop shortcut at all, which seems like a mistake.

Comment 21

[Robert Strong (they/them - no direct email)]

That would be fine... file a bug?