Using Mozilla 0.9.9 Gecko/20020311, Imported IE Favorites show up URL Encoded in both drop-down and sidebar. To Reproduce: Look at imported IE favorites. Spaces will be represented as %20. First noticed in last week's 9.9 nightlies.

Not showing up in Mac build, Mozilla 0.9.9 Gecko/20020311

I can confirm this (Windows XP mozilla 0.9.9+ 2002030921, this is a custom build)

*** Bug 130188 has been marked as a duplicate of this bug. ***

*** Bug 130232 has been marked as a duplicate of this bug. ***

according to bug 130244, this also happens when you drag a link to toolbar folder. Dup?

*** Bug 130334 has been marked as a duplicate of this bug. ***

*** Bug 130390 has been marked as a duplicate of this bug. ***

Resummarizing to make this bug easier to find.

*** Bug 130523 has been marked as a duplicate of this bug. ***

seems this isn't only affecting IE favorites, but is a general bug about URL-encoding of links: see bug 130244 and bug 130615

*** Bug 130792 has been marked as a duplicate of this bug. ***

*** Bug 131079 has been marked as a duplicate of this bug. ***

*** Bug 131133 has been marked as a duplicate of this bug. ***

*** Bug 131165 has been marked as a duplicate of this bug. ***

*** Bug 131235 has been marked as a duplicate of this bug. ***

*** Bug 131284 has been marked as a duplicate of this bug. ***

*** Bug 131488 has been marked as a duplicate of this bug. ***

resummarizing to make this as easy to find as possible (twelve dupes in six days, is that a record?)

*** Bug 131539 has been marked as a duplicate of this bug. ***

*** Bug 131718 has been marked as a duplicate of this bug. ***

I have this bug too on a 18th march 2002 build. Build id : 2002031803 under WinXP pro.

*** Bug 131811 has been marked as a duplicate of this bug. ***

-> nsbeta1, it will effect a lot on non-US OS with i18n folder names, especially on localize builds.

Why not fix the problem instead of removing all the duplicates? I tried going through the file which saves bookmarks and replacing %20 with a space. No luck. Any code hackers got an idea on what the problem is?

*** Bug 132951 has been marked as a duplicate of this bug. ***

I'm on a US version of win XP pro and have a US keyboard. I can also confirm this bug on win2k (also a US version). So it is not just non-US operating systems that are affected by this bug. My guess is that most windows/IE users are affected.

*** Bug 132977 has been marked as a duplicate of this bug. ***

re comment 26 - yes, i don't think that's in dispute. it's apparent that this bug will affect anyone on windows who has any IE bookmarks (unless they have only bookmarks with no spaces in the titles!), which accounts for the number of dupes. nobody seems to have mentioned win98 yet, but i can confirm this happens with win98 0.9.9 release. seems like this merits the 'polish' keyword.

mozilla build: 2002031104 I have 2 "Imported IE Favourites" I tried to bookmark: http://pub20.ezboard.com/bkingofpopdiscussion and space is shown as %20. However, bookmark works with http://web.tiscali.it/datxxla/archiv.html

when I drag the URL with 8bits characters (Big5, in my case) into bookmarks, they are also stored as URL-encoded, whereas using Bookmarks->Add Bookmarks is fine.

I've also noticed that even though I've added new IE favorites since this bug appeared, they aren't showing up in Mozilla. This is still happening with build 2002032203. Is this behavior covered by this bug, or should I enter a new bug?

-

nsbeta1+ per Nav triage team, adt3/1.0

changing OS to all although platform is still PC. That is to say this has been reported on all the Win flavors but I haven't seen it on Mac yet(not that I've done an exhaustive search)

*** Bug 134138 has been marked as a duplicate of this bug. ***

Adding a bookmark with "Add Bookmark" is bugged for me as well. It adds the %20s for spaces and such. Windows XP, 0.9.9 Talkback enabled.

Correction...adding bookmarks with "add bookmark" which also exist as an IE favorite (even if I deleted the "imported IE favorites" folder, causes the bug. If I add a bookmark that doesn't also exist as a favorite, it works fine. My apologies.

*** Bug 134244 has been marked as a duplicate of this bug. ***

*** Bug 134337 has been marked as a duplicate of this bug. ***

I checked the cvs update log and diff a little bit. According to the date and my guess ;) , the cause of this bug could be the following, but I do not have the environment to rebuild/check to see if my guess is correct. Can someone else give it a try? /cvsroot/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp,v retrieving revision 1.225 retrieving revision 1.226 diff -c -r1.225 -r1.226 *** nsBookmarksService.cpp 2002/03/04 23:18:19 1.225 --- nsBookmarksService.cpp 2002/03/06 07:48:47 1.226 *************** *** 3237,3246 **** nsXPIDLCString url; ResolveShortcut(path.get(), getter_Copies(url)); ! nsXPIDLCString baseName; ! fileURL->GetFileBaseName(getter_Copies(baseName)); ! nsAutoString bookmarkName; ! bookmarkName.AssignWithConversion(baseName); nsCOMPtr<nsIRDFResource> bookmark; rv = CreateBookmark(bookmarkName.get(), url.get(), aParentResource, getter_AddRefs(bookmark)); --- 3229,3237 ---- nsXPIDLCString url; ResolveShortcut(path.get(), getter_Copies(url)); ! nsCAutoString baseName; ! fileURL->GetFileBaseName(baseName); ! NS_ConvertUTF8toUCS2 bookmarkName(baseName); nsCOMPtr<nsIRDFResource> bookmark; rv = CreateBookmark(bookmarkName.get(), url.get(), aParentResource, getter_AddRefs(bookmark));

