Closed Bug 130079 Opened 22 years ago Closed 22 years ago

Importing IE favorites turns spaces into %20 (URL-encoded)

Categories

(SeaMonkey :: Bookmarks & History, defect)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: andyed, Assigned: bugs)

References

Details

(Keywords: polish, regression, Whiteboard: [adt3])

Attachments

(1 file, 1 obsolete file)

Another attempt
1.38 KB, patch
bugs
: review+
darin.moz
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
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.
Summary: IE Favorites are URL-Encoded → IE Favorites are URL-Encoded (%20 for spaces)
*** 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. ***
Keywords: regression
*** 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?)
Summary: IE Favorites are URL-Encoded (%20 for spaces) → Importing IE favorites turns spaces into %20 (URL-encoded)
*** 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.
Keywords: nsbeta1
Keywords: mozilla1.0
Blocks: 120814
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.
Keywords: polish
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?
-
Depends on: 132977
No longer depends on: 132977
nsbeta1+ per Nav triage team, adt3/1.0
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
Target Milestone: --- → mozilla1.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)
OS: Windows 2000 → All
*** 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));
Attached patch patch to fix the problem (I hope) (obsolete) — — Splinter Review 
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 ;-)
Attachment #77004 - Flags: needs-work+
Attached patch Another attempt — — Splinter Review 
Yep, I mixed it up with the NS_UnescapeURL version that returns a PRBool
Attachment #77004 - Attachment is obsolete: true
Comment on attachment 77076 [details] [diff] [review]
Another attempt 

sr=darin (andreas: thx for fixing this one!)
Attachment #77076 - Flags: superreview+
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.
Blocks: 134771
Keywords: mozilla1.0 → mozilla1.0+
*** 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.
Attachment #77076 - Flags: approval+
*** 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
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** 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.
Keywords: fixed1.0.0
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
closing again, that issue is dealt with in bug 127476
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0 → verified1.0.0
*** 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. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: