User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040512 Camino/0.7+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040512 Camino/0.7+ When I try to import my Firefox bookmarks, the folders are always nested incorrectly. Some of these bookmarks are over 5 years old, dating back to IE4. Looking at the file, I can see at least 3 different types of formatting style. I will attach a file showing a cut down version of the bookmarks.html file. As a clue to what's going wrong, if you hover your cursor of the "Proxies" folder in "Show All Bookmarks" window, the helper dialog shows "/H3>" instead of "Proxies". This is how the nesting is supposed to look: Bookmarks Toolbar Internet Proxies Blogs Shopping dvd and video music Hard to Find Amazon UK Amazon US Walmart comparison Retro Rebels Football And this is how it turns out: Bookmarks Toolbar Internet Proxies Blogs Shopping dvd and video music Hard to Find Amazon UK Amazon US Walmart comparison Retro Rebels Football Reproducible: Always Steps to Reproduce: 1.Camino -> Import Bookmarks 2.Use the attached bookmarks.html file 3. Actual Results: Bookmarks were imported but folder nesting was incorrect. OS 10.3.3

Have added bookmarks file as attachment.

I can't reproduce this problem with Firefox 0.8 and a bunch of nested folders. They always import correctly.

I was using a Camino build from 5/14/04.

Josh: are you using the attached bookmark file? I can reproduce with this file. Just glancing at where things go wrong and looking at the file, I'd guess that the completely empty <dd> tags are fouling up the parser.

Stuart, your diagnosis seems to be correct. I removed all the empty <DD> tags. The attached file and my complete bookmarks file were then imported correctly. Thanks.

Over to Stuart, since he seems to know the most about what is going on here.

Giving my bugs back to pink.

The problem is that NSScanner ignores whitespace and newlines by default. Whoever wrote the import code must have just forgotten that. So the parser attempts to scan from a blank <DD> tag up to the next tag, but it doesn't actually scan past any whitespace. Thus when it assumes its grabbing a tag's text (e.g. "<TD" or whatever) its actually grabbing whitespace. The good news is the author seems to have assumed it didn't skip whitespace in all the rest of the code, so just making that assumption true doesn't seem to break anything else.

Patch work as advertised. Bug is gone using the attached test bookmarks file.

Comment on attachment 157351 [details] [diff] [review] patch v1.0 This fix makes sense and works as described.

Comment on attachment 157351 [details] [diff] [review] patch v1.0 sr=pink

landed on trunk and branch.