Alterations made by using �Find� in Bookmarks file revert.



16 years ago
12 years ago


(Reporter: michael.graubart7, Assigned: bugs)


Mac System 9.x

Firefox Tracking Flags

(Not tracked)




16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.3b) Gecko/20030109
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.3b) Gecko/20030109

Under Bug No. 187071, I reported a problem when making alterations in the
Bookmarks file. At first I thought that the bug occurred sporadically. Then I
discovered the circumstances in which this bug appears and added further
explanations, but the report remains somewhat confused. As the problem is a
serious one, I am now making a new (and, I hope, clearer) report, which
supersedes 187071.

The problem only arises if ‘Find’ (Command + F) or the ‘Search’ slot at the top
of the ‘Manage Bookmarks’ page is used. If this is done, a change made to a
bookmark remains in place until Mozilla is shut down and reopened and another
bookmark is changed. At that point the original change is nullified and the
first bookmark reverts to its original state. The same applies to deletions.

This means that the only way to make changes that are permanent is either to
locate bookmarks by searching manually through ‘Manage Bookmarks’, or to open
the ‘bookmarks.html’ file itself, locate the bookmark to be changed by means of
‘Find’ (Command + F) and then go to the ‘Manage Bookmarks’ page, find the
bookmark manually with the help of the information gained from ‘bookmarks.html’
and make the change.

This bug is still present in Build No. 20030109 and in Build No. 20030121 (which
I am not using because it has other, new, bugs).

Reproducible: Always

Steps to Reproduce:
1.  Open ‘Manage Bookmarks’.
2.  Use ‘Find’ (Command + F) or ‘Search’ to locate a bookmark.
3.  Click on the name of the bookmark in the results of Find or Search.
4.  Click ‘Rename’ or ‘Properties’ or type Command + I.
5.  In the resulting window, make a change in the name of the bookmark.
6.  Go back to ‘Manage Bookmarks’ to verify that the change has occurred.
7.  Quit from Mozilla.
8.  Restart Mozilla and open ‘Manage Bookmarks’. Check that the alteration is
still intact.
9.  Repeat nos. 2 - 5 above with a different bookmark.
10. Go back to ‘Manage Bookmarks’.

Actual Results:  
At 10. above, the bookmark that was changed at 5. above has reverted to its
original state. The change made at 9. above is retained (until Mozilla is shut
down, reopened and yet another bookmark is changed).

Expected Results:  
At 10. above, both changes should have remained.

Mac G3 (old beige tower), OS 9.2.2. Modern theme.

Comment 1

16 years ago
This could be bug 51683 or bug 114869 dupe. Find is often used by those who have
multiple bookmarks for the same URI. Reporter, does this happen on every renamed

Comment 2

16 years ago
Mrmazda, Yes, it happens with everything I have tried it on. Certainly with ones
that are not duplicated in my bookmarks file.

Comment 3

16 years ago
I should like to add another comment. Putting this bug together with all the 
numerous requests for a system that shows where a found bookmark is located 
within the set of folders in the bookmarks file, is it not time to consider going 
back to the system in Netscape 4.x, where 'Find' simply highlights a bookmark 
within the 'Edit bookmarks' page, just like in a word-processing document? It is 
simple, elegant, foolproof, locates the bookmark and prevents any possibility of 
alterations being undone by subsequent changes. I see no advantage at all in the 
Mozilla system in which a found bookmark appears in a new window, other than that 
if there are several, it saves a little time otherwise spent in 'Find again'.

Comment 4

16 years ago
It's much simpler than this! (I may have got confused, since some of the URLs I
tried to alter did have similar names.) The simple fact is that any alteration
made to an URL found by means of 'Find' or 'Search' has reverted again after
Mozilla has been shut down and re-opened. There is no need to make a further
change in another URL.

Comment 5

16 years ago
I think I have discovered the reason for this bug. In Mozilla, 'Find' and
'Search' find items not only in bookmarks.html, but ALSO IN 'HISTORY'. So when
one changes something, it reverts because the original version is still there in

I tried removing bookmarks.html from tibonwlx.sit in my Profile folder and
restarting Mozilla, which created an empty bookmarks.html file. Yet if I used
'Search' it found all the bookmarks that I might have visited in the last 30 days.
Obviously changing these would not change the actual bookmarks.html file.

It is actually not quite as simple as this, because when I still had my full
bookmarks.html file in place, I did check that when I had made an alteration,
this alteration actually appeared (temporarily) in bookmarks.html. But somehow
it is the version that is contained in 'History' that then gets copied back into
the bookmarks.html file the next time something is changed.

(I believe that my last comment, Comment No.4, is not always correct. There is
scope for endless confusion between items that are in 'History' and ones that
are not.)

Comment 6

