Closed Bug 30852 Opened 24 years ago Closed 24 years ago

Image cache not refreshed on reload

Categories

(Core :: Graphics: ImageLib, defect, P3)

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: roberts, Assigned: pnunn)

References

()

Details

(Whiteboard: [nsbeta2+] ETA 8/02)

The graphics (a chart, in this case) does not update when the reload button is
used. In fact, from the point that the graphics component is first loaded it is
never refreshed, even if the URL is re-entered.

--Doug
Not seeing a problem on NT.  investigating to see if this is already reported.
roberts@tsasa.lanl.gov, can you make sure that you include the build ID (month,
date and hour of the build, found in the lower right in the status bar)  This is
really helpful (necessary) information for all bug reports.  Also could you
include the exact steps you take when this bug happens.  Steps to reproduce may
look obvious but sometimes a bug can only be repeated by following a strict
order or process. In your example below you migh include whether or not this is
the first page you load when you open the browser, what other pages you viewed
before you viewed this page, what on the page is updated (in addition to what
isn't).  These details can sometimes mean the difference between a bug getting
FIXED or getting marked WORKSFORME.  And thank you for all the help in testing
and reporting bugs.
This is still ocurring on build id 2000030709 -- Doug (roberts@tsasa.lanl.gov)
Problem still exists with build id 2000031517. Has this one been deferred til
after beta?

--Doug
*** Bug 32268 has been marked as a duplicate of this bug. ***
OK, I see this on build 031708.

Steps to reproduce:

Load http://finance.yahoo.com/q?s=^IXIC&d=1d in mozilla.
2.  Note teh date and time in the image (chart in the center of the page).
3.  Wait a few minutes and hit reload button (or enter in the address bar) to 
reload page.
4.  Look at image date and time.

Results:  Image is not updated.
Expected Result: Image is updated.

Other information:  the image URL is http://ichart.yahoo.com/b?s=^ixic
loadint this URL will provied a simpler test case.  Load 
http://ichart.yahoo.com/b?s=^ixic in mozilla and then load it again a few 
minutes later and it is not updated (cached?).  Nav 4x and IE 4 both update the 
image when reloading.

Sending this to Networking.  gagan, if this isn't yours please help us find a 
better place for it (maybe gordon?).  Thanks
Assignee: cbegle → gagan
Component: Browser-General → Networking
QA Contact: asadotzler → tever
Shouldn't this bug status be changed from "UNCONFIRMED"? The bug is still in
build 032018.

--Doug
COnfirming to help put it on appropriate RADARs
Status: UNCONFIRMED → NEW
Ever confirmed: true
This must be stealth bug (invisible to RADARs).

--Doug
->davidm
Assignee: gagan → davidm
Component: Networking → Networking: Cache
Keywords: beta2

*** This bug has been marked as a duplicate of 21137 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
verified dupe
Status: RESOLVED → VERIFIED
I disagree that this is a dupe of 21137: the behavior of this bug is the
opposite of that described for 21137. This bug has also found it's way into the
Netscape 6 prelease.

--Doug
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Target Milestone: --- → M16
Whiteboard: 1d
This bug is still in M15.

--Doug
Keywords: nsbeta2
*** Bug 26207 has been marked as a duplicate of this bug. ***
Problem calculated the expires header do to use of unsigned math and subtracting 
a big number from a small one. Verified that we are hitting the net for a if 
modified.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Keywords: beta2
Resolution: --- → FIXED
verified on Linux 2000042709
Status: RESOLVED → VERIFIED
Pardon me, gents & gentarinas: but the following has absolutely no meaning to me
(a software gent myself w/25 years experience in both creating & squashing bugs)
(or, to put it another WTF are you talking about?):

"Problem calculated the expires header do to use of unsigned math and
subtracting 
a big number from a small one. Verified that we are hitting the net for a if 
modified."
As the original reporter of this bug, I feel a need to try to report it again:

1. You hit a page that has both text & graphics components. Both the text and
the graphics are updated on the http server regularly throughout the day.

2. Upon subsequent hits to the URL, the Mozilla browser only updates the text
portion of the page. The graphics portion is forever-after frozen as the
original (now cached) version which was rendered upon Mozilla first hitting the
page. Always. Forever after. Only the cached graphics are shown. Not the current
graphics. Only the cached version. Which is now hopelessly out of date. I have
absolutely _no_ idea what 

"Problem calculated the expires header do to use of unsigned math and
subtracting a big number from a small one. Verified that we are hitting the net
for a if modified."

has to do with this bug report.

--Doug
thanks Robert, I am re-opening this.

David, can you take another look at this.  The problem reported is easily seen 
using the URL http://ichart.yahoo.com/b?s=^ixic  It appears this image is only 
updating from the cache.   I checked this on todays Linux commercial build - id: 
2000050208 

changing the test url from http://finance.yahoo.com/q?s=^IXIC&d=1d  to 
http://ichart.yahoo.com/b?s=^ixic
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
It might be worth mentioning that a URL which illustrates this problem 
(http://ichart.yahoo.com/b?s=^ixic) only does so during the hours of 9:30am -
2:30pm Eastern time, since the data presented is the running NASDAQ index. Were
a Mozilla programmer to view the site outside of those hours, the graph and the
textual representations of the data would always be in sync.

--Doug
yes, I found that out last night :-)
unsigned math primer.
The expires test was along the lines of
	2000  > (1997-200 )
is always true for signed math ( 2000 > -3) and false for unsigned ( 2000 is not 
less than 2^32 - 3). I'll look at it some more some day.
Img lib cache problem. ImageURLImpl::GetExpires returnx 0x7FFFFFF always. I 
couldn't find the spot where we use the expires value but this is why even after 
doing the if-modified request the image doesn't get update. Reassign to imagelib
Assignee: davidm → pnunn
Status: REOPENED → NEW
Component: Networking: Cache → ImageLib
QA Contact: tever → elig
Status: NEW → ASSIGNED
*** Bug 35163 has been marked as a duplicate of this bug. ***
look at bug 35163, which is has more info on the problem. Stealing the summary
from that bug, as it reflects the problem correctly.  This is a image cacheing
problem, seen on win32 as well, marking OS all. Not sure about the m16 target.
OS: Linux → All
Summary: Graphics do not update when url is reloaded → Image cache not refreshed on reload
also try:
http://jazz/users/pnunn/publish/cur_time.html for simple clock.

[nsbeta2+]
Whiteboard: 1d → [nsbeta2+] 1d
Target Milestone: M16 → M17
It looks to me like images are not inheriting any
reload info from the document at all.
For all images, the reload policy is set up IMG_NTWK_SERVER by
default in line 840, mozilla/gfx/src/nsImageNetContextAsync.cpp.

http://lxr.mozilla.org/seamonkey/source/gfx/src/nsImageNetContextAsync.cpp#834

Where should I get the reload info for top level, or document reload policy??
-P
davidm:
reassigning to you to get on your radar.
Any words of wisdom before friday?
-P
Assignee: pnunn → davidm
Status: ASSIGNED → NEW
Isn't that what the aLoadContext is for. That gives you a nsILoadGroup which I 
would guess would have the various cache flags set. CCing Rick since he knows 
more about them.
Hmmm... it sounds like the caching policy is not being set on the LoadGroup when 
the document URI is loaded...

If the caching policy is set, then it should be inherited, by each one of the 
channels that is added to the group.
I'm guessing that nobody is working this one: the bug still exists...

--Doug
*** Bug 41923 has been marked as a duplicate of this bug. ***
->Pam?  Not sure if you or someone else should get this. 
Assignee: davidm → pnunn
yep. I can take the bug.
I've talked to Neeti (who is now
taking over necko cache bugs).
The reload policy (or attrib) isn't
being passed through to the imglib.

