96221 - all new windows seem to ignore preferences on layout

Status: RESOLVED DUPLICATE of bug 99236

(Core :: XUL, defect)

Description

[Todd Kennedy]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3) Gecko/20010802
BuildID:    2001080214

all new browser windows (including main window when starting mozilla) seem to be
ignoring the localstore.rdf file (at least, as far as i can tell).  the sidebar,
which i keep collapsed is open on all new windows, as well as the size of the
window is very small (which i then have to expand out).  I looked in the
localstore.rdf file and noticed that all the sections dealing with the sidebar
and layout seem to be correct (i've pasted what seems to be the relavant
information in here), but mozilla seems to be ignoring them.  I'm only using one
profile, so there's no confusion there.

here are excerpts from my localstore.rdf file (though, i'm not sure this is the
file that these preferences are kept in, but it looks right...)


 <RDF:Description about="chrome://navigator/content/navigator.xul#sidebar-box"
                   width="162"
                   collapsed="true" />

  <RDF:Description about="chrome://navigator/content/navigator.xul#sidebar-splitter"
                   state="collapsed" />

                   screenX="5"
                   screenY="1"
                   sizemode="normal"
                   height="713"
                   width="1005" />

Reproducible: Always
Steps to Reproduce:
1. open mozilla

or

1. open a new window (via cmd-o or file->new navigator window)

Actual Results:  the window opens with the basic install defaults, not the
customized defaults.

the sidebar appears and the window is about 600x400 pixels big

Expected Results:  opened the window with no sidebar, and a height of 713 pixels
with a width of 1005 pixels.

this happens after a random number of days after a fresh install.  i revmoed
mozilla and all of it's preferences after the first time this happened and
re-installed fresh, but after a few days teh problem started occuring again.

Comment 1

[Greg K.]

So, you're saying you create a new profile, and you then configure the browser window 
to your liking (collapsed sidebar, arbitrary window size), but after some arbitrary amount 
of time new browser windows are created looking as they did when the profile was new?

About how much time passed before the problem was evident? How many new profiles 
have you created that show the same behavior?

Comment 2

[Marek Wawoczny]

Win2k Build ID 2001082303

When opening new window via menu, from windows shortcut - window is maximized - like I want. When opening new window via link in some pages (probably with _blank attribute) - new window  is not maximized, width is ok, but height is about 2/3 of full height of my desktop - it should be maximized. Mayby this is also related with this bug? 

Comment 3

[karnaze (gone)]

->Xp Apps

Comment 4

[Todd Kennedy]

in response to the question about how long this takes:
almost exactly two days.  i'm not sure if it's 48 hours on the dot, buit every
two days i ahve to make a new profile and import all my data into it from the
old one.

this is the third profile that it's happened on.  I'm going to create a new one
right now and i'll write down the time and hte day and check the time and day it
reverts back.

thanks.

Comment 5

[Todd Kennedy]

I've discovered a work around, as I just started to create a new profile. 
Instead of creating a new profile, all you need to do is to delete your
localstore.rdf file, quit mozilla, start mozilla and it'll create a default one,
which will accept changes and let you keep custom window configurations.

so, from what I can gather, is after a few days, or during the reading of
localstore.rdf at some point (maybe the two days thing was just a co-incidence)
mozilla either starts to ignore it's values or somehow corrupts the file on
reading it.

Comment 6

[Greg K.]

Huh. Well, when it starts happening again, attach your localstore.rdf hereon, then.

Comment 7

[Greg K.]

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

Comment 8

[Jonathan S Abrams]

Strong candidate for a dupe of bug 71402.

Comment 9

[sairuh (rarely reading bugmail)]

->toolkit?

Comment 10

[Greg Lloyd]

Attachment: corrupted localstore.rdf - always shows small window + sidebar

Comment 11

[Greg Lloyd]

As requested, above, here's a copy of a localstore.rdf that demonstrates the problem

I used the workaround suggested by Tod Kennedy (thanks!) and removed 
Mozilla:Users50:Default:localstore.rdf and let Mozilla create a new file
on next startup. But I saved the old one, and verified that swapping it
in place of the newly created localstore.rdf causes the symptom to return.

