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)
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.
Comment 1•23 years ago
|
||
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.
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
confirming based on the comment from mike@prog99.com
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•23 years ago
|
||
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
Comment 7•23 years ago
|
||
*** 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'
Comment 9•23 years ago
|
||
*** Bug 101119 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
*** This bug has been marked as a duplicate of 56765 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 11•23 years ago
|
||
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
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.1
Comment 12•23 years ago
|
||
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
Comment 14•23 years ago
|
||
*** Bug 140939 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
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.
Comment 16•23 years ago
|
||
Copied favorites is bug 69768.
Comment 17•21 years ago
|
||
*** Bug 206249 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com
Assignee: bugs → ben_seamonkey
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•18 years ago
|
Assignee: ben_seamonkey → nobody
QA Contact: claudius → bookmarks
Comment 20•15 years ago
|
||
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
Comment 21•15 years ago
|
||
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
Comment 22•15 years ago
|
||
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
Comment 23•15 years ago
|
||
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
Comment 24•15 years ago
|
||
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
Comment 25•15 years ago
|
||
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
Comment 26•15 years ago
|
||
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
Comment 27•15 years ago
|
||
SM 2.0.1
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•