There is a default value being set 
where new network contexts for images are
created in nsImageNetContextAsync.cpp.
We need a real value here.

-P
Status: NEW → ASSIGNED
An improvement in the most recent build (id 2000061320). If you start mozilla
and view the offending URL, the image is refreshed from the old cached version.
However, subsequent reloads do not refresh the image, nor does revisiting the
url. 

--Doug
Interesting. I haven't changed a thing relating
to img cache.
-P
You're right: interesting. The behavior sho' is different today. Previously,
stopping Mozilla and then restarting did not cause the cache image to be
refreshed from the URL. Somebody changed something...

--Doug
yep. I found out later ruslan made some netwerk changes that
could have affected this. I guess that counts as 'forces beyond
our control'. ;-)
-p
this is a problem with page counters, too. Once you go to a page with a counter
it has the same number of visitors every time you go to.
*** Bug 43035 has been marked as a duplicate of this bug. ***
*** Bug 43109 has been marked as a duplicate of this bug. ***
Here's a page with 24 hour updates.

http://www.aceprogrammer.com/GaugePageCDEC.shtml

On this page, the images are not updated... ever (even after restarting Moz).
You have to shut down Moz, clear your cache manually and restart.  The "Clear
disk cache" and "Clear memory cache" on the Edit preferences dialog don't seem
to work.
After reading the descriptions here and checking for commonalities, it appears
that the images that are not reloading, probably don't actually exist on the
server.  They are generated on demand, using a CGI that takes the specified
input, retrieves the current data and then generates an image based on the
retrieved data.  Could this be part of the problem?
A step backwards with today's build (and maybe even previous ones): 2000062120.
The graphics no longer update, unless the cache is completely cleared.

