In the Bookmarks menu, Imported IE Favorites are no longer being resolved to the correct websites; just showing internet shortcut text. Steps to reproduce: Click on Bookmarks menu Click on Imported IE Favorites Click on any Imported IE Favorite Expected Behavior When I click on the IE Favorite, it browses to the desired page. Actual Behavior: Browser shows: [DEFAULT] BASEURL=http://www.mozillazine.org/ [InternetShortcut] URL=http://www.mozillazine.org/ Modified=006CE5209653C0011B IconFile=http://www.mozillazine.org/favicon.ico IconIndex=1 Address bar shows: file:///C|/Documents%20and%20Settings/xxx/Favorites/Daily%20News%20-%20MozillaZine%21%20Your%20Source%20for%20Mozilla%20News%20and%20Advocacy.url I've tried removing my bookmarks.html, deleting localstore and other rdfs, and fastload files. No luck. Will try creating a new profile soon. This is present is builds 20020507xx - 20020509xx but works fine earlier.
*** Bug 143225 has been marked as a duplicate of this bug. ***
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0, nsbeta1, regression
This problem is not present with a new profile but does happen on Imported IE Favorites imported because of this pref: user_pref("browser.bookmarks.import_system_favorites", true);
hmm, it doesn't work for me having this line in my old prefs: user_pref("browser.bookmarks.import_system_favorites", false); and this line only starts the action to import the favorites while starting Mozilla.
Did something change beween Moz 1.0.0 RC1 and RC2? Everything worked before I upgraded, but now my IE favourites have stopped working - I get the behaviour described in the summary. Mozilla 1.0.0 RC2, Windows 2000 Pro, IE 5.5
Ditto for me. Worked fine in RC1. Loaded RC2, and I am seeing this same behavior. Mozilla 1.0 RC2 on Windows 2000 Pro.
*** Bug 144375 has been marked as a duplicate of this bug. ***
It happens since the nightly 1.0.0 build 20020508 or -09.
Are you getting this behavior with the listed steps, or do you require copying your favorites out of their default location? If you do, this is bug 69768.
i can also confirm this - mozilla1.0RC2 on win2k pro. my bookmarks were imported when i created a profile under one of the builds when URL encoding was still a problem, so mine had %20s all through them. i tried to fix by deleting the imported ie favorites folder, setting user_pref("browser.bookmarks.import_system_favorites", true); in prefs.js, and restarting mozilla - it re-imported all my bookmarks without spaces, but stopped actually resolving them (i get the same behaviour as above). i set that import pref back to false. it still has all the imported IE favorites in their own folder, it's not getting new favorites (as expected), and it's not resolving them. so doesn't resolve the favorites with the import pref set to both true and false.
To clarify: The original Imported Favorites that are present when a new profile is created work. This is because they have actual entries in the Bookmarks file that are made when the profile is created. When the pref (import_system_favorites) is used, it will not re-import the actual bookmarks into the Bookmarks file, it only creates a "folder" bookmark. Mine is: <DT><A HREF="file:///C|/Documents%20and%20Settings/steve/Favorites/">Imported IE Favorites</A> It is this "folder" bookmark under which no bookmarks will resolve. So it's not that the pref is active or not at the time the user is trying to use the bookmarks, it's just that that's how the pref imports the bookmarks. This was also mentioned in bug 143225 that was marked duplicate. If I remember correctly (sorry, can't test at the moment), this first showed up in the 20020507, so here are the check-ins for the previous day. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=05%2F06%2F2002&maxdate=05%2F07%2F2002&cvsroot=%2Fcvsroot
I can totaly confirm the last post #10 .
nsbeta1- per Nav triage team, since few target users will set this hidden pref.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2alpha
I'm not sure what you mean by setting a hidden preference. I installed Mozilla. It imported IE favorites. I moved those folders around so that they appear on my personal toolbar in Mozilla. Prior to RC2, I could click on bookmarks in those folders, and they would work. Now when I click on them it just displays the contents of those bookmark files. I didn't add or change any hidden preferences related to this, and I am experiencing this bug.
Confirm this bug on Mozilla 1.0 RC2 on Win NT 4.0
Added to RC3 not suck. We need to decide what to do with this feature, fix it, leave it, or turn it off (screams anticipated)
Trying to summarize this bug. Actual results: Using 1.0 RC2 branch Build ID: 2002051506 with a new profile on Windows 98, IE favorites are imported once. They work great. New IE favorites are not imported. Then, after closing Mozilla, and manually adding the following line to user.js in the profile directory, and restarting Mozilla: user_pref("browser.bookmarks.import_system_favorites", false); Mozilla imports IE Favorites again. This time, though, the IE Favorites are imported into a second Mozilla Bookmarks Folder entitled "Imported IE Favorites." This new folder includes all of the current IE Favorites, but the new IE Favorites have the wrong URL. They link to file: URL's instead of http: URL's, for example. Expected results: As a result of the pref, Mozilla should import IE Favorites each time it starts into the same IE Favorites folder with the right URL. This bug should not result in IE Favorites being pulled from Mozilla 1.0. It affects only users who manually insert the pref. At worst, the bug should be relnoted to inform users who use that pref. Ideally, this bug would be fixed for 1.0.
off the RC3 list.
No longer blocks: 143200
Comment #13 says that this bug happens regardless of setting a hidden pref. Can anyone verify if this is true?
Well, here are two parts of this Bug. One means having problems by importing favorites. That's not my problem. Importing works fine for me on w2k. My problem is the now again broken referencing of Win-Favorites like described in this Bugreport and in Bug 143225 . And I checked this thing with the hidden prefs - no change. The referencing (to file:///C|/Dokumente%20und%20Einstellungen/joe/Favoriten/Links) worked until 1.0.0 Build 20020507. In latest 1.0.0 Build 2002051606 it keeps broken.
I never set any hidden prefs, and I can confirm this bug is nevertheless present for me. Moz 1.0 RC2 Build ID 2002051006 Win Me
Apparently the reason that I had the link to the IE Favorites Directory without having set any pref was because I previously installed Netscape 6.2.2. Netscape 6.2.2 automagically created a default profile and the corresponding bookmark file C:\WINDOWS\Application Data\Mozilla\Profiles\default\foo.slt\bookmarks.html contained this link to the Imported IE Favorites directory -> file:///C|/WINDOWS/Favorites/ So when I installed Mozilla, instead of a new default profile being created, Mozilla used this profile. Part of the confusion ( and plently of future confusion I'm sure) has stemmed/ will stem from the fact that both of these are named "Imported IE Favorites." I will rename them something like "Imported IE Favorites" and "IE Favorites Directory" so that I can use both and not mix them up.
I confirm this on rc3 on win2000. BTW, SmartFind queries works on IE Favorites and URLs are resolved. Possible workaround.
Confirmed on rc3 running on WinXP (new moz install on fresh os image).
The reason I'm experiencing this bug is the same as the one in comment 21 - I'd previously installed various versions of Netscape 6.x and Mozilla. Creating a new profile solved this problem.
Confirm behavior build 2002052306 on WinME. New profile doesn't exhibit problem. Previous Mozilla builds and Netscape on machine.
Past RC3 Build 2002052306 continues with this Bug on W2K. Rebuilding a new profile won't fix it! I tested it with my old Profile "User50" and a totaly new "Profiles" profile. Result: No difference. :-( It seams to because by buildung a clean profile creates/copies the Favorites URLs into the bookmark.html and doesn't reference to the System-Bookmarks of Windows like explained in this Bug.
*** Bug 147154 has been marked as a duplicate of this bug. ***
adding my name to this bug
Status: NEW → ASSIGNED
*** Bug 147260 has been marked as a duplicate of this bug. ***
Why is this bug target for only mozilla1.2alpha in "far" future?? My opinion is that this bug is a broken main function bookmark - which worked before(!). I hope it will be fixed before or until 1.0.
I was able to go to a link in the imported favorites using build ID: 2002052306
First: I saw this bug first without having touched my pref.js file before. Again: This bug concerns the _references_ to the System-Bookmarks of Windows not the static _imported_ Favorites. You can simulate/reproduce it by this steps: 1. Menu > Bookmarks > Manage Bookmarks... 2. Remove "Imported IE Favorites" folder 3. Exit Mozilla 4. Open "prefs.js" in your "...\Mozilla\Profiles\Default\foo42.slt" folder 5. Add or change the bookmark prefs to the following values: user_pref("browser.bookmarks.added_static_root", true); user_pref("browser.bookmarks.import_system_favorites", true); user_pref("browser.bookmarks.show_static_system_bookmarks", true); 6. Start Mozilla again 7. Menu > Bookmarks > Imported IE Favorites > Select any bookmark you like below 8. You get an output like this: [DEFAULT] BASEURL=http://www.heise.de/ [InternetShortcut] URL=http://www.heise.de/ Modified=B0F3A3C537CBC001CE IconFile=X:\Data\images\WinIcons\heise.ico IconIndex=0 Same happens in the latest build 2002052906 which comes with a near final Browserstring: "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020529" A static import of the favorites is not an alternative to this now broken function. BTW: Why did it broken?? It is a broken major function in my point of view and should be fixed. This function worked like said in Comment 4 , Comment 5 , Comment 7 , Comment 9, Comment 10 , Comment 14 , Comment 16 , Comment 20 , Comment 22 , Comment 23, Comment 25. Concerning Comment 18 I can confirm: Yes. And think: Netscape 6 users - I know this is not a main term - would like to use this feature in the near Netscape 7 and will be surprised having this feature in a broken status. :-/
If it doesn't get fixed, let's relnote this for 1.0. I can't figure out what the relnote should say, though. Any thoughts?
I don't understand what you mean with a "relnote". But Anyway... Let's do it! They seam to ignore this Bug. :-(( The release tag information is out on the homepage of http://mozilla.org
*** Bug 148499 has been marked as a duplicate of this bug. ***
It looks like the contents of the dynamic folder are being given the file path as a url rather than the url content inside the .lnk file. This could mean that something in the .lnk parsing isn't working (in widget/src/windows/nsClipboard.cpp), or that something in the file system datasource is causing these items not to have their NC:URL arc set as the url from the .link file, or anything else. If someone can produce a patch, I will review. This is not relnote. This feature is not supported officially and requires hand-editing of prefs to enable. I cannot find any indication that this import_system_bookmarks pref is set to try by default in any of our past releases, which would cause a migration issue.
The only thing I see worth relnoting here is that we have removed the dynamic behavior IE favorites had in the previous release. We should not relnote defects in unsupported "features" made possible by hidden prefs. We can't afford to spend any time on this for the current release, but I am keeping it on the radar, and hope to fix it as part of an overhaul of bookmarks in the the next point release.
*** Bug 144336 has been marked as a duplicate of this bug. ***
Created attachment 93579 [details] IE favorite example for the SmartFind workaround The behavior reported is still in Mozilla 1.1 beta. But, I discovered something. SmartFind can also retreive IE favorites data and even better, resolve it. The IE fav is named "Mediom - Votre dossier.url" and points to https://wwws.mediom.qc.ca . I attach it to this comment. Put the URL file in your Windows Favorites folder. Then, go to Bookmarks > Mozilla Project > Technology Demonstration > SmartFind queries > Bookmark Names starting with 'M' > Mediom - Votre dossier
Well, this bug is targeted for 1.2alpha like you can see. :-(( Are the functions of the smartfind-project somewhere documented? And is it possible to receive a part of the favorites tree with subfolders? I saw that smartfind gets the result only in a plain list und having hundreds of results by searching e.g. for .com or .org is some kind of ugly. Maybe alphabet-folders for the results....
At the End 1.2a is out today and this Bug seams to be solved. :-) Thanks, very much!! :-D
WFM with latest build (1.2b+). Can anyone verify and mark as WORKSFORME.
yeah, I don't see this bug anymore using the trunk builds. Please reopen if you see this bug again.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Does not work for me on Mozilla 1.2b+ 2002110808. What is bug number for voting which IE bookmark integration to choose?
Can you specify why? Which System do you have, etc.? It works perfect for me. 1. go to Manage Bookmarks 2. create new Bookmark with e.g. "file:///C|/Dokumente%20und%20Einstellungen/joe/Favoriten" (on a german System your Win-Favoritefolder) and give it a Name. 3. Voila, it should work now to acces your Win-favorites directly through the Mozilla-Bookmarks.
I tried what you wrote (with adapting the location to match my system) Joseph, but it still does not work. Yes, I get bookmarks, but no one work as expected and behaviour is the same as described in original comment. I use French Windows 2000 Professional with SP2 applied.
What does it show in the bookmark management window in the location area for the reference? Try this: 1. close Mozilla 2. remove x:\Program Files\Mozilla.org\Mozilla\components\compreg.dat 3. restart Mozilla Does it work now?
file:///I:/Documents%20and%20Settings/rener/Favoris It still does not work after deleting compreg.dat.
It's broken agin in 1.4a and all latest TRUNKs :(( How to reopen?
Don't reopen this bug. Open a new bug.
You need to log in before you can comment on or make changes to this bug.