Closed
Bug 753660
Opened 12 years ago
Closed 8 years ago
Installing an Application with an Icon, then Reinstall Same Application without Icon Causes Icon Inconsistencies between first & second install
Categories
(Firefox Graveyard :: Web Apps, defect, P2)
Tracking
(blocking-kilimanjaro:-, firefox16 wontfix)
People
(Reporter: jsmith, Unassigned)
References
Details
Steps: 1. Go to testmanifest.com 2. Select edit 3. Install the application generated 4. Notice the icon in the desktop shortcut, start menu, and add or remove programs 5. Alter the icons URLs to point to non-existing locations and save it 6. Reinstall the application Expected: The icon behavior should follow the second application installed. Meaning, the default app icon should be used in the start menu, desktop shortcut, the app in add or remove programs. Actual: Some inconsistencies occur. The desktop shortcut I noticed still had the icon of the first application installed that pointed to a valid icon. If the app was listed in the top of the task bar, then it contained the icon of the first application installed. If you search for the application, you would notice that the application would not have an icon attached to it. In add or remove programs, the icon shown is an executable icon. Overall, 3 icons appear - this isn't correct.
Reporter | ||
Updated•12 years ago
|
Priority: -- → P2
Target Milestone: --- → Firefox 15
Reporter | ||
Comment 1•12 years ago
|
||
Nominating for k9o - relates to basic install flow when an app developer changes their icon for their app.
blocking-kilimanjaro: --- → ?
Updated•12 years ago
|
blocking-kilimanjaro: ? → -
Updated•12 years ago
|
Target Milestone: Firefox 15 → ---
Comment 2•12 years ago
|
||
Jason, when you reinstall an application the old shortcuts should be removed and re-created. Aren't they?
Reporter | ||
Comment 3•12 years ago
|
||
(In reply to Marco Castelluccio from comment #2) > Jason, when you reinstall an application the old shortcuts should be removed > and re-created. Aren't they? Doesn't look like it. If I launch the app, the app shows the default icon when no icon is provided. But the start menu and desktop shortcuts still have the icon from the 1st install.
Comment 4•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #3) > (In reply to Marco Castelluccio from comment #2) > > Jason, when you reinstall an application the old shortcuts should be removed > > and re-created. Aren't they? > > Doesn't look like it. If I launch the app, the app shows the default icon > when no icon is provided. But the start menu and desktop shortcuts still > have the icon from the 1st install. Look at the file creation times for the shortcuts; that will tell you whether the shortcuts were re-created. It's likely that what you're experiencing is an icon caching issue (Windows caches the icons for the various shortcuts).
Reporter | ||
Comment 5•12 years ago
|
||
(In reply to Tim Abraldes from comment #4) > (In reply to Jason Smith [:jsmith] from comment #3) > > (In reply to Marco Castelluccio from comment #2) > > > Jason, when you reinstall an application the old shortcuts should be removed > > > and re-created. Aren't they? > > > > Doesn't look like it. If I launch the app, the app shows the default icon > > when no icon is provided. But the start menu and desktop shortcuts still > > have the icon from the 1st install. > > Look at the file creation times for the shortcuts; that will tell you > whether the shortcuts were re-created. It's likely that what you're > experiencing is an icon caching issue (Windows caches the icons for the > various shortcuts). Checked - it looks like the shortcut is not re-created, but the shortcut is marked as modified and accessed on the 2nd install.
Comment 6•12 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #5) > Checked - it looks like the shortcut is not re-created, but the shortcut is > marked as modified and accessed on the 2nd install. This is strange, as we are removing the shortcuts on reinstallation. Felipe, do you have any idea? Maybe followLinks is causing problems here?
Comment 7•12 years ago
|
||
Jason, could you check if in the installation directory there is a shortcut file? (it's a temp shortcut that we copy to the desktop and the start menu, that shout be created and removed during installation)
Reporter | ||
Comment 8•12 years ago
|
||
(In reply to Marco Castelluccio from comment #7) > Jason, could you check if in the installation directory there is a shortcut > file? (it's a temp shortcut that we copy to the desktop and the start menu, > that shout be created and removed during installation) Could you clarify where I need to look? Btw, watching the chrome/icons/default directory, the icon may not be getting overwritten for some reason (it's the same icon when I checked the directory directly). Can someone else confirm this behavior?
Reporter | ||
Updated•12 years ago
|
QA Contact: jsmith
Reporter | ||
Updated•12 years ago
|
status-firefox16:
--- → wontfix
Comment 9•8 years ago
|
||
Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•