--Doug
Nick:

Thanks for sending a good demo page. The problem with your page is
a little different than the specific bug in this report.

Since the html document that lists the various graphic elements 
doesn't change, the page will never get an update unless you add
a pragma/no-cache meta tag to the html document's header.
Like:

<header>
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv"refresh" content="10">
</header>

These lines specify the page will be updated from the server
every 10 seconds.

Your page should also update when you press a shift-reload,
which issues a request to get the data again directly from
the web server. Pressing a reload button only specifies 
getting the page from the server if the top document, ie the 
html page, has been modified or marked as modified by the
web server.
----------
That said, I am working on a bug where the network load info
is not being passed properly to images and applied to their
reloading.  

roberts:
Thanks for the info, but I haven't check in any changes for 
this bug in the last several days. Checkins in other areas 
are obviously affecting the loading behaviour. I'll scan
the checkins for the last couple of days.

-pn
Perhaps the correct behaviour needs to be clearly stated.

In Nav4.x, the first time the page is encountered, the images are loaded from 
the server.  The next time the images are loaded are 1. Nav is restarted. 2. The 
shift-reload button is used if you haven't left the page. 3. The reload button 
is used (with or without shift) if you come back to the page.  I can accept this 
as the correct behaviour.  If we're not in synch on this definition, can you let 
me know where I can find the document describing the correct behaviour?

In Moz, the images are only loaded the first time the page is encountered.  
Using the shift-reload button has no effect.  Restarting Moz has no effect.  
Using the clear cache buttons on the preferences dialog has no effect.  The 
images persist.  The only way to get the images to reload is to manually go 
clear out the cache directory.  This behaviour has existed for quite some time, 
so I wouldn't spend a great deal of time searching the check-ins.

Thanks,

Nick
removing myself from cc: 
I'm with you until #3.

If you move off of the page, and then back and hit the
reload button, you will still be getting what is in the
cache .....depending on the other server related parameters, like
expires settings.

Note that I'm saying this is what SHOULD happen and is not yet, because
the network info on the data stream is not passed to the image handling
code as it should be. I'm working on getting the load attribute passed
from netlib to imglib.

-pn
Re: #3.  I guess it would be ok to have to hold the shift key down there as 
well.  What I was describing was the behaviour of Nav4.5.  If there's a good 
reason to implement a different behaviour, that's fine.  I just want it to be a 
concious decision.
Are my eyes playing tricks on me, or are the images now being reloaded as of
last night's 6/27 build (where did the build id go, BTW)?