*** Bug 134440 has been marked as a duplicate of this bug. ***

You are absolutely correct. During that checkin the urlgetters changed from a mixed escaped/unescaped return to uniform escaped return. GetFileBaseName was changed from unescaped to escaped ... ccing darin

*** Bug 130244 has been marked as a duplicate of this bug. ***

yes, after calling GetFileBaseName, you must explicitly unescape baseName. note: the resulting unescaped string is not necessarily UTF-8, so the conversion from UTF-8 to UCS-2 may fail (or give bogus results). this sort of thing was a problem with the old code as well, except that the old code assumed the unescaped text would be ASCII... which is definitely not true. to void this sort of charset problem, you can unescape escaped-ASCII-chars only. currently, the best way to do that is the following: nsCAutoString baseName; fileURL->GetFileBaseName(baseName); // convert baseName to UCS-2 w/ ASCII chars unescaped; non-ASCII escaped chars // remain escaped. nsCAutoString buf; NS_ConvertUTF8toUCS2 bookmarkName( NS_UnescapeURL(baseName, esc_OnlyASCII, buf));

This patch should do it, could somebody with a windows build please test it, that code is #ifdef XP_WIN and I'm on linux ...

Comment on attachment 77004 [details] [diff] [review] patch to fix the problem (I hope) Index: mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp >+ nsCAutoString buf; >+ NS_UnescapeURL(baseName, esc_OnlyASCII, buf); >+ NS_ConvertUTF8toUCS2 bookmarkName(buf); this isn't quite right. the copy of data to buf only happens if required. the return value of NS_UnescapeURL |const nsACString &| corresponds to the location of the actual unescaped data. so, you should really write: nsCAutoString buf; const nsACString &unescapedName = NS_UnescapedURL(baseName, esc_OnlyASCII, buf); NS_ConvertUTF8toUCS2 bookmarkName(unescapedName); or, just do away with the temporary |unescapedName| as i did in my previous comment. /me thinks this unescaping API (that i admittedly hacked together) could definitely use some work ;-)

Yep, I mixed it up with the NS_UnescapeURL version that returns a PRBool

Comment on attachment 77076 [details] [diff] [review] Another attempt sr=darin (andreas: thx for fixing this one!)

Has anybody tested it? I'm pretty sure it compiles and that it does the job, but I need someone to verify that. As I said, I have no windows build available currently and that code is #ifdef XP_WIN.

Comment on attachment 77076 [details] [diff] [review] Another attempt r=ben@netscape.com

*** Bug 136043 has been marked as a duplicate of this bug. ***

