who is going to work on this?

Re-assinged to mcmullen@netscape.com. John, are you the right Mac geek for this, or should I give this to Gordon or David?

I'll have a shot. Accepting bug. Changed platform to Macintosh (was PC).

This is not a very well-written bug report (to put it politely). Where are the steps to reproduce? The expected behavior? The actual behavior? I'm inclined to mark it invalid, but perhaps the reporter would care to add some information to make the "invalid" description less appropriate? Thanks.

This is not a very well-written bug report (to put it politely). Where are the steps to reproduce? The expected behavior? The actual behavior? I'm inclined to mark it invalid, but perhaps the reporter would care to add some information to make the "invalid" description less appropriate? Thanks.

I first notice that there is a NU_CACHE macro which was not defined in the build. OK, I can define that in the Macintosh build, but how do I test whether this works or not. Was the problem simply to add the define to the build? Or had somebody tried that and encountered problems? If the latter, what problems were encountered?

Progress so far (based on pure guesswork, you understand). I have, in my tree, done the following things: 1. Turned on NU_CACHE globally. 2. Added all the nucache source files to the Macintosh build. 3. (Fixed a few hundred warnings in the memory module) 4. Rebuild is in progress. I still need some test scenarios, or instructions about where to set a breakpoint, or something, to make sure that this stuff is working.

If you do the things you have done (per our talk), then going to a page, clicking on a link and then using back to get back to the original page should work. The rest can be taken care by gagan. And sorry about the bug. It was more of a place holder until gagan got back from his vacation. Gagan can you work with mcmullen on this bug. Rather possibly take the lead on this and use only McMullen's help to resolve this. I am very happy to see mcmulen's initiative.

Well, problem is I have a bazillion changes in my tree, so I have to "own" this at least till I check my tree in.

Well, I talked to Gagan today. It turns out to be impossible to do this: the "opendb" call fails, because there's no code behind it. This is true on Unix and Macintosh. So what I've done is make this stuff at least BUILD with and without the NU_CACHE option defined. Ishall check in all my changes to make it build, but leave the NS_CACHE flag off. Then I shall assign this bug back to Gagan. I shall be happy to help when some database code is ready to support this truly.

upping severity to p1 - critcal after talking with don..

I'm ready to check in, whenever the tree might open.

Checked in. NU_CACHE is still off, but if you turn it on, it builds. It should not be run in this state, however, until the db code is installed.

Have switched off NuCache on all platforms. Will be switching it back on simultaneously. Marking it fixed for now.

Ooops really meant to remove PP, really really really... :-)

Setting all current Open Critical and Major to M3

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

Nu cache not turned on until after N2 lands. Marking M4.

Nu Cache is not enabled in M4. N2 has been canceled.

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

Necko still has not landed, shooting for M9

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Deferring till cache gets operational in Necko.

Marking component as cache.

Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache component.

LATER is deprecated per bug 35839.

WONTFIX, the code is dead.

VERFIED/WONTFIX: CFM-RIP