Closed Bug 89220 Opened 23 years ago Closed 15 years ago

ie favorites in non-standard location are not functional

Categories

(SeaMonkey :: Bookmarks & History, defect, P3)

x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: oterman, Unassigned)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628 BuildID: 2001062815 On a lot of Mozilla builds up through 0.9.2 Imported IE Favorites won't work. When I click on any favorite, the browser shows something like this: [DEFAULT] BASEURL=http://www.menfak.no/bibel/ [InternetShortcut] URL=http://www.menfak.no/bibel/ Modified=D02DF9D3C1BFC0010A Reproducible: Always Steps to Reproduce: 1. Click on an Imported IE Favorite Actual Results: Browser shows [DEFAULT] BASEURL=http://www.menfak.no/bibel/ [InternetShortcut] URL=http://www.menfak.no/bibel/ Modified=D02DF9D3C1BFC0010A Expected Results: Mozilla should have opened the URL instead of showing the properties of the favorite.
Using Build 2001071803 on Win2000 I have no problems using the imported IE favorites. They load just as well as any other bookmark. (Same for Win98) Try upgrading to a nightly build to see if you still experience the problem.
Using the same build as over (2001071803) the bug is no longer there.
I've reproduced this one. It seems to be a side effect of copying out your ie favorites to a different folder (in my case the root of bookmarks). Using build 2001072108
confirming based on the comment from mike@prog99.com
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 94955 has been marked as a duplicate of this bug. ***
From duped bug 94955: When I drag a bookmark imported from Internet Explorer into a Mozilla bookmark folder, the program does not create a proper bookmark entry but creates a bookmark that points to the bookmark file of Internet Explorer. When I click on this bookmark, this appears in the browser window: [DEFAULT] BASEURL=http://overbyte.alexid.fr/frame_index.html [InternetShortcut] URL=http://overbyte.alexid.fr/frame_index.html Modified=C00C3E94F01BC1016B and not the expected page.
Summary: imported ie favorites are not functional → ie favorites in non standard location are not functional
*** Bug 100140 has been marked as a duplicate of this bug. ***
Don't want to be redundant, but this is from the duped bug above: When managing bookmarks, if you copy and paste from "imported IE favorites" into the personal toolbar, you are unable to move the resulting "icon"(?) until Moz is restarted. Other interesting notes: the right-click context menu is different than "normal" bookmarks created in Moz. You only have the option to Open, Find a bookmark, or Copy. I assume delete isn't offered since you can't delete the ORIGINAL IE "favorite", but I should certainly be able to delete it from my personal toolbar in Moz. I think I should also be able to rename it. Again, this only until Moz is restarted. Other stuff on the same topic: When managing bookmarks, the location shows up properly for the copied-and-pasted favorite/bookmark, but when the properies button (properties not available in context menu) is pressed, the info is blank. No name, no location, nothing. Yet again, this only until Moz is restarted.After Moz is restarted, you can move "icons" on the personal toolbar, and the context menu is "normal", but properties yields a location of "file://" pointing to my favorites folder, then '/name.URL'
*** Bug 101119 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 56765 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Timeless: this isn't a dup of bug 56765. If you were trying to say "I don't think this should be fixed because it's not important in the short term and bug 56765 will eventually make this bug moot", you should have said so. Btw, I think this is more closely related to bug 69114, "Opening Internet Shortcuts dont work", although fixing that one without fixing this one would be a little weird (Mozilla would be using a different mechanism for following IE favorites in their default location than it would for following them in other locations).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: ie favorites in non standard location are not functional → ie favorites in non-standard location are not functional
Status: REOPENED → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.1
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.
Assignee: ben → pchen
Status: ASSIGNED → NEW
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
Blocks: 120814
*** Bug 140939 has been marked as a duplicate of this bug. ***
Favourites ".url" items now work ok as described below, however items moved/copied out of IE favourites are still read-only, and folders have locked contents. Bug #140939 has my description of the issue in more detail. I am not certain whether it qualifies as a dup of this bug or not, however the information is relevant to this one anyway.
Copied favorites is bug 69768.
*** Bug 206249 has been marked as a duplicate of this bug. ***
retargeting
Target Milestone: mozilla1.1alpha → Future
Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com
Assignee: bugs → ben_seamonkey
Product: Browser → Seamonkey
Assignee: ben_seamonkey → nobody
QA Contact: claudius → bookmarks
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
SM 2.0.1
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.