Open Bug 59636 Opened 24 years ago Updated 6 years ago

Need UI for importing IE Favorites bookmarks

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: andre, Unassigned)

References

Details

(Keywords: parity-opera, Whiteboard: [2012 Fall Equinox]) 

unforunately you can only display IE bookmarks, not merge(copy) them into 
mozilla's bookmarks

It would be nice to have an option like that for
a) IE->mozilla switchers
b) users (like me) using both, to update the bookmark collection (held in 
mozillas bookmarks) by adding thoses held in IE favourites
That you can´t move/copy importet IE bookmarks to the Mozilla bookmarks is
alread reportet.
This is bug 56765.

duplicate

*** This bug has been marked as a duplicate of 56765 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified
Status: RESOLVED → VERIFIED
This is definitely not a dup of bug 56765, this bug is about really importing IE
favourites (i.e. when Mozilla is first started the IE favs folder is read and
the folder is converted into HTML bookmark representation and merged with the
mozilla bookmarks.html file.

It's another solution to the problem of IE favs not behaving like real
bookmarks, in my eyes fixing bug 56765 is the ultimate solution to the problem,
I proposed a possible stopgap solution in bug 101174 this is another possible
solution to the problem.

If it's decided not to implement this then mark it wontfix by all means, but I
think this is a valid RFE and if the favs are converted to bookmark format then
it automatically makes them manageable (but fixing this does not automatically
fix bug 56765 because changes made to the bookmarks.html file will not show up
in IE, but if bug 56765 is implemented then it'd be live editing of the IE favs
so the changes would show up in IE too)
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
See also bug 94465, [rfe] drag bookmark folder to desktop to create folder 
containing .url files, and vice versa.
Status: REOPENED → ASSIGNED
Target Milestone: --- → Future
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
*** Bug 111003 has been marked as a duplicate of this bug. ***
*** Bug 110991 has been marked as a duplicate of this bug. ***
*** Bug 116847 has been marked as a duplicate of this bug. ***
mass reassign of pchen bookmark bugs to ben
Assignee: pchen → ben
*** Bug 119557 has been marked as a duplicate of this bug. ***
It would be better if we made this a callable function from Bookmark Manager
then if we automatically imported the IE favorites.

There are two ways that IE favorites could be automatically added to the
bookmarks list kept by Mozilla. The first would be to import all IE favorites
permanently into bookmarks.html upon each Mozilla startup. The second would be
to do so only while a Mozilla session was active, not writing IE favorites to
the bookmarks.html file on disc. 

The first would be bad in some ways. If both IE and Mozilla had a duplicate
bookmark, what would you do? What if the Description/Title of the bookmark and
favorite were different, but the URI's were the same? 

Let's take another example of badness if this bug were fixed by automatic
importation. Let's say on Day 1 a user has 45 IE Favorites. He opens Mozilla and
they are all imported into Mozilla bookmarks.html. Then, he closes Mozilla. On
Day 2, he opens IE and changes the name of 12 of his IE Favorites. He closes IE.
He goes into Mozilla. Does Mozilla re-import the 12 renamed IE Favorites? How
does Mozilla decide? The logic would be complex.

The second would be bad, too. If IE temporarily imported all the IE Favorites,
but wouldn't add the IE Favorites to bookmarks.html on disc, it would get just
really messy.

What about users, like me BTW, who are die-hard Mozilla users, yet use IE for
some purposes, such as to access their bank accounts? Eventually Mozilla will
work with all the financial institutions, but right now my bank blocks Mozilla.
I keep a limited set of favorites in IE. Any web site that Mozilla can access, I
move to bookmarks.html in Mozilla.

What about users who are die-hard IE users, but download Mozilla to try it out?
If this bug was fixed, they would enter Mozilla and eventually notice that
Bookmarks has their IE Favorites. So they go through these Favorites/bookmarks,
modify some, delete a few, and add others. Then, they go back to IE and expect
to see the changes reflected in IE's Favorites. The user is disappointed.

Just my two cents, but I'd like to see this bug fixed by making this a function
that could be called from the Bookmark Manager. One implementation would be to
add a menu option under File of "Import IE Favorites." 

(At this point, it's important to say that right now, in Mozilla 0.9.7, under
the Bookmarks menu, the IE Favorites are listed as "Imported IE Favorites." In
my comment above, I'm talking about a different function entirely.)

Once the user clicks on "Import IE Favorites," all the LNK files would get
imported into Mozilla's bookmarks.html. This would be a solution that would
avoid all of the above problems.

Whoa.  I think there is way to much technical thought going into this.  Why not 
just a simple solution?  The first time Mozilla starts it could as if you'd 
like to have your IE Favorites imported (just like it does with old Netscape 
4.x profiles).  Anytime after that, just have an import option in the file menu 
to import your IE favorites.  Why is this so difficult to do?  Why is so much 
time being put into something that I would think would be very simple?
A one-time importation of IE Favorites would work just fine. I don't think
that's the current plan, however.

The summary is "converting IE bookmarks (not only displaying)," which implies
that IE Favorites will be converted each time Mozilla is run.
It may imply that, but does it have to mean that?  Besides that though, is it 
really that hard to import the favorites on each run, allow them to be 
modified, and then save them back to the disk when closing Mozilla?  I honestly 
don't know, that's why I ask, but I've seen plenty of little tools that let you 
go back and forth from Netscape bookmarks to IE Favorites, so I don't see why 
this should be that hard to implement.
*** Bug 122973 has been marked as a duplicate of this bug. ***
Blocks: 120814
back end for this with partial UI exposure will be done by .9.9. See patch in 106326
Status: NEW → ASSIGNED
Depends on: 106326
Target Milestone: Future → mozilla0.9.9
The back end for this is in, so resummarizing to state that this is now about
creating an import UI. Not likely before 1.0. 

To force a re-import manually, remove the pref
"browser.bookmarks.show_static_system_bookmarks" & a reimport will be performed
next time you start.
Summary: converting IE bookmarks (not only displaying) → need UI for importing IE bookmarks
Target Milestone: mozilla0.9.9 → Future
People who just want a one-time import can surely use IE's export feature?
No longer depends on: 106326
~~~
From Comment #13:
The first time Mozilla starts it could as if you'd like to have your IE
Favorites imported (just like it does with old Netscape 4.x profiles).  Anytime
after that, just have an import option in the file menu to import your IE favorites.
~~~

Possibly a better word choice if such a feature is added:
"Import/Update IE Favorites..."
 -or-
"Synchronize IE Favorites..."
Keywords: mozilla1.2
Add "Favorites" to summary so this bug can be found more easily.
Summary: need UI for importing IE bookmarks → Need UI for importing IE Favorites bookmarks
This bug started as an enhancement to allow IE Favorites to be properly imported
and integrated with Mozilla bookmarks, rather than just displayed as bookmarks
in Mozilla. However, IE Favorites are now imported only when a new profile is
created or by manually editing the pref file, so we need this bug fixed to
regain the functionality that was previously available.

Severity -> normal
Severity: enhancement → normal
*** Bug 168260 has been marked as a duplicate of this bug. ***
*** Bug 169624 has been marked as a duplicate of this bug. ***
using Phoenix 2002-10-28, which I assume is working the same as Mozilla, the
bookmarks in 'Imported IE Favorites' are now editable (but changes are not
"pushed" back to IE, unfortunately).  How does this affect the goal of this bug?
 I'm trying to clarify the difference between this bug -- which seems oriented
towards creating "real" bookmarks -- versus bug 84272 which is about simpler
re-importation of the original "temporary" system of 'Imported IE Favorites'.

If imported IE Favorites are now being treated as real bookmarks (the new
behaviour in Phoeniz), then they are de-facto a one-time/initial import unless
we want to create duplicate 'Imported..' bookmark folder, or unless we're going
to erase everything in the 'Imported..' folder (and risk dataloss if they've
been customized).
____________________

Personally, I want to be able to switch back-and-forth between IE and Mozilla
without losing the ability to share IE Favorites.  So, making the imported
bookmarks permanent is a setback to me.  I'm also going to add a question to the
main bug 59636 re IE Favorites...
*** Bug 178657 has been marked as a duplicate of this bug. ***
I just downloaded mozilla from zdnet,and have also hit the bookmarks bug.
I`m running win95 osr2 from a amd k6-2 platform.normally, I`d be browsing with
IE 4.0.
Attemping to import my ie favourites into mozilla`s bookmarks,doesn`t work,
mozilla looks for html files whem importing,and can`t see ie favourites as such.

o.k.,get sneaky!!Open ie and mozilla(offline),select organise favourites in ie,
and the similar command in mozilla,size each window to suit,then drag and drop
the buggers from one to the other.Bingo!!it worked!!

The snag is that what you get is the url but the path points to
c:\\blah\blah....All that`s happened is the creation of a short-cut for each
item.Useable but still not quite there.Interesting.......Russell Harris
Keywords: mozilla1.2 → nsbeta1
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 199172 has been marked as a duplicate of this bug. ***
Blocks: 164421
Whiteboard: parity-opera
I suggest changing the summary to "Syncronize bookmark between browsers" because
this is what this bug is really about.
The annoyance of going from one browser to another , expecting to see the same
bookmarks and finding out differently.

The same situation is also true not only for Mozilla <-> IE but also Mozilla <->
Firefox/Opera/Netscape/Safari

I feel it's important to keep the UI simple and do like Firefox does , choose a
good default and leave editing it to the more advanced users by means of
about:config
I suggest one option named "Syncronize bookmarks between browsers" or something
like that.
The option would be changed either in Options or in about:config , and it's
default would be what was choosen when the browser was installed (it already ask
if it should syncronize) , which would automaticly syncronize bookmarks between
installed browsers.

This would no doubt be the easiest .. however I'm concerned about startup
performance issues .. does anyone have any ideas to that point ?
> I suggest changing the summary to "Syncronize bookmark between browsers"
> because this is what this bug is really about.

That's what bug 52431 seems to be for.
Product: Browser → Seamonkey
Assignee: bugs → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: claudius → bookmarks
Target Milestone: Future → ---
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
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 14 years ago
Resolution: --- → EXPIRED
There still no possibility to import ie favorites into already existed profile.
Use-case - restoring from backup, and  transferring from another computer.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
Still valid request
Whiteboard: parity-opera → parity-opera [2012 Fall Equinox]

    
    

    
  
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-opera
Whiteboard: parity-opera [2012 Fall Equinox] → [2012 Fall Equinox]

          You need to log in
          before you can comment on or make changes to this bug.