--Doug
I'm still seeing the problem with 2000062720, win32.
still seeing 2000062808 win32. btw, the build id is now in the title of the browser.
Seeing the problem again on Linux with recent daily builds, including
2000070920. (Only the cached image displays, not the current one).

--Doug
Bug still exists in build 2000071020. After reading the previous I would also 
like to point out, that this error even happens, if all caching is turned off 
(Enable disk cache: OFF, Enable memory cache: OFF, Disk Cache size: 0, Memory 
cache size: 0)
There is no need to add a comment to bugs unless the behavior has
changed in some way, or new info is known about the bug. Just adding
that the bug still exists bloats the bug report and makes it less useful
to people trying to fix the bug.
thnx,
p
A careful re-reading of the previous three comments should reveal that new
information was being presented. The first indicated that the bug was back,
after having been fixed for a few daily builds.

The second presented new information about how the bug is evidenced.

So what are you complaining about?

--Doug
Notes to self:
see info in bugs#44469 and #42130. 

Changes in local tree fix reload problem within an html
page with pragma-nocache or other refresh settings....but
break view-images. The failure shows up in nsAsyncStreamListener.cpp,
line 393 in nsOnDataAvailableEvent::HandleEvent(). GetStatus on 
the channel gives a closed status.
-p
There are several pieces to this puzzle:
 - Make sure netlib load attributes are correct.
    (e.g. pragma no-cache translates to netlib attribute FORCE_RELOAD).
 - pass info from netlib load attribute to image net context.
 - test netlib cache 'freshness'.

I can make sure the netlib load attribute is passed to the imgnet context...
but I'll need help from Neeti on callable test for netlib cache freshness.
or all I can do is ALWAYS get data from necko unless we are specifically
told to get the data from the img cache. (as in the case of printing and
perhaps, view-source.)
-p

Removing that 1d which never happened (we never got *that* 1d) :)
ETA updated. Pam has a partial fix and needs a review but being safe we set it
to 7/20 as an ETA. 
Whiteboard: [nsbeta2+] 1d → [nsbeta2+] ETA 7/20
I have a fix that works on wintel & probably works on mac and linux.
Neeti gave me a code review on the wintel changes. Once the changes
test out on linux & mac, I check it in.
-P
Checked in a fix for the reload bug.
(This fix also handles view-img's correctly.)
-p
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
I'll give you a Linux platform QA report in the morning after the market opens.
;-}.

--Doug
Try this:
http://www.exploratorium.edu/cgi-bin/Count.cgi?display=clock

its a clock that changes every minute.
Putting it in an html page is a good separate check.

And, roberts, make sure that market is going UP tomorrow, ok?
thankyouandgoodnight.
-p
Your wish is my command: Dow +141, Naz +121.

Oh, and the Linux Tiger Team gives the fix a big thumbs up.

Tnx,

