109.14 KB, text/plain
4.08 KB, patch
|Details | Diff | Splinter Review|
3.54 KB, patch
|Details | Diff | Splinter Review|
5.22 KB, patch
|Details | Diff | Splinter Review|
4.27 KB, patch
|Details | Diff | Splinter Review|
6.72 KB, text/plain
14.46 KB, patch
|Details | Diff | Splinter Review|
857 bytes, patch
|Details | Diff | Splinter Review|
Run Mozilla. Delete the Imported IE Favorites folder from Bookmarks|Manage Bookmarks. Close Mozilla. Run Mozilla. The folder is back. Mozilla should not automatically import IE Favorites each time it's opened, but it would be a good option to have in Bookmarks.
Hmmmm ... good point. Steve, is it supposed to work like this?
In addition, the Favorites folder shouldn't be migrated if it's empty, which currently happens. I have an empty Favorites folder that won't go away...
In addition, if the Favorites folder is empty, it doesn't behave like other empty folders, which lose the little arrow on the right. Instead, a tiny 1 or 2 pixel menu pops out when selected.
(happens on Mac, too)
OS: Windows 95 → All
Hardware: PC → All
Summary: Cannot permanently delete Imported IE Favorites folder. → Cannot permanently delete Imported IE Favorites folder
Move to M16 for now ...
Target Milestone: M15 → M16
It's important you should be able to delete the IE Favorites folder for good. It's a good feature to import them when you install Mozilla, but if you have deleted it, the folder shouldn't be imported every time you start the Browser. It's really annoying for anyone who keeps track of their bookmarks. Why not put the import of Favorites in the 'Import Utility' (where it logically should be) tool instead?
Also, you can't move the stupid thing. (Click and drag to rearrange doesn't work. It's rooted itself in there pretty well.)
*** Bug 39840 has been marked as a duplicate of this bug. ***
Move to M21 target milestone.
Target Milestone: M18 → M21
usability issue, worth dealing with before release in my oppinion
To be blunt, for those of us who do not USE IE AT ALL, it's damn annoying. I think I can see why this may have been a useful idea. People who use both browsers see their IE Bookmarks (I refuse to call them favorites) always current in Mozilla, but see nothing from Mozilla in IE, thus making Moz look smarter than IE. But, it never quits. How about just a simple flag in the user prefs.js file? user_pref("import.ie.favorites", false);
Stuff like this isn't going to get fixed between nsbeta3 and rtm. Changing keyword.
nav triage team: fyi, this is not "imported", it is a live feed of the folder on your desktop called "IE Favorites" so it is always up-to-date. Vera is planning to add to documentation that the user can remove the folder from the disk drive and hopefully that will take care of the problem. This is actually a feature request, so -
Fine it's a feature request to supress a poorly implemented feature. Relnote3, and RTM: "It is impossible to permanently delete this folder from your mozilla/netscape6 bookmarks" [have a nice day].
email@example.com: That doesn't solve the problem for people like me: My brother uses IE, I use Mozilla. I don't want his bookmarks. This means that I can't remove the IE bookmarks folder, as you suggested as a solution to the problem. There needs to be a way to turn accessing the IE bookmarks off.
A similar situation: I can't delete the IE Favorites folder on this computer. `You cannot move "Favorites" from the folder "System Folder", because you do not have the privilege to make changes.' Filed bug 52431 about synchronizing Mozilla's bookmarks with those of another browser, instead of this hokey folder thing.
This could probably be fixed by hacking our magic entry so that when it is "deleted" it is marked with some attribute that prevents it from displaying. This would probably map to a preference that lives near the Go|Search|Bookmarks checkboxes. At first I thought that the correct thing to do would be to leave this flag in the bookmarks file, as I thought about the undelete method I considered it as a preference. I don't know enough about how we handle magic folders to know if we could trap the delete event for just one.
The "Imported IE favorites" bookmark doesn't show a popup menu either. At the very least right-clicking on it should display a popup allowing the user to delete the folder (permenantly of course)
*** Bug 56640 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
It is not. Please keep this separate. Thank you.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
win32 build 110420 crashes when the IE favorites folder is deleted. Running on win98SE. Steps to reproduce: 1. Start Mozilla 2. Select Bookmarks|Manage Bookmarks 3. Select IE Favorites folder and hit delete key 4. Close Mozilla 5. Crash Talkback did not kick in, but here is console log. Dr Watson attached. Contents of console log: has multiple monitor apis is 1 Move window by 580,484.5 New location for profile registry and user profile directories is -> C:\WINDOWS\APPLICATION DATA\Mozilla start with profile: Default ProfileManager : StartApprunner profileName passed in: Default I am inside the initialize Hey : You are in QFA Startup (QFA)Talkback loaded Ok. Setting content window *** Pulling out the charset Loading page specified via openDialog in SetSecurityButton Document http://www.mozilla.org/ loaded successfully Hey : You are in QFA Shutdown
Reassigning 79 Bookmarks bugs to Ben. I was told this was going to be done shortly about two months ago, but it clearly hasn't been. I think that's long enough for all these bugs to remain assigned to nobody. Feel free to filter all this spam into the trashcan by looking for this string in the message body: ducksgoquack
Assignee: slamm → ben
Status: REOPENED → NEW
reported 11/15/2000 by Jim Thomason at http://www.macintouch.com/netscape6.html
reported 11/15/2000 by Steve Palm at http://www.macintouch.com/netscape6.html
Removing myself from list of cc's. I hope this gets fixed!
This was a common complaint from Netscape 6 users, and should be addressed for beta1...
reported 01/08/2001 by Art Hughes on n.p.m.wishlist ("various issues", no.3)
Netscape Nav Triage Team: adding german to the cc list. we need to design this behavior.
nav triage team: Yeah, we need to solve this issue, but not now. Marking nsbeta1-
*** Bug 68926 has been marked as a duplicate of this bug. ***
reported 2/16/2001 by Jerry Park on n.p.m.seamonkey Not now? Sorry, but I can't follow. This is in the top 12 of the voting charts, and sounds like it has a good reward/effort ratio. Re-nominating by replacing the nsbeta1- keyword with the nsbeta1 keyword, per keyword description. Please have a second look. If it get's nsbeta1- again, I'll stop whining.
Above patch adds a preference for importing the Favorites on startup. The UI for the prefs needs a bit of cross-platform work (presumably Unix doesn't need the pref, and BeOS needs to refer to NetPositive bookmarks?) but this can be done if the approach is sound. Review?
sounds like IEFavorites is the wrong term. ben, can we rename it systemFavorites? Import is inaccurate, let's use Include. this whitespace change is bad: - </titledbox> + </titledbox> if you're going ^ to change trailing whitespace please trim all of it. asside from my wording nits, this patch looks great. german: thoughts about Include?
Renaming of IE Favorites is currently bug 68858. Anyone in a position to test on a Mac?
I can test it, but I need a binary...
+<!ENTITY IEFavorites.label "IE Favorites"> We should probably use `Internet Explorer™' rather than `IE', because more people will know what `Internet Explorer' is than what `IE' is. (Abbreviations are generally bad UI, except for units of measurement.) I don't think we should use `system favorites', for cross-platform reasons -- Internet Explorer favorites aren't system favorites on either Mac OS or Solaris (where IE is also present), and it's probably not worth doing platform-specific stuff for this bug until this fix is made obsolete by the fix for bug 56765. +<!ENTITY IEFavoritesExplanation.label "&brandShortName; can create a bookmark to your IE Favorites on startup."> It's not a bookmark, it's a folder full of bookmarks. And they're not created on startup, they're dynamic based on the contents of the Favorites folder. +<!ENTITY importIEFavorites.label "Import IE Favorites on startup"> This is the only entity you should need. Having a group box, and in-line help text, just for a single checkbox which has a relatively simple function, seems rather extreme. [/] Show Internet Explorer™ "favorites" in their own bookmarks folder
>It's not a bookmark, it's a folder full of bookmarks. And they're not created >on >startup, they're dynamic based on the contents of the Favorites folder. I think that what I said describes what actually happens - although not necessarily what it looks like to the user. There *is* a single bookmark created, which points to the location of the IE Favorites folder on disk - you can create one yourself, or for other directories, such as the desktop. The reason I mentioned startup in the preference text is that unchecking the preference does not instantly delete your IE Favorites folder, you have to restart for that to happen.
"Create bookmark folder containing Internet Explorer favorites when &brandname; starts up" ? >This is the only entity you should need. Having a group box, and in-line help text, just for a single checkbox which has a relatively simple function, seems rather extreme. It is consistent with the current bookmark prefs though. Which group box should this new pref be included in?
As long as the UI isn't lying, it's what it looks like to the user (rather than how it is implemented) which is important. > Which group box should this new pref be included in? It shouldn't. Prefs in group boxes should be the exception, rather than the rule.
adding self to CC, timeless wants me to modify the patch
I note that 1) the UI will still refer to Internet Explorer (pref-bookmarks.dtd) 2) nsBookmarksService.cpp still refers to the pref browser.bookmarks.import_IE_favorites not browser.bookmarks.import_system_favorites 3) there's an unrelated history change in there
That's what I get for posting a patch when tired, sorry for the spam. 1) I think the UI strings should be platform dependent because BEOS is mentioned in nsBookmarksService.cpp but there are no entities. Ask timeless for the specifics. 2) Fixed (thanks for the heads up) 3) Removed
re: 1. I originally suggested that this bug would need cross-platform work (NetPositive Bookmarks on BeOS, not applicable on Linux etc). but Matthew Thomas thought that "it's probably not worth doing platform-specific stuff for this bug".
*** Bug 70127 has been marked as a duplicate of this bug. ***
The latest patch: * still refers to `import_system_favorites' rather than `import_ie_favorites', potentially causing confusion with any future pref which really does include the system favorites rather than the Internet Explorer favorites; * still talks about creating the folder `on startup', when as far as the user is concerned that is irrelevant. Neither of those are huge problems, though.
mpt: yes the idea is to refer to system favorites, not ie favorites, because we were abusing the elements to have IE Favorites refer to netpositive bookmarks which makes no sense. Note to self, I owe this patch some love for the preference ui. [refactor dtd values into platform files]
mpt: If we do not mention startup, then it looks as though unchecking the preference will instantly delete the Imported IE Favorites folder; it will not.
mpt: there are three possible solutions to the "on startup" problem: - add a text that explains that the changes will take effect the next time he restarts the browser - when the user checks/unchecks this option, bring up a pop-up telling her/him when the changes will take effect - actually delete/insert the bookmark when the user checks/unchecks the option I prefer the third solution, but I don't know if the insertion can be done...
As a user I would like the option to import them, move them around, and so on, without having them be in a "ie favorites" folder.
Lorin, That's more closely related to bug 56765 then this one.
*** Bug 70822 has been marked as a duplicate of this bug. ***
i haven't looked at the actual text of the patch but can't you just change the wording from 'on startup' to 'after restart'? I think most folks get the ramifications of that. (i.e. not now but later)
I didn't have to close Mozilla for it to crash on me --all I did was try to delete the IE folder. After hitting the delete option in the editing menu, Watson showed up with a 'c0000005 (access violation)'. This is on NT with build 2001031008 --C. Labombard
The fix to allow the IE Favourites folder to be turned off is (as far as I can see) to set up the pref, and then add code to check for it in the tests on line 4914 (Mac) and 4217 (Windows) of nsBookmarksService.cpp. So, we can have a UI option which immediately sets a pref. Then, the next time the Bookmarks menu is pulled down, they'll be gone. (If they are cached, we merely call ReadBookmarks again.) Gerv
Gerv: s/4914/4194. And isn't that pretty much what the current patch does? >Then, the next time the Bookmarks menu is pulled down, they'll be gone. Doesn't happen. (because the Imported IE Favorites directory is saved out as part of the bookmarks?) Are there actually any problems with the latest patch? What is stopping it being reviewed and checked in?
*** Bug 74195 has been marked as a duplicate of this bug. ***
nav triage team: This is not a Netscape priority for beta, marking nsbeta1-. The mozilla community is more than welcome to fix this bug, though. ;-)
51 votes and a patch - what more does the "mozilla community" have to do? Although the patch itself now needs - <checkbox id="importSystemFavorites" value="&importSystemFavorites.label;" + <checkbox id="importSystemFavorites" label="&importSystemFavorites.label;" following the XUL syntax changes.
> what more does the "mozilla community" have to do? 0. agree that with the patch applied things are better than without 1. get a review and a super-review 2. check it in Someone probably needs to volunteer to drive this to the finish. To indicate that you are willing to do this, just take the bug (reassign it to yourself). Ben, can you review or comment, please? Or recommend someone else for review?
*** Bug 76548 has been marked as a duplicate of this bug. ***
This requires some more thought. Placing into .9.2. as it is a popular bug however and causes some bookmarks usability issues.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9.2
Here's the solution I want: No preferences panel UI. This is more of a view option than a checkbox in prefs. Show the folder by default. Allow the user to delete it, perform a delete and then update the pref. Have a menu item in the view menu maybe, with platform text: [x] Internet Explorer Favorites (Windows and Mac). [ ] NetPositive Favorites (BeOS) Not sure what the work is like for Mac and BeOS, but should be fairly straightforward for Windows. Checking the item will recreate the folder. I'm not going to get to this before .9.2, and then outliner work may take priority, but someone who produces a patch along these lines will be greatly appreciated ;) Please note that I want an XP solution as that's the way I'd do it myself.
*** Bug 77316 has been marked as a duplicate of this bug. ***
*** Bug 78160 has been marked as a duplicate of this bug. ***
This is not actually a patch, (well, it was extracted from a larger one). It's possible to hand-apply. Implements support required from nsBookmarksService.cpp for removal of system favorites folders. Adds the same pref from previous patches to disable the adding of the folder on startup. Hooks up a set of this pref into the delete function in bookmarksOverlay.js. Still left: add a checkbox to the 'System' panel in preferences to allow this to be re-activated.
This patch should also prevent the addition of multiple favorites folders, as it does a case insensitive compare for filename.
Ben - great! > This is not actually a patch, (well, it was extracted from a larger one). > It's possible to hand-apply. Does this mean that: a) You are working on this in another patch and it'll get checked in as part of that soon, or b) You want someone else to pick this code up, make a proper patch and add the pref to the prefs UI somewhere? Gerv
Can we not call NetPositive bookmarks IEFavorites?
*** Bug 79512 has been marked as a duplicate of this bug. ***
marking mostfreq: 9 dupes + the press reports.
*** Bug 80071 has been marked as a duplicate of this bug. ***
nav triage team: Not an ns stopper, marking future
Target Milestone: mozilla0.9.2 → Future
Oh man. This bug has 70 votes, 9 dupes, and was one of the oft-commented on "features" of NS 6 that people disliked. Why why why?
i tried to use my other 9 votes for this bug, but it won't let me vote for it more than once. the sooner this is fixed, the better, as far as i'm concerned. i'd prefer a few of the crashers i get over this.
This is one of those things that keeps me from using Mozilla as my main browser. It's so annoying... And it's been there SOOOOOO long. Please change this behavior. Make it an option (Would you like to import you IE bookmarks?)
I thought this was mostly done, and was only lacking a UI for it. If that's true, how do I change my prefs to get rid of the IE favorites?
I like the fact that you have an up-to-date version of your IE bookmarks, which can be useful if you use both browsers. Although it would be nice to make it either optional, and/or allow adding/moving/copying/deleting to/from the IE bookmarks folder.
Ben, where are we up to with your patch? I have a UI patch if people are interested. It adds "Internet Explorer Favorites" (or the platform equivalent) to the Bookmark Manager/View menu.
I follow Simon's lead in asking 'why' here. Ben is a busy guy, but I don't see how this bug is less important than the other plussed bugs on his plate. Are people expected to complain more about bug 75470 than this? Or 68985 or 81213? Renominating; this should also be catfood, because more than a couple reviews mentioned it. I would be happy to help out in fixing this (I'll talk to Ben about where he is on this...)
Pessimistically 0.9.3, as I already have a patch
Target Milestone: --- → mozilla0.9.3
nav triage: not sure why this is catfood. its a nice to have - hence scheduled into m0.9.3. if someone wants to take it, thats fine too ;).
SEMI-SPAM: Vishi is not sure why this is nsCatFood??? Doesn't he know what that means??? Hasn't he seen all the CC's, all the votes??? All the comments for this bug??? Vishi, if this isn't a "serious user *satisfaction* issue" (not user "usability") and your managers don't slap you upside the you-know-what, then Mozilla will surely fail - steamrolling over such obvious user satisfaction issues is no good omen. Please remove the #*§%& minus sign from nsCatFood!!! END-OF-SPAM, and apologies for loosing my "cool" (it's 3:00 AM).
So I've had this patch in my tree for some time now, and it'd be a little hard to remove it, and since the code collides with other nsbeta1+ fixes I have, I'd like to just check it in. I don't see any harm, it seems to work. Need review, super review.
r=hixie, with two minor comments: first, your diff is screwed up (one of the files is in there twice??) and second, dude, remove the tabs...
apart from the horrrrrible indentation this patch looks good to me as well, unfortunately I could not test it as I build only on linux, and bill knows that there is no such thing as favourites on linux
Tabs are a long standing issue in this file (you can thank rjc). Since this isn't really a large modification to the file, I've chosen not to start a fight in my text editor (as it'd eventually end up in a war, with many casualties, botched braces and failed compilations). I plan on reformatting the file function by function as I make localized changes. As for the double patch, oops, that'll teach me to use >> too liberally ;)
a= firstname.lastname@example.org for checkin to the trunk. (on behalf of drivers)
Patch checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago → 18 years ago
Resolution: --- → FIXED
I can't seem to delete any of my bookmarks now. As soon as I click on one, the "delete" button is disabled, and never re-enables.
Is this really fixed, if that there is no UI for it? Or is there a UI patch on the way?
Oops, forgot about that. Delete key and Delete button on toolbar work though. Can we take the details to a new bug to prevent spam?
Sounds like a good idea. Ben, I have a more complete UI patch if you are interested in seeing it.
Works for me 2001060504 Win98. I don't remember how I deleted it but it hasn't come back.
verified fixed with win2k build 20010605.. (CVS opt) BTW: how can I get the IE Bookmarks back :-)
Status: RESOLVED → VERIFIED
Matthias: good question! Open your prefs.js file and remove the pref for browser.bookmarks.import_system_favorites. Not the best solution, so file a new bug on me to create a UI for this. mpt has suggested the system panel in the past, but lets leave that for a new bug. Matthew Wilson, could you also file a bug on me for your patch? Thanks.
OK, I created bug 84281 for "Prefs UI to show/hide Imported IE Favorites folder". That way, we can get the IE favs back if we ever change our minds or accidentally deleted them ;)
Has this regressed on newer builds ? (2001122603)
Sorry if I missed the obvious, but this bug is marked "fixed" and "closed" back in 2001 for target milestone 0.9.3, and here I am in 2002 with a brand new milestone 0.9.9 (build 2002031104 on Win98SE) and I still don't know how to *permanently* delete that stupid IE favorite folder Mozilla keeps creating each time I start it... Yes, I did read through the thread, and yes, I did notice a handfull of patches, but I don't think installing a 0.9.3 patch on my 0.9.9 build would be a good idea. And AFAIK usually a patch gets integrated into future versions. What am I missing?
Please see bug 84272. If that isn't what you want, please open a new bug.
You need to log in before you can comment on or make changes to this bug.