confirming on build 2002-04-08 on WinNT (not that there's any doubt) I only have this problem with *some* of my Favorites, i.e. some spaces show up correctly. If this a function of when they were imported? Will the suggested patch take care of this half-right/half-wrong condition? I install the latest nightly every morning over the top of my existing install.

Applied the patch to a cvs build from a from a couple of days back. The problem disappeared. I'm on Win2K SP2.

Thanks Harshal, someone else for more regression checking? Who will get the approval and check it in?

I am writing this to confirm this bug. I downloaded mozilla-win32-0.9.9-installer.exe on 4/8/02. Here is the "About Mozilla" print out: ======================================= Mozilla 0.9.9 Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311 ======================================= I am using NT. An able to replicate bug

Comment on attachment 77076 [details] [diff] [review] Another attempt a=asa (on behalf of drivers) for checkin to the 1.0 branch.

*** Bug 136563 has been marked as a duplicate of this bug. ***

Andreas, time is running out for RC1. can you please land this or find someone to land it? Thanks.

darin, do you want to land this on the 1.0 branch and trunk? I can do it too, but that would certainly violate nearly every checkin rule I know (landing windows specific stuff from a linux build).

fixed-on-branch

fixed-on-trunk

*** Bug 137113 has been marked as a duplicate of this bug. ***

*** Bug 137346 has been marked as a duplicate of this bug. ***

04/11/2002 14:12darin%netscape.com mozilla/ xpfe/ components/ bookmarks/ src/ nsBookmarksService.cpp 1.234.2.2 MOZILLA_1_0_0_BRANCH adding fixed1.0.0 keyword.

removing item for this bug from the release notes since the bug is marked fixed. If this is in error, please make a note in the release notes bug for the current milestone.

This doesn't seem fixed, to me. Using build 2002-04-16(17) "1.0" on WinNT. I installed this latest pre-1.0 version over the top of my existing build. The IE Favorites still show %20 etc. I created a new profile but the IE Favorites were not imported. Questions: 1. Does the fix only affect new installs? 2. Is there a command somewhere to manually re-import IE Favorites?

I think this will only affect new installs when the IE Favorites are newly imported. Maybe this can also be achieved with creating a new profile? Otherwise I don't think this can be triggered manually.

I did create a new profile. The only thing I didn't do was uninstall and clean out my Windows Registry, then re-install.

I've tried on recent latest-1.0.0 builds. At least for 2002041711, only the %20 for space is solved. I18N characters other than en-US letters are still encoded.

closing again, that issue is dealt with in bug 127476

OK, so, granted that newly imported IE Favorites will be ok... HOW DO I RE-IMPORT THEM?! Creating a new profile didn't do it. The Import command in Manage Bookmarks won't do it. Is there an RFE bug for "Need means to re-import IE Favorites"? Or, maybe a bug re "New profiles do not re-import IE Favorites"? HELP!

*** Bug 138377 has been marked as a duplicate of this bug. ***

reporter of bug 138377 still sees this in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1) Gecko/20020417

AFAIK installing over an old build will not import the favorits again, you have to do a very fresh install ... see comment #71

I'm seeing this as well. I uninstalled 0.9.9, then installed 1.0RC1. The IE Favourites bookmarks have %20 all over them. This bug needs to be reopened, and put on the RC2 dependency list.

I deleted the "IE Favs links" in mozilla (by mistake). Unfortunately, all my bookmarks are in IE. I would love to get that link back. Following this thread, i understand that it is not possible. Will it be possible for someone to write a temoprary script or something that I could run and get the link back ? Thanks

the last few comments seem to be missing what this bug was about. this bug was that _on performing the import_, the bookmarks got %20 in them. that no longer happens, so the bug is fixed. if you delete your mozilla profile and then reinstall, the IE favorites will be reimported correctly. what the last commenters want is for new versions of mozilla to detect and fix up existing bookmarks which previously got broke, which is a separate issue. it could probably be more generally expressed as an RFE - "want a way to re- import IE favorites"

As per Comment #77, created enhancement request via Bug #138514.

For those looking for a (semi-painful) way to reimport, do this: Export your Mozilla bookmarks. (So you can go back and make sure you got everything.) Rname your "Mozilla" folder off somewhere, for me this was C:\Documents and Settings\ryan\Application Data\Mozilla - I renamed it "Mozilla.old" Uninstall Mozilla. Install RC1. Export your bookmarks. Rename the *new* Mozilla folder out of the way. ("Mozilla.rc1" makes sense.) Rename your old one back. ("Mozilla.old" -> "Mozilla") Go in, manage your bookmarks, import the bookmarks you exported 3 steps ago, edit for a while to merge the lists.

There seems to be a lot of confusion about this bug. Does Mozilla maintain a live link to IE Favourites as is stated in Bug #138514 and in Bug #120814? Or, does Mozilla do an import, and then has nothing to do with IE? From evidence so far, it looks like a live link is maintained. Especially when one reads comment 2 in Bug #120814.

I think that those of us still suffering from %20 entries now need to turn our attention (and our votes) to bug 134535 "IE Favorites do not import". I believe the desired functionality is for IE Favorites to be re-imported every time you restart Mozilla. Of course, this does not address the issue of a missing IE Favorites folder (desired or not). Bug 127756 is for people who *want* to delete the folder but can't stop it's re-appearance. How we can have these two diametrically-opposed bugs is beyond me...

Have a pref of course ...

*** Bug 138655 has been marked as a duplicate of this bug. ***

*** Bug 138808 has been marked as a duplicate of this bug. ***

There are still 13 votes on this bug which should be transferred to bug 134535. Also, all new "dupes" should probably be assigned to 134535 instead of this one. After all, if people are still having problems, then there should be an open bug to assign them to!

*** Bug 140004 has been marked as a duplicate of this bug. ***

*** Bug 140225 has been marked as a duplicate of this bug. ***

VERIFIED Fixed with branch and trunk builds 20020423 potential dupes should look at bug 134535

*** Bug 144294 has been marked as a duplicate of this bug. ***

*** Bug 144971 has been marked as a duplicate of this bug. ***

*** Bug 145829 has been marked as a duplicate of this bug. ***

*** Bug 146520 has been marked as a duplicate of this bug. ***