--Doug
Verifying that pnunn's checkin from last night fixed it. Good work!
Status: RESOLVED → VERIFIED
Thanks for the update.  There still seems to be a problem (although it's 
probably more of a performance issue).  At least on this page:
http://www.aceprogrammer.com/GaugePageCDEC.shtm
the images are reloading... every time the page is displayed.
The behaviour of other browsers does not reload the images if the page is 
encounterred as a result of using the back/forward buttons.
Again, thanks for the update.  It's much more useful to have the images loading 
all the time than to not have them reload at all :-)
thanks for the info, Nick.
I'll check it out and find out whazzup with the page.
Chances are its a different bug with a similar MO.
If so, I open a new bug on it.
-p
*applause*
"It's working, it's working". [A.S., PM]
I'm getting a 404 on that page 
(http://www.aceprogrammer.com/GaugePageCDEC.shtm).
If you have any more info, open a new bug on it and
assign it to me.
thanks,
p
Sorry, it was a typo.  There should have been an "l" on the end of the url.
http://www.aceprogrammer.com/GaugePageCDEC.shtml
I've opened up new bug 45999 so this one can stay resolved.
pnunn - is it my eyes only or do images get reloaded all the time, no matter what?
I just tried to discribe all the different scenerios with reloading of
images. Images should not be reloaded all the time, only when the top
document is marked as being modified or expired by netlib. 

If you describe to me what you are seeing and give me a test URL,
I'll dig into it.
-P
You're welcome to use
http://www.aceprogrammer.com/GaugePageCDEC.shtml
  These images are generated by a server dynamically.
or 
http://www.aceprogrammer.com/Pillsbury.shtml
  These images are static, and stored on the same server as the page.

They all seem to be loading on each display of the page.

It looks like the images are reloading on every display of the page.
mozilla.org, the top header image is reloaded each time from the server when I
surf around it. Looks like there is not image cache at all...
Big step backwards here. As of today's build, 2000072920, images no longer
reload.

--Doug
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Keywords: nsbeta3
Target Milestone: M17 → M18
I am going to put this on [nsbeta2-], suggest work for nsbeta3.  Seems like a 
performance issue.

Images off the test page: 
http://www.mozilla.org/quality/browser/front-end/testcases/imaging/index.html
load fine on todays July 28 commercial builds.
2000-07-31-05-M17/ Win32
2000-07-31-04-M17 Linux
elig will check Mac too.

Are you seeing his on mozilla builds?  Also, pages with lots of images like
http://www.aceprogrammer.com/GaugePageCDEC.shtml
does indeed take some time.  But I see all images on reload after some time.
Whiteboard: [nsbeta2+] ETA 7/20 → [nsbeta2-] ETA 7/20
It looks like the changes to the necko cache that went in friday,
broke this again. I'm looking into what went wrong.
-p
Sorry, but I can't find anything covering this bug in the above mentioned test
cases http://www.mozilla.org/quality/browser/front-end/testcases/imaging/index.html

Wouldn't it be a good idea to add something like
http://www.aceprogrammer.com/GaugePageCDEC.shtml to the test page?
Neeti is checking in a change to the necko cache which affects (and most
likely fixes) the most recent occurance of this bug's symptoms.
The fixes will be checked in under bug#40449.
Depends on: 40449
Putting on [nsbeta2+] radar.  pnunn, please checkin fix after testing today!
Whiteboard: [nsbeta2-] ETA 7/20 → [nsbeta2+] ETA 8/01
Jan,
You misunderstand. I don't have changes to check in.
Neeti's changes for bug#40449 will fix this. She checked them in today
in branch and trunk.

I will repull and retest before closing.
-P
I updated my necko directory and am still having a problem reloading
one of my test pages.
If I reload a dynamic clock on the page by itself, making the image
the top document, it updates properly. I get the correct load attribute
from necko (x00000402, FORCE_VALIDATION). When I view my test page that
has a pragma-nocach, refresh 1 minute  in the meta tags, I don't get
a necko load attribute of FORCE_VALIDATION. I get a LOAD_NORMAL which 
means that I should use whats in the image cache if it exists.

In short, I can't close this yet.
Possibly the problem is now dependent on a pragma-nocache bug, since
the reload works if the image is the top document.

-P
Moving to ETA 8/02.  Go pnunn! Go neeti! ;-)
Whiteboard: [nsbeta2+] ETA 8/01 → [nsbeta2+] ETA 8/02
This was fixed by the changes checked in for 40449 on the branch.

The trunk has some other extra checkin that breaks the page pragma-nocache
load.

So we can close this for nsbeta2+, and open a new one for nsbeta3 (trunk).

whew.
-p
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
    Can anybody please tell me the number of that new bug so I can track it, too?
(Or just add me to the Cc list). I tried several different queries, but I couldn't
find it. Thanks.
bug for nsbeta3 = #47493.

st.n@gmx.net:
  your name has been added to the cc: list of #47493.
-p
As of today's build, 2000080605, the bug seem to be fixed again.

Thanks,

--Doug
Verified on Windows, Mac and Linux using builds 2000081105-m18, 2000081404-m18,
2000080910-m18
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.