Closed Bug 633728 Opened 9 years ago Closed 9 years ago

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

Categories

(Firefox :: Installer, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 4.0b12
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: scoobidiver, Assigned: rstrong)

References

Details

(Keywords: regression, Whiteboard: [hardblocker])

Attachments

(1 file)

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.
Summary: After an update, the Firefox shorcut on the desktop is moved to the top right cornernr → After an update, the Firefox shorcut on the desktop is moved to the top right corner
Can you provide a regression window for when this started happening?
Unable to reproduce with both 32 and 64 bit Firefox on Win7 64 bit.
I'll update for the next week with shortcuts for Firefox and other apps on my desktop to try to reproduce.
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).
Summary: After an update, the Firefox shorcut on the desktop is moved to the top right corner → After an update, the Firefox shorcut on the desktop is moved to the top left corner
This is likely due to refreshing the shell and the OS shell auto-arranging... we have always performed a refresh of the shell though.
Summary: After an update, the Firefox shorcut on the desktop is moved to the top left corner → After an update, the Firefox desktop shorcut is moved to the top left corner from a user set custom position
I am able to reproduce now... I'll try to find the cause later this week.
Assignee: nobody → robert.bugzilla
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.
Attachment #512919 - Flags: review?(jmathies)
(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?
Is there any chance we are deleting it a recreating it for some reason?
> 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.
(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.
Blocks: 621873
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 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.
Attachment #512919 - Flags: review?(jmathies) → review+
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.
Attachment #512919 - Flags: approval2.0?
(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.
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.
blocking2.0: --- → ?
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.
blocking2.0: ? → betaN+
Whiteboard: [hardblocker]
Attachment #512919 - Flags: approval2.0? → approval2.0+
Whiteboard: [hardblocker] → [hardblocker][has patch][can land]
http://hg.mozilla.org/mozilla-central/rev/4ff3881cac8c
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker][has patch][can land] → [hardblocker]
Target Milestone: --- → Firefox 4.0b12
Flags: in-testsuite-
Flags: in-litmus-
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.
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.
That would be fine... file a bug?
You need to log in before you can comment on or make changes to this bug.