Last instance of URL deletes -- or overrides name of -- all previous instances in bookmarks.html

VERIFIED DUPLICATE of bug 51683

Status

SeaMonkey
Bookmarks & History
VERIFIED DUPLICATE of bug 51683
16 years ago
13 years ago

People

(Reporter: unadyyplzs, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

This reproducible bug is occurring in the Mozilla browser (with a build ID of
2002053012) on an Intel PC running a freshly installed Windows 2000 operating
system, after repeated reboots.

This bug has two separate but quite similar parts:

1. If the Mozilla bookmarks.html file contains multiple instances of a
particular URL within the same <DL></DL> tag, then only the last instance is
displayed by Mozilla in its Bookmarks menu.  When Mozilla is closed, the
bookmarks in memory are written back out to the bookmarks.html file, and only
the last instance is saved in that file.

2.  If the bookmarks.html file contains multiple instances of a particular URL
within different <DL></DL> tags, then all of the instances are displayed by
Mozilla in its Bookmarks menu, but the link name (i.e., the text in between the
<A...></A> tags) of the last one overrides all of the previous ones.  When
Mozilla is closed, the bookmarks in memory are written back out to the
bookmarks.html file, and only the name of the last instance is saved in that
file, for all instances.  This is best seen in example 2 below.

The version information found in the Help menu:  Mozilla 1.0 / Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530


Reproducible: Always
Steps to Reproduce:
For part 1, use a sample bookmarks.html file such as the following:

<!DOCTYPE NETSCAPE-Bookmark-file-1>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<TITLE>Test bookmarks 1</TITLE>
<H1>Test bookmarks 1</H1>

<DL><p>
    <DT><A HREF="http://www.yahoo.com/">Yahoo! 1</A>
    <DT><A HREF="http://www.yahoo.com/">Yahoo! 2</A>
    <DT><A HREF="http://www.yahoo.com/">Yahoo! 3</A>
</DL><p>


For part 2, use a sample bookmarks.html file such as the following:

<!DOCTYPE NETSCAPE-Bookmark-file-1>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<TITLE>Test bookmarks 2</TITLE>
<H1>Test bookmarks 2</H1>

<DL><p>
    <DT><H3 FOLDED>Section 1</H3>
    <DL><p>
        <DT><A HREF="http://www.yahoo.com/">Yahoo! 1</A>
    </DL><p>
    <DT><H3 FOLDED>Section 2</H3>
    <DL><p>
        <DT><A HREF="http://www.yahoo.com/">Yahoo! 2</A>
    </DL><p>
    <DT><H3 FOLDED>Section 3</H3>
    <DL><p>
        <DT><A HREF="http://www.yahoo.com/">Yahoo! 3</A>
    </DL><p>
</DL><p>


Actual Results:  For part 1, the Bookmarks menu only shows the last one, "Yahoo! 3".

For part 2, the menu shows all three bookmarks, but with the same link name,
"Yahoo! 3" for each one.

Expected Results:  For part 1, the Bookmarks menu should display bookmarks for
"Yahoo! 1", "Yahoo! 2", and "Yahoo! 3" (on the main menu).

For part 2, the Bookmarks menu should display bookmarks for "Yahoo! 1", "Yahoo!
2", and "Yahoo! 3" (each on its own cascading menu).

One might argue that there should be no need for multiple instances of the same
URL in a bookmark file, but offhand I can think of many reasons for having such.
 For example, one might have a "favorites" section at the top, for those links
which one visits quite frequently.  But of course one would not want to delete
them from the main sections further down in the bookmarks menu, simply because
they have been added to the "favorites" section.
Duplicate of "Unable to have 2 differently named bookmarks for the same url."

*** This bug has been marked as a duplicate of 51683 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 2

16 years ago
vrfy dupe
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.