642791 - returning to an ftp page uses cached values

Status: RESOLVED INACTIVE

(Firefox :: General, defect)

Description

[Marc Auslander]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

I've noticed this in the nightly tree using ftp://
If an entry has changed I won't see the change until a do ctrl-r
I'm guessing the cache is being used.
AFAIK, this behavior is new in R4, but it's been around for a while I think.

Reproducible: Always

Steps to Reproduce:
Can't be reproduced without access to an ftp server to manipulate.
Actual Results:  
See old values until ctrl-r.  For example, might see
build1 ...

then there are several build directories.

Expected Results:  
Should fetch fresh values every time.

I've only noticed this in the firefox build trees.

Comment 1

[Tim (fmdeveloper)]

Reporter -> Are you still experiencing this issue with the latest version of Firefox 4? Does the issue occur with the latest nightly? http://nightly.mozilla.org/

Comment 2

[Marc Auslander]

Just reproduced it with 4.0 released version.  Visited the nightlies, and the directory dates of lastest... showed as 4/7.  After ctrl-r, they were 4/9.

It's not easy to test.  You have to visit an ftp site - I use the firefox nightly page, and then wait till it changes!

I'm not running the nighties right now - but is there any reason to believe this has changed since the 4.0 release?

Comment 3

[Tim (fmdeveloper)]

Not able to reproduce on Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110903 Firefox/9.0a1 ID:20110903030832

Is this still an issue with Firefox 6 for you? Are you behind a proxy?

Comment 4

[Marc Auslander]

I just reproduced this with 6.01.  I must stress that I have only seen this with the firefox nightly ftp page.  I reproduce by visiting the page, waiting for a build cycle (next day) and then visiting the page again.  The dates for the nightly builds will be the previous day until I refresh.

Comment 5

[Tim (fmdeveloper)]

I will test again using ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Are you behind any proxies?

Comment 6

[Marc Auslander]

I have a straight ISP connection.  The reproduction I reported above was from a Hotel connection - again direct internet.  No proxies involved.

Comment 7

[Tim (fmdeveloper)]

I have been unable to reproduce in 3.6 or nightlies.

Please attach the contents from about:support as a text attachment to this report

Comment 8

[Tim (fmdeveloper)]

Marc -> Still an issue? Please attach the contents from about:support as a text attachment to this report

Comment 9

[Marc Auslander]

Attachment: requested about support contents

Yes it still happens.  The last time I visited the ftp page was 9/21 and today if I visit it with my normal profile, even in safe mode, it's still 9/21.  If I visit the same URL with a clean profile, I get today's data.

Comment 10

[Marc Auslander]

To clarify the above - I am NOT saying that an empty profile works correctly, only that visiting the url in a profile that has not seen it works.  I'll try the empty profile tomorrow and report.

I am now running the beta.

Comment 11

[Marc Auslander]

I have reproduced this using a completely new, empty profile.  So it is not add-on related.

I'm surprised you can't reproduce this.  Remember to use:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

the ftp access to the list.  Visit it, wait till tomorrow, try again.

Do NOT clear any private date, including the cache, between the two attempts.  Clearing the cache, even just the last hour, prevents the failure.

Comment 12

[Tim (fmdeveloper)]

I can not reproduce with a new empty profile regardless of how long I wait between visits. I have tried on 3.6 and the latest nightly.

Added qawanted flag to see if someone in QA can reproduce.

Comment 13

[Alfredos-Panagiotis Damkalis [:fredy]]

Not able to reproduce too. Marc does this bug still shows up?

If yes, could you describe exactly which are your movements to reproduce this, for example, writing this address, then pressing that button etc.

Comment 14

[Giovanny Gongora [:gioyik]]

Unable to reproduce and confirm this issue, because all is working great in:

Aurora 15 and Firefox 14.0b12 build1
Linux x86-64

Comment 15

[u279076]

Please reopen this bug if it's reproducible in the latest Nightly.

Comment 16

[Marc Auslander]

Attachment: web page after visiting the ftp url two days after the last visit

Comment 17

[Marc Auslander]

Attachment: page after ctrl-r

Comment 18

[Marc Auslander]

It still fails for me on the beta - this time tried on a Windows 7 system.  Previous reports from Windows XP.  This is clearly not a big deal, so ignoring it makes some sense.  I'm just bemused by the fact that only I see it.

Comment 19

[Alfredos-Panagiotis Damkalis [:fredy]]

I tried some minutes before with the stable linux 64bit version (v13) and with a new profile.

I connected on my ftp server and see the list of the files. Then I uploaded  a file on it from the same pc.

Then I copied the ftp address and pasted it in a new tab, firefox gave me the same page, without the new file. I tried, in this occasion, to open the ftp site with other ways like using the newtab page or loaded it on an old tab with other site already loaded.

All the ways bring the old ftp page. After reloading the ftp page, I saw the new file.

I tried to reproduce this behavior. Firstly by deleting the file from my server, reload the ftp page and adding the file on ftp server again. I couldn't anymore reproduce it, the new pages had the new file.

I also tried to create a new profile again and test it, but one more time I couldn't reproduce it.

I will have some more tests on this (on linux and windows), trying to find a way to reproduce this behavior.

However, I have some suspicions that this bug has to do with networking setup/options outside firefox, but still not sure about it.

Comment 20

[Serg Iv]

I still have this issue in 17.0.2 with Mozilla's ftp (ftp.mozilla.org).
BTW this bug looks like a duplicate of bug 394550.