16 years ago
Yet further observations:
See Comment #8: the phenomenon cannot, after all, have anything to do with
'History', because I have now tried making alterations in bookmarks whose sites
I have not visited and which, therefore, do not appear in 'History'. But the
following observation (from Comment #8) still basically holds, as long as the
reference to 'History' is removed:

'I tried removing bookmarks.html from tibonwlx.sit in my Profile folder and
restarting Mozilla, which created an empty bookmarks.html file. Yet if I used
'Search' it found all my bookmarks.'

What this means is what I originally suspected, namely that 'Find' and 'Search'
somehow create their own copy of the bookmarks file and access this when making
further changes.

Comment 7

16 years ago
It has only just occurred to me, I am afraid, to search for possible copies of
bookmarks.html -- and I have found TWO!

PLEASE would someone tell me whether I should delete one or other or both of
these, and whther I need to keep deleting them in case they reconstitute themselves?

My main one is in Mac HD - Documents - Mozilla - Profiles - Michael Graubart
(Mozilla) - tibonwlx.sit. (This is the one that changes as soon as I make any
changes, as confirmed by the time and date in 'Information'.)

The two I have now discovered are in Mac HD - Applications - Mozilla folder -
defaults - profile, and in Mac HD - Applications - Mozilla folder - defaults -
profile - US.

These may have something to do with the previous Mozilla build that was active
before I installed the one I am now using, which is 2003011508.

Comment 8

16 years ago
Merciful Heaven! I believe I have solved this problem - or non-problem, as it
seems to have turned out.

When I upgraded to successive 'Nightly builds' of Mozilla, I retained my
profile. I have now deleted the Mozilla folder in 'Documents' as well as that in
'Applications', started from scratch, installed Mozilla Build No. 2003011508
(the last OS 9.x one I could find before the mail-addressing problems began) and
created my profile anew. So far the problem has not reappeared. (If it does, I
shall return to the fray.)

Comment 9

16 years ago
Please reopen if the problem reappears.

Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 10

16 years ago
Cplyon: I have just filed an additional comment (Comment 38) to Bug Report
56418, which refers to what I think is the source of the earlier problem of
bookmark alterations reverting; filed in Bug 56418, because the cause seems to
be a procedure, or procedures, recommended there.
Summary: Alterations made by using ‘Find’ in Bookmarks file revert. → Alterations made by using �Find� in Bookmarks file revert.

Comment 11

16 years ago
It has recurred, even though (see comment 10 below and Bug 56418) I have been
very careful and not tried to open the bookmarks.html at all. This is how it now
seems to happen:

1. Open 'Manage Bookmarks.

2. Use 'Find' or 'Search' to find a bookmark. Use 'Command + I' or 'Properties',
make a change to the name.

3. Close Mozilla.

4. Restart Mozilla. THE CHANGE IS STILL THERE.

5. Use 'Find' or 'Search' to find a different bookmark. THERE IS NO NEED TO MAKE

6. Look at the originally changed bookmark: THE CHANGE HAS GONE, THE NAME HAS

NB: I am using Build 2003011508, because later builds do not work for Mac OS
9.2.2.  I am using Modern theme.
Resolution: WORKSFORME → ---

Comment 12

16 years ago
One more comment, or rather request: could someone PLEASE tell me which file can
possibly be responsible for 'remembering' an earlier state of a bookmark and
restoring it to the bookmarks.html file when 'Find' or 'Search' is used? And
whether it is possible to remove whatever file it is permanently?

I said in an earlier comment, either in this bug or in bug 56418, that I had
discovcered that if I remove bookmarks.html from my profile altogether, all my
bookmarks are still there when I open the bookmarks window or the 'manage
bookmarks' window, which proves that somewhere there is another file that stores
them all.

Comment 13

16 years ago
The situation became intolerable: every time I deleted or changed something in
my bookmarks list, all the old changes were undone. So I once again had to
uninstall all components of Mozilla, reinstall and reconfigure it and import my
Netscape bookmarks. Now it appears to work correctly. But the questions remain:

1. Why does it go wrong so easily?

2. How is it that if 'bookmarks.html' is removed from my profile and trashed,
going to 'Bookmarks' or 'Manage Bookmarks' shows a blank page, but if in the
apparently empty 'Manage Bookmarks' I use 'Find' or 'Search', all my old
bookmarks can still be found? (It is this, I am sure, that causes changes to

The Netscape bookmarks that I imported were actually on a previous occasion
back-imported from a Mozilla bookmarks list. The fact that it now works in
Mozilla suggests that whatever was corrupted was not data actually stored in the
bookmarks.html file, but somewhere else - or in the application itself.
Bugs are targeted at mac classic, which is dead. Marking WONTFIX. Please reopen,
if you can reproduce the bug on Mac OS X with 1.5beta or later.
Last Resolved: 16 years ago15 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.