BuildID: 2000061311 I think periodically mozilla's cache is mistranslating URLs when looking cache data up. I had this happen yesterday and on todays build. Predictable reproduction is not possible (yet). I will give you an exact recouting of how it just happened, but it did happen yesterday without the proxy setting changes that I will mention. I opened mozilla. It opened the releases page. I went to slashdot. I hit the stop button before slashdot could fully load. I went to the advanced preferences and enable the manual proxy configuration which had previously been entered. I went to the AIChE's website (www.aiche.org) I went to the Career and Employment Services page. I went to the list of employers page. I went to TV Guides website (www.tvguide.com) I went to their TV listings page. I did some perusing and clicking on links (next time slot, descrp) *** Now I entered the URL for slashdot (www.slashdot.org) After clicking enter the TV Guide main webpage came back up!? Repeated entry of the slashdot url just brings up TV Guide. I force a reload - finally slashdot appears.

I just reproduced the bug by: Open Mozilla. Go to slashdot Go to CNN Go to linuxtoday Go to slashdot Go to linuxJOURNAL Instead of taking me to linuxJOURNAL it took me to linuxTODAY. I went back to slashdot then tryed linuxJOURNAL again. This time it took me to linuxTODAY and crashed. This seems to cause pretty regular crashes once it happens some I'm upgrading to critical. Two talkbacks of the crash were captured and sent. TB12363418E TB12359864G

You know, this may not be a cache issue but a URL autocomplete problem. I just noticed if I type the URL slower, periodically mozilla is brainfarting on the autocomplete. Sometimes i'll be typing www.slash (for slashdot) and it'll append some >> www.cnn.com crap on the end of the URL. I noticed it was doing this when it was feeding me www.slaughterhouse.com when I typed www.cnnfn.com. Also, once I was on www.pricewatch.com and I entered www.slashdot.org. Mozilla tried to load slashdot in one of the sub-frames of the pricewatch page! Weird. I really think the address bar is feeding fubar addresses to the network engnie so I'm going to try and figure out what component that is and get this bug switched over.

Autofill... I hope that is the same component as autocomplete on the URL. I think that's where this problem really lies.

I have experienced this bug plenty of times on Linux, which doesn't have URL autocompletion. It also occurs from the "Open Web Location" menu selection, further implying that the address bar itself is not at fault. Sometimes (but not always) I seem to be able to work around it by opening the Preferences 'Cache' panel and pressing both cache clear buttons, but this is not 100% reliable; it may be luck that it works.

OK, I have more info about this bug. It looks like it might be disk cache related, and can be reproduced by URL drag+drop between windows. I'm running a nightly build on Linux; the about info says: Mozilla M16 Mozilla/5.0 (X11; U; Linux 2.2.15 i586; en-US; m16) Gecko/20000615 To reproduce: 1) Start Mozilla at a home page with multiple links. 2) Select "New Navigator Window" from the File menu. 3) Drag a link (e.g. http://www.linuxtoday.com/) from the initial window (window #1) to the new window (window #2). 4) Focus window #2. 5) Click 'Home' in window #2. This will work correctly. 6) Still window #2, click on a link on your home page (not the link you originally dragged). This will fail: the URL shown in the address bar will be correct, but the wrong page will be rendered. Details on the exact nature of the failure follow. The failure persists across a quit+restart of Mozilla, suggesting disk cache involvement. Manually clearing the disk cache from the Preferences window fixes it, causing the correct page to render the next time Enter is hit in the address bar (to force a reload). The specific failure behavior is that the file part of the URL is out of sync with the queried server. Details: -- My (inside firewall, sorry) home page is http://in.bluemug.com/~miket/homepage.html -- When I trigger the bug by clicking on a URL with no file part (e.g. http://www.slashdot.org/) I see instead the root page of the server on which my home page lives: http://in.bluemug.com/. The address bar shows the correct Slashdot URL, though. -- When I trigger the bug by clicking on a URL with a file part (e.g. http://www.linux.org.uk/diary/) I get a 404 not found, because Mozilla is asking the wrong server (http://in.bluemug.com/) for '/diary/'. If I remove the 'diary/' from the URL in the address bar, leaving http://www.linux.org.uk/, and hit Enter, I once again see the contents of http://in.bluemug.com/. In summary, the file part of the URL is working fine, but the server part is screwed up. I'd suspect DNS caching if it weren't persistent across restarts; does Mozilla do file caching of DNS lookups (doubt it)? Does the file cache separate the URL components in a way that would allow them to get out of sync? BTW, I'm not sure if it's OK to change the OS field from 'Windows 95' so I'll let the bug's owner do it.

OK, yet more info :-). The bug only occurs when I'm using the Junkbuster cookie-eating/ad filtering proxy. If set my 'Proxies' setting to "Direct connection to the Internet", I can't reproduce the bug given the steps below. My Junkbuster proxy configuration uses the "Manual Proxy configuration" radio button with both FTP and HTTP proxy set to localhost, port 5865. My hunch is that this is a Mozilla bug, not a junkbuster bug. Reasons: -- Same proxy works fine with Netscape 4.x -- Fixed by hitting 'Clear disk cache' in Mozilla, but persists across Mozilla restarts, as described earlier. -- _Not_ fixed by stop/restart of junkbuster daemon, which doesn't do any file caching as far as I know. BTW, I checked the Debian bugs DB for relevant junkbuster bugs, but nothing looks relevant.