Comment 12

[Greg K.]

There are some references in that file to Mozilla 0.7 and 0.9.1. You don't have some old 
versions still on your drive that are being run accidentally, do you?

Comment 13

[John Morrison]

Thanks for attaching the example localstore.rdf.

So, that localstore.rdf has an entry like (don't know if the unprintable ascii
characters will come through intact on this posting, but they are ^C)

  <RDF:Seq about="nc:urlbar-history">
    <RDF:li>http://www.foopy.com</RDF:li>

When parsing that file, that is flagged as a well-formedness error, since
0x3 is not a legal character <http://www.w3.org/TR/REC-xml#charsets>.

So, the questions are:

1) how did those characters get entered into the urlbar history (that is then 
   persisted)? Were they copied in from somewhere else? Should the history
   have rejected them as bogus (since those characters are not allowed in 
   a URL in unescaped form) [or alternatively, should it have escaped the 
   ^C before adding them to history (i.e., encode as %03)].

2) should the RDF serializer refuse to emit these bogus characters when 
   writing out localstore.rdf (well, yes).

3) if the reading of localstore.rdf flags a well-formedness error, shouldn't 
   that file be automatically removed, since it can never be used again (well, 
   yes).

4) who wants this bug :-]

Comment 14

[John Morrison]

I split this out into a couple of bugs:
  bug 99235 -- Bogus URL's added to urlbar history will corrupt localstore.rdf
  bug 99236 -- localstore.rdf should be deleted when it is corrupt
to address points 2 and 3 above. I'm partially retracting point 2, because 
it would be painful to have to scan for illegal characters every time 
localstore.rdf is persisted to disk. Instead, I'm just shooting for not putting 
the illegal characters in the history in the first place. 

I'll leave this bug open for the time being to see if Greg can identify any 
other way that he might have gotten those bogus url's entered into his history
(other than pasting them into the urlbar and hitting Enter, which should be 
fixed by 99235.).

Comment 15

[John Morrison]

Hmm, just realized that Greg Lloyd is not the original reporter. Todd -- if you 
look in that localstore.rdf file are there any control characters? [One easy 
way to check this is to save localstore.rdf as foo.xml and then load foo.xml
into the browser -- that will flag any XML parsing errors that occur].

Comment 16

[Greg Lloyd]

I frequently cut and paste URL's from Eudora (Mac) and IE (Mac) into Mozilla
while testing a server product my company is developing. However, looking
at the URL's with bad characters (infoword.com, wired.com, eweek.com) it is
very unlikely that I entered these URLS with a direct cut and paste. 

I frequently visit these sites, and almost always type the top level domains
directly (e.g. "wired.com") rather than "www.wired.com". Possible problem in
prepending an implied "www"?

It is possible that an A tag with an invalid URL string in its href attribute
was created and stored (or synthesized) by our server, which added the bogus URL
to the history when the link was followed.

I don't recall seeing any problems following links to these locations, and have
not been able to find any problematic href values, but it seems like a path that
should be guarded to prevent corruption of the localstore.rdf history list. 

Comment 17

[Dan M]

So what's left of this bug after John split out two other bugs? Is all that 
remains John's point (1) from 2001-09-10 19:25; that is, maybe we shouldn't allow 
illegal characters the history? (In which case this bug is about to be 
reassigned, and wants a new summary.) Or having handled the repercussions of that 
in bug 99235, are we done here?

Comment 18

[John Morrison]

bug 99235 has closed off the possibility of entering bad data into 
localstore.rdf via the urlbar. There may however be other ways of corrupting 
that file. bug 99236 will do (more of) the right thing if it finds a badly 
formed file when reading localstore.rdf.

There probably isn't anything particular to do with this bug, unless another 
way to corrupt that file is identified.

Comment 19

[Dan M]

Oo! well then, in the interests of controlling clutter, I'm closing this as a
duplicate of the last open split-off bug. Thanks, John.

*** This bug has been marked as a duplicate of 99236 ***