Closed Bug 96393 Opened 23 years ago Closed 23 years ago

Some localstore.rdf persistence is broken (post 8/17)

Categories

(Core :: XUL, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: jrgmorrison, Assigned: danm.moz)

References

()

Details

Overview Description: Some aspects of persistence with localstore.rdf are broken in builds after 8/17, at least on win32. Steps to Reproduce: 1) create a new profile; shutdown 2) delete localstore.rdf from that profile 3) start again -- a new localstore.rdf will be created 4) type 'http://jrgm/setibench.html' in the urlbar (this will run some JS that will resize the browser window) 5) type 'http://www.mozilla.org/' 6) do 'File->Exit' 7) check the timestamp on localstore.ref -- is it current (i.e., now)? 8) start again -- what size is the browser window? 9) drop down the history popup in the urlbar -- are the two URLs above listed in the dropdown? Actual Results: 8/20 & 8/21 comm. builds win2k -- No, default size and no. Expected Results: 8/17 comm. build win2k -- Yes, 800x600 and yes. Reproducibility: 100% win2k -- need to check mac/linux Possibly a leak; possibly something changed in persisting code path.
This applies to linux 8/21 builds, but not to Mac 08/21 builds. I should note that if you resize the window and then quit, then the window size and URLs are persisted. Probably need to fix this, or at least figure out how much is affected, for the emojo release.
Blocks: 99194
Dan/Peter - This not targeted, but has an nsenterprise+ keyowrd. Additonally, this hasn't been commented on in a while. Status Please .. .Will this be fixed this week?
Okay, after exercising my talent for performing incredibly repetive and boring tasks, I have narrowed this down some more. In favour of getting the specifics right, I only did this on win32. This is only a problem in the commercial builds. I don't see this problem in a current trunk build for mozilla, but I do see it in either the commercial trunk or commercial branch for today. If I type a URL into the urlbar to load a page, then do File->Exit, then localstore.rdf will not be written to disk at program exit. Any other changes during the session, such as resizing the window or (un)collapsing the sidebar will be lost, in addition to any URLs that are typed into the urlbar. If I do _not_ type in a URL, then localstore.rdf _is_ written to disk, and resize/collapse state will be saved. It is only when I use the urlbar, that persistence is broken.
... and let me one step further: if I just type "asdfasdf" in the urlbar (without hitting enter), then localstore.rdf is not persisted to disk at program exit. [Guess: "So what evil Netscape goo attached to the urlbar is causing a leak?"]
Any chance of making it so there aren't any destructors in the stack where localstore.rdf is written to disk?
I think we need to figure this out and get it fixed for N6.2
Keywords: nsbranch+
dbaron: sure, we could move it somewhere else. But then we'd never find these great leaks, would we? :-) jrgm: do you have to _type_, or is just _clicking_ in the URL bar sufficient to cause the leak? If not, how about causing the URL bar to drop-down?
I believe that I need to _type_, not just click, although a single keystroke is sufficient. [I'll check that statement and update the bug]. Note that the checkins on the comm. branch from morning 8/17 to afternoon 8/20 amount to the addition of a single property to navigator.properties, a property that was already on the mozilla branch. However, in the same time period, hyatt landed his popup changes (which triggered a few other leaks). It may be possible to do this in a mozilla build. Or, at one point, this seemed to happen to me using a mozilla build (current trunk) but when I went back to try again, I couldn't figure out the right set of steps to reproduce. [Perhaps some change in ordering of event listeners makes this 100% on a comm. build, and now-you-see-it-now-you-don't on a mozilla build].
So, I can click to bring up either the history dropdown, or the keyverbs dropdown, I can use the keyboard navigation keystrokes in the urlbar (home, end, <-, ->, etc.) and I can even enter text into the middle of the current URL (e.g, home.asdfnetscape.com). But, if I enter text so as to bring up the autocomplete popup, then other persistable changes (e.g., resize window, collapse sidebar) are not persisted at program exit.
removed keyword nsbranch since it now has nsbranch+, per pdt mtg.
Keywords: nsbranch
I can't get the autocomplete popup to pop up in my Linux commercial debug build. (Hitting enter in the URL bar also doesn't work in my Linux commercial or Mozilla debug build, and hasn't for months, although it's fine in my optimized build.) But localstore persistence seems OK for me even in my Linux commercial optimized build, where the dropdown works.
I can't reproduce this on my Win2k build. Been trying for quite a while. I've tried Mozilla and Netscape debug builds from this morning's source, and a Netscape 0.9.4 prefab build (2001-09-26-05-0.9.4). I've tried John's steps above from 2001-09-12 22:12 and 2001-09-12 22:08 (mostly the latter). I've also tried my own version of the original overview steps (http://jrgm/setibench.html doesn't seem to exist any longer, so I used this test file:) <?xml version="1.0"?> <?xml-stylesheet href="chrome://navigator/skin/" type="text/css"?> <!DOCTYPE window> <window align="horizontal" xmlns:html="http://www.w3.org/1999/xhtml" xmlns ="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" title = "localstore.rdf persistence test"> <box> <button label="resize window" onclick="window.resizeTo(400,300)"/> </box> </window> Load it, click the button to resize the window, hit File->Exit. I've tried other variations. It's always worked for me. localstore.rdf's timestamp is always updated after exiting the app and any window sizing I may have done has always stuck. I appreciate your working on this so much, John, but well, maybe it was a leak that's since been fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
yep, I can't reproduce this anymore branch or trunk builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.