Linux, build ID 2000061520 Linux has had autocompletion for a while now. Can you see what happens when you "disable" the cache by setting both disk and memory cache to size 0? Don't forget to clear them. Btw, I've seen something else happen, which needs unlucky timing: http://slashdot.org/ http://www.cnn.com/ http://www.linuxtoday.org/ --> http://slashdot.org/ Upon typing enter after the last one, http://slashdot.org/ showed in the URL and then was displayed. But it's rather hard to reproduce. Hmmm, I've tested some more, now it's becoming interesting: I typed http://www.linux, waited for a bit, it showed http://www.linuxjournal.com/ as an option in a dropdown menu. I typed a t and waited a bit, it still displayed http://www.linuxjournal.com/ in the dropdown menu, and added " >> http://www.linuxjournal.com/" in the urlbar. I typed the rest: oday.com/, waited a bit, and still the only option was http://www.linuxjournal.com/, and " >> http://www.linuxjournal.com/" added in the URL bar. Upon pressing enter, I was taken to linuxjournal and not to linuxtoday.

Linux may have autocompletion, but I've sure never seen it :-). How do you turn it on? I can type 'www.lin' in the address bar and wait all day, and nothing happens; is this a bug? This report's bug still occurs with 0 size caches. I set both cache sizes to zero, cleared both using the buttons, and also unchecked both 'Use Cache' boxes in the Debug preferences. Also, my note about needing to press the cache clear buttons to get the page to load correctly doesn't hold up; if I continue to press reload and/or enter in the address bar without doing anything else, the page will sometimes load correctly (although it can take several tries). Also, sometimes pressing the cache clear buttons doesn't work. At first I thought that I was wrong to associate pressing these buttons with clearing up the bug, but further testing suggests they are at least weakly related [see below]. I just got Mozilla into a state where it was trying to fetch my home page from linux.com (so I got linux.com's 404 page when I pressed Home). For the sake of experiment, I tried reloading it 30 times (using a combination of reload button, Enter in address bar, and Home button) without any success. I pressed both cache clear buttons, and the next load succeeded. So the sequence is: 1) Try 30 reloads => still wrong page. 2) Pick Preferences from menu. 3) Navigate to Cache panel. 4) Press both cache clear buttons. 5) Press OK. 6) Try another reload => correct page loads. I repeated the experiment, without actually pressing the clear buttons: 1) Try 30 reloads => still wrong page. 2) Pick Preferences from menu. 3) Navigate to Cache panel. [don't hit cache clear buttons] 4) Press OK 5) Try another reload => still wrong page. [ObRandomBugHunch] I usually couldn't go 30 reloads without getting the right page. Maybe the cache clear business is often working because it delays me, and the problem is somehow fixed by a minute rollover?

Scratch my comment about autocompletion; I got it to work (I'd gotten in the habit of leaving out the protocol part of the URL when typing it in manually). There may be two bugs here, though, since the one I've been describing can be reproduced without any typing in the address bar.

Interesting. I too use the JunkBuster proxy to filter cookies and ads. I went back to test it without JunkBuster. I was able to get it to exhibit its incorrect behaviour so while JunkBuster may or maynot exacerbate the condition, it is not required. Secondly, I tried clearing out the cache. This prevented the problem from occuring for a couple minutes, but eventually it came back and I got the page mixup followed by a crash. Finally, I tried clearing and disabling the cache. This proved to eliminate the problem. A couple of times the autocomplete overrode my manually type URL and I ended up at linuxjournal instead of linuxtoday, but the address display and the page that were shown were never out of synch. I was not able to reproduce the drag 'n drop example of this problem on Win95. My gut feeling (which is usually wrong) is that there is some bad mojo between the autocomplete and the network cache. But wait, didn't somebody say they saw this in the "Open From Web" box? Geez, I dunno. If somebody wants to change this back the the Network Cache component - no complaints from me.

You guys are talking about two separate bugs... I've seen them both; one already has its own report in mozilla (#38488). There is a workaround listed in the comments to that bug, that involves adding a line to your prefs.js file to turn off HTTP 1.1 keepalives (or something like that). This workaround works. Even after activating this workaround, though, I still see some occasional URLbox/autocompletion weirdness that results in taking me to the wrong page. I can't give further details on that, but hopefully now all of us Junkbuster users can work around the Junkbuster-related bug to focus on the autocompletion bug that shows the same symptoms.

I've seen something similar and I'm wondering if it is the same bug or not. I start up the browser and go to http://slashdot.org (which generates a page from based on my cookie, since I've previously logged in). I click on any link I like and then press the back button. At this point the browser is displaying an old slashdot page from late June -- the one I saw before I logged in. This has nothing to do with autofill, the component currently (erroneously?) listed for this bug.

Wayne: What you describe reminds me more of bug #25395 than this one.

neeti is this a dup of the slashdot.org bug that you have?

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

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

Netscape nav triage team: based on Steve Morse's pretriage recommendation, this is not a beta stopper.

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

severity critical and target milestone future don't get along very well... anyway, i'm hoping the new cache would fix this? gordon?

yup the new cache should fix this. marking for 0.9

Changing component to networking:cache.

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

Cache bugs to Gordon

this should be fixed in the new cache, marking as such

verified