Image cache not refreshed on reload

VERIFIED FIXED in M18

Status

()

Core
ImageLib
P3
major
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: roberts, Assigned: pnunn)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

19 years ago
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

Comment 1

19 years ago
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.
(Reporter)

Comment 2

19 years ago
This is still ocurring on build id 2000030709 -- Doug (roberts@tsasa.lanl.gov)
(Reporter)

Comment 3

19 years ago
Problem still exists with build id 2000031517. Has this one been deferred til
after beta?

--Doug

Comment 4

19 years ago
*** Bug 32268 has been marked as a duplicate of this bug. ***

Comment 5

19 years ago
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
(Reporter)

Comment 6

19 years ago
Shouldn't this bug status be changed from "UNCONFIRMED"? The bug is still in
build 032018.

--Doug

Comment 7

19 years ago
COnfirming to help put it on appropriate RADARs
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 8

19 years ago
This must be stealth bug (invisible to RADARs).

--Doug

Comment 9

19 years ago
->davidm
Assignee: gagan → davidm

Updated

19 years ago
Component: Networking → Networking: Cache
Keywords: beta2

Comment 10

19 years ago

*** This bug has been marked as a duplicate of 21137 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 11

19 years ago
verified dupe
Status: RESOLVED → VERIFIED
(Reporter)

Comment 12

19 years ago
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 → ---

Updated

19 years ago
Target Milestone: --- → M16

Updated

19 years ago
Whiteboard: 1d
(Reporter)

Comment 13

19 years ago
This bug is still in M15.

--Doug

Updated

19 years ago
Keywords: nsbeta2

Comment 14

19 years ago
*** Bug 26207 has been marked as a duplicate of this bug. ***

Comment 15

19 years ago
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
Last Resolved: 19 years ago19 years ago
Keywords: beta2
Resolution: --- → FIXED

Comment 16

19 years ago
verified on Linux 2000042709
Status: RESOLVED → VERIFIED
(Reporter)

Comment 17

19 years ago
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."
(Reporter)

Comment 18

19 years ago
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

Comment 19

19 years ago
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 → ---
(Reporter)

Comment 20

19 years ago
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

Comment 21

19 years ago
yes, I found that out last night :-)

Comment 22

19 years ago
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.

Comment 23

19 years ago
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
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 24

18 years ago
*** 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
(Assignee)

Comment 26

18 years ago
also try:
http://jazz/users/pnunn/publish/cur_time.html for simple clock.

Comment 27

18 years ago
[nsbeta2+]
Whiteboard: 1d → [nsbeta2+] 1d
(Assignee)

Comment 28

18 years ago
http://ichart.yahoo.com/b?s=aol
(Assignee)

Updated

18 years ago
Target Milestone: M16 → M17
(Assignee)

Comment 29

18 years ago
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
(Assignee)

Comment 30

18 years ago
davidm:
reassigning to you to get on your radar.
Any words of wisdom before friday?
-P
Assignee: pnunn → davidm
Status: ASSIGNED → NEW

Comment 31

18 years ago
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.

Comment 32

18 years ago
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.
(Reporter)

Comment 33

18 years ago
I'm guessing that nobody is working this one: the bug still exists...

--Doug

Comment 34

18 years ago
*** Bug 41923 has been marked as a duplicate of this bug. ***

Comment 35

18 years ago
->Pam?  Not sure if you or someone else should get this. 
Assignee: davidm → pnunn
(Assignee)

Comment 36

18 years ago
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
(Reporter)

Comment 37

18 years ago
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
(Assignee)

Comment 38

18 years ago
Interesting. I haven't changed a thing relating
to img cache.
-P
(Reporter)

Comment 39

18 years ago
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
(Assignee)

Comment 40

18 years ago
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

Comment 41

18 years ago
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.

Comment 42

18 years ago
*** Bug 43035 has been marked as a duplicate of this bug. ***

Comment 43

18 years ago
*** Bug 43109 has been marked as a duplicate of this bug. ***

Comment 44

18 years ago
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?
(Reporter)

Comment 45

18 years ago
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
(Assignee)

Comment 46

18 years ago
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

Comment 47

18 years ago
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

Comment 48

18 years ago
removing myself from cc: 
(Assignee)

Comment 49

18 years ago
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

Comment 50

18 years ago
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.
(Reporter)

Comment 51

18 years ago
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

Comment 52

18 years ago
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.
(Reporter)

Comment 54

18 years ago
Seeing the problem again on Linux with recent daily builds, including
2000070920. (Only the cached image displays, not the current one).

--Doug

Comment 55

18 years ago
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)
(Assignee)

Comment 56

18 years ago
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
(Reporter)

Comment 57

18 years ago
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
(Assignee)

Comment 58

18 years ago
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
(Assignee)

Comment 59

18 years ago
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

Comment 60

18 years ago
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
(Assignee)

Comment 61

18 years ago
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
(Assignee)

Comment 62

18 years ago
Checked in a fix for the reload bug.
(This fix also handles view-img's correctly.)
-p
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 63

18 years ago
I'll give you a Linux platform QA report in the morning after the market opens.
;-}.

--Doug
(Assignee)

Comment 64

18 years ago
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
(Reporter)

Comment 65

18 years ago
Your wish is my command: Dow +141, Naz +121.

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

Tnx,

--Doug

Comment 66

18 years ago
Verifying that pnunn's checkin from last night fixed it. Good work!
Status: RESOLVED → VERIFIED

Comment 67

18 years ago
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 :-)
(Assignee)

Comment 68

18 years ago
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

Comment 69

18 years ago
*applause*
"It's working, it's working". [A.S., PM]
(Assignee)

Comment 70

18 years ago
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

Comment 71

18 years ago
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?
(Assignee)

Comment 73

18 years ago
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

Comment 74

18 years ago
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...
(Reporter)

Comment 76

18 years ago
Big step backwards here. As of today's build, 2000072920, images no longer
reload.

--Doug
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

18 years ago
Keywords: nsbeta3
Target Milestone: M17 → M18

Comment 77

18 years ago
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
(Assignee)

Comment 78

18 years ago
It looks like the changes to the necko cache that went in friday,
broke this again. I'm looking into what went wrong.
-p

Comment 79

18 years ago
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?
(Assignee)

Comment 80

18 years ago
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

Comment 81

18 years ago
Putting on [nsbeta2+] radar.  pnunn, please checkin fix after testing today!
Whiteboard: [nsbeta2-] ETA 7/20 → [nsbeta2+] ETA 8/01
(Assignee)

Comment 82

18 years ago
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
(Assignee)

Comment 83

18 years ago
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

Comment 84

18 years ago
Moving to ETA 8/02.  Go pnunn! Go neeti! ;-)
Whiteboard: [nsbeta2+] ETA 8/01 → [nsbeta2+] ETA 8/02
(Assignee)

Comment 85

18 years ago
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
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 86

18 years ago
    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.
(Assignee)

Comment 87

18 years ago
bug for nsbeta3 = #47493.

st.n@gmx.net:
  your name has been added to the cc: list of #47493.
-p
(Reporter)

Comment 88

18 years ago
As of today's build, 2000080605, the bug seem to be fixed again.

Thanks,

--Doug

Comment 89

18 years ago
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.