86974 - NS4 imported bookmarks have Description truncated at line breaks

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Bookmarks & History, defect, P5)

Description

[fkuester]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID:    2001061804

using renamed netscape bookmark-file for mozilla most of the comment-entries 
are lost, just the first line in the comment-field is not lost.

Reproducible: Always
Steps to Reproduce:
1. create bookmark in netscape with many lines in description-field
2. rename netscape bookmark.htm to bookmarks.html
3. (re)place this in the folder where mozilla stores its bookmarks
4. start mozilla and manage bookmarks
5. show properties of the bookmark with the many lines of comments

Actual Results:  only first line of the description/comment is not lost

Expected Results:  all lines of the description field (netscape) should be in 
the comment field (mozilla)

Comment 1

[Chris Lyon]

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

Comment 2

[Chris Lyon]

Confirming based on dupe.

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Comment 4

[Paul Chen]

Mass move Ben's bugs dumped on me marked future with p5 to get off my untriaged
radar. You can filter out this email by looking for "ironstomachaussie"

Comment 5

[Peter Trudelle]

mass reassign of pchen bookmark bugs to ben

Comment 6

[Pierre Chanial]

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

Comment 7

[Pierre Chanial]

From the dupe:

I was using NS 4.77 before switching to Mozilla 0.99. In the "Description" field
of the bookmarks, I often used several lines of text. These I created by
pressing <enter>.

After Mozilla converted my bookmarks it had lost all the text in the description
following this <enter>. 

Example. This is how a description was in NS:
  Bla bla bla text line one <enter>
  bla bla bla text line two <enter>
  bla bla bla text line three

This is what ended up in Mozilla
  Bla bla bla text line one

I found that NS 4.77 allows <enter>, <ctrl-enter> and <shift-enter> to create a
new line, whereas Mozilla only accepts <shift-enter>. This could be a reason, as
I used <enter> which Mozilla doesn't recognise..

Comment 8

[kmt]

This has been driving me nuts as well, as I have a Netscape 4.x bookmark file 
chock full of multi-line descriptions, so I did some investigating.  This is 
what I found:

Taking a look at a Netscape 4.79 bookmark.htm file, I saw that it places a <BR> 
tag between each line in a multiline description as well as placing them on 
separate lines in the HTML source.

Taking a look at a Mozilla bookmarks.html file, I found that it just places the 
individual lines of a multiline description on separate lines with no tags 
between them, apparently letting the Bookmark Manager simply pick up the 
formatting from the newlines in the HTML source.

Sure enough, stripping the <BR> tags from the Netscape 4.x bookmark file before 
using it in Mozilla seemed to allow Mozilla to handle the multiline descriptions 
properly.

Note however that, due to the way Mozilla is handling multiline descriptions, 
its bookmark file does not display properly when viewed as an HTML file. Without 
the <BR> tags, the descriptions are always displayed as a single line.

As I view the bookmark file this way quite frequently, this is rather annoying, 
albeit not the major problem that the truncated descriptions were.

This really should be fixed; Mozilla should use <BR> tags in its description 
field just like Netscape 4.x.  This would both fix the compatibility problem and 
enable you to properly view the bookmarks.html file as a document (which, after 
all, is the whole point of storing the bookmarks in an HTML file).

You can do this without causing a problem for Mozilla users with existing 
multiline bookmark descriptions in the current format if you have the Bookmark 
Manager continue to count newlines without following <BR> tags as line 
terminators when reading the bookmark file.  (I.e. accept either format when 
reading the bookmark file and just use the Netscape 4.x one when _writing_ it.)

Comment 9

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 11

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Phoenix]

As now bookmarks stored in sqlite database, there is no way to use old Netscape bookmarks directly, so the question is - does import from such file works properly? Does anybody still have bookmarks file from Netscape 4.x, or this bug can be closed as nobody faces this problem anymore?

Comment 18

[Phoenix]

Resolved per whiteboard