Closed Bug 166455 Opened 22 years ago Closed 20 years ago

localstore.rdf: after manual deletion, it is recreated, but out of synchronization with prefs.js

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.7final

People

(Reporter: sgautherie, Assigned: sgautherie)

References

Details

(Keywords: fixed1.7)

Attachments

(1 file, 2 obsolete files)

Prefs.js and new LocalStore.Rdf, when bug shows up
2.15 KB, application/octet-stream
Details 
(While making some tests for another bug, I discover this "minor" bug:)


Before, I used Edit -> Preferences to remove the Search and Print buttons from
the Toolbar; which worked fine.

Now, Mozilla is stopped, and I manually delete <localstore.rdf>.

When Mozilla is started again, it recreates a new <localstore.rdf>;
but now the two buttons are back in the Toolbar :-(

At this stage, see attachment in next Additional Comment for my <prefs.js> and
brand new <localstore.rdf>.

The two buttons will then remain there even after restart;


I need to go to Preferences twice to get rid of then:
first, to re-enable the prefs settings;
second, to disable them again.
(This is the workaround which make this bug minor.)


Theses two buttons may be an example only: other "settings" might be out of
sync. too !?
See Bug description
With "Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910"

Same bug.

This might be the cause of bug 122520.
"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2b) Gecko/20021016"

Same bug.


     ***** Comment on #3

This bug is exactly what the testcase in
<http://bugzilla.mozilla.org/show_bug.cgi?id=122520#c3> describes !

Bug 122520 and others also describe file corruption or permanent failure, etc,
which is not the point of this bug.

Then I would ask to promote this bug from 'Unconfirmed' to 'New' (at least).

Thanks for checking: I did not find thoses bugs before.

bug 123929 is the profile corruption tracker.
     ***** Comment on AC#5

As I said in AC#4, I don't think that this bug is actually about "corruption";
Nevertheless, if responsible people for bug 123929 think that this bug should 
"block" theirs, I wouldn't mind.

On the opposite, I think bug 122520 (and related) "could" be set as blocking bug 
123929.

"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2) Gecko/20021126"

Bug still there.

     ***** 2nd reply to comment 5

Since there is still not much activity on this bug, I eventually tried to get
some from bug 123929 as suggested...

there are other related bugs. For instance bug 86164, where it becomes clear
that differences in toolbar button settings in prefs.js and localstore.rdf are
overruled by the rdf file.
Blocks: profile-corrupt
QA Contact: tever → nobody
not a bug in our RDf implementation. ->profile. Why on earth are we storing the
same information in more than one place?
Assignee: waterson → prefs
Status: UNCONFIRMED → NEW
Component: RDF → Preferences: Backend
Ever confirmed: true
*** Bug 147657 has been marked as a duplicate of this bug. ***
My checkin for bug 230219 has affected this bug because it now effectively
ignores localstore.rdf and in fact the "code" that saves the settings in
localstore.rdf could probably be removed.
(In reply to comment #12)
> in fact the "code" that saves the settings in
> localstore.rdf could probably be removed.

I might give it a try:
where is that saving "code" located ?
Well a "working" localstore.rdf contains two types of sections:
A per-window section, named after the xul that loads in that window.
Each entry in that section includes the id of an element in that xul.
A per-element section, named after the xul#id as above.
Each entry in that section names an attribute of the element.

There are two ways to cause an attribute to be saved:
document.persist("home-bm-separator", "hidden"); in script
<toolbarseparator id="home-bm-separator" persist="hidden"/> in the xul

In fact lines 93-105 of navigator.js could probably be cleaned up too.
Component: Preferences: Backend → XP Apps: GUI Features
Depends on: 230219
OS: Windows 95 → All
Hardware: PC → All
Attached patch (Av1) <navigator.xul> (obsolete) — — Splinter Review 
Removes the 5 button |persist="hidden"|, obsoleted by patch for bug 230219.
Assignee: prefs → gautheri
Status: NEW → ASSIGNED
Attachment #145834 - Flags: review?(neil.parkwaycc.co.uk)
So you didn't spot my subtle clue in comment 14 about the 6th xul fix ;-)
Attachment #145834 - Attachment is obsolete: true
Attachment #145834 - Flags: review?(neil.parkwaycc.co.uk)
(In reply to comment #16)
> So you didn't spot my subtle clue in comment 14 about the 6th xul fix ;-)

Not quite :-( (but I should have)

At first, I though you wanted to remove lines 93-105;
but the "button.hidden" part is required for the pref to have any effect:
that's where I got +/- puzzled and (see bug 230219_Bv1 patch for what I did).

Then I kind of "ignored" the |"home-bm-separator"| part :-(
Av1, with comment 16 suggestion(s).
Attachment #145839 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #145839 - Flags: review?(neil.parkwaycc.co.uk) → review+
Attachment #145839 - Flags: superreview?(mscott)
Comment on attachment 145839 [details] [diff] [review]
(Av1b) <navigator.xul>
[Checked in: Comment 25]

I don't think Neil nor myself are module owners for xpfe/browser you might need
to get module owner approval here.
Attachment #145839 - Flags: superreview?(mscott) → superreview+
Comment on attachment 145839 [details] [diff] [review]
(Av1b) <navigator.xul>
[Checked in: Comment 25]


'approval1.7=?':
Trivial U.I. cleanup, no risk.
Attachment #145839 - Flags: approval1.7?
(In reply to comment #19)
> (From update of attachment 145839 [details] [diff] [review])
> I don't think Neil nor myself are module owners for xpfe/browser you might need
> to get module owner approval here.

Right: I should have asked alecf for sr :-<
(neil is a (review) peer.)

jag:
Do you approve this patch ?
'blocking1.7=?':

This patch has no risk, and is a direct follow-up of bug 230219, which was
'fixed1.7': it makes sense too have both patches together.

The existing code is now useless: updating localstore.rdf is now a waste of
time/space/etc.
(Well, in fact, I didn't test how the existing code behaves exactly with the new
second check-in of bug 230219; but anyway...)
Flags: blocking1.7?
Whiteboard: [approval: waiting for comment 21 answer...]
not going to block the release for this.
Flags: blocking1.7? → blocking1.7-
Comment on attachment 145839 [details] [diff] [review]
(Av1b) <navigator.xul>
[Checked in: Comment 25]

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #145839 - Flags: approval1.7? → approval1.7+
Fix checked in to trunk and 1.7 branch.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
Whiteboard: [approval: waiting for comment 21 answer...]
Attachment #145839 - Attachment description: (Av1b) <navigator.xul> → (Av1b) <navigator.xul> [Checked in: Comment 25]
Attachment #145839 - Attachment is obsolete: true
Target Milestone: --- → mozilla1.7final
so the changes in this bug are purely cleanup of dead code from fixing bug 230219?
QA Contact: nobody → benc
(In reply to comment #26)
> so the changes in this bug are purely cleanup of dead code from fixing bug 230219?

Yes, it turned out to be almost what you wrote:
except that this (RDF update) code was not 100% dead, but rather useless/unwanted.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: