42453 - URL gets mismatched to cache data

Status: VERIFIED FIXED

(Core :: Networking: Cache, defect, P3)

Description

[Stephen Anderson]

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.

Comment 1

[Stephen Anderson]

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

Comment 2

[Stephen Anderson]

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.

Comment 3

[Stephen Anderson]

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

Comment 4

[bugzilla-CI4Yexa]

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. 

Comment 5

[bugzilla-CI4Yexa]

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.

Comment 6

[bugzilla-CI4Yexa]

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.

Comment 7

[Peter "jag" Annema]

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.

Comment 8

[bugzilla-CI4Yexa]

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?

Comment 9

[bugzilla-CI4Yexa]

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.

Comment 10

[Stephen Anderson]

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.

Comment 11

[sungod]

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.

Comment 12

[Wayne Davison]

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.

Comment 13

[Stephen Anderson]

Wayne:

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

Comment 14

[Gagan]

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

Comment 15

[Asa Dotzler [:asa]]

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

Comment 16

[Keyser Sose]

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

Comment 17

[Marcia Knous [:marcia]]

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

Comment 18

[Keyser Sose]

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

Comment 19

[Fabian Guisset]

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

Comment 20

[Gagan]

yup the new cache should fix this. marking for 0.9

Comment 21

[neeti]

Changing component to networking:cache.

Comment 22

[neeti]

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

Comment 23

[neeti]

Cache bugs to Gordon

Comment 24

[Tom Everingham]

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

Comment 25

[Tom Everingham]

verified