Closed
Bug 30852
Opened 24 years ago
Closed 24 years ago
Image cache not refreshed on reload
Categories
(Core :: Graphics: ImageLib, defect, P3)
Tracking
()
VERIFIED
FIXED
M18
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
Comment 1•24 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.
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
Comment 5•24 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
Shouldn't this bug status be changed from "UNCONFIRMED"? The bug is still in build 032018. --Doug
Comment 7•24 years ago
|
||
COnfirming to help put it on appropriate RADARs
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•24 years ago
|
||
*** This bug has been marked as a duplicate of 21137 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 12•24 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•24 years ago
|
Target Milestone: --- → M16
Updated•24 years ago
|
Whiteboard: 1d
Reporter | ||
Comment 13•24 years ago
|
||
This bug is still in M15. --Doug
Comment 14•24 years ago
|
||
*** Bug 26207 has been marked as a duplicate of this bug. ***
Comment 15•24 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
Closed: 24 years ago → 24 years ago
Keywords: beta2
Resolution: --- → FIXED
Reporter | ||
Comment 17•24 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•24 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•24 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•24 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•24 years ago
|
||
yes, I found that out last night :-)
Comment 22•24 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•24 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 | ||
Comment 24•24 years ago
|
||
*** Bug 35163 has been marked as a duplicate of this bug. ***
Comment 25•24 years ago
|
||
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•24 years ago
|
||
also try: http://jazz/users/pnunn/publish/cur_time.html for simple clock.
Assignee | ||
Comment 28•24 years ago
|
||
http://ichart.yahoo.com/b?s=aol
Assignee | ||
Comment 29•24 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•24 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•24 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•24 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•24 years ago
|
||
I'm guessing that nobody is working this one: the bug still exists... --Doug
Comment 34•24 years ago
|
||
*** Bug 41923 has been marked as a duplicate of this bug. ***
Comment 35•24 years ago
|
||
->Pam? Not sure if you or someone else should get this.
Assignee: davidm → pnunn
Assignee | ||
Comment 36•24 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•24 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•24 years ago
|
||
Interesting. I haven't changed a thing relating to img cache. -P
Reporter | ||
Comment 39•24 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•24 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•24 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•24 years ago
|
||
*** Bug 43035 has been marked as a duplicate of this bug. ***
Comment 43•24 years ago
|
||
*** Bug 43109 has been marked as a duplicate of this bug. ***
Comment 44•24 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•24 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•24 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•24 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•24 years ago
|
||
removing myself from cc:
Assignee | ||
Comment 49•24 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•24 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•24 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•24 years ago
|
||
I'm still seeing the problem with 2000062720, win32.
Comment 53•24 years ago
|
||
still seeing 2000062808 win32. btw, the build id is now in the title of the browser.
Reporter | ||
Comment 54•24 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•24 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•24 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•24 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•24 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•24 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•24 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•24 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•24 years ago
|
||
Checked in a fix for the reload bug. (This fix also handles view-img's correctly.) -p
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 63•24 years ago
|
||
I'll give you a Linux platform QA report in the morning after the market opens. ;-}. --Doug
Assignee | ||
Comment 64•24 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•24 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•24 years ago
|
||
Verifying that pnunn's checkin from last night fixed it. Good work!
Status: RESOLVED → VERIFIED
Comment 67•24 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•24 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•24 years ago
|
||
*applause* "It's working, it's working". [A.S., PM]
Assignee | ||
Comment 70•24 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•24 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.
Comment 72•24 years ago
|
||
pnunn - is it my eyes only or do images get reloaded all the time, no matter what?
Assignee | ||
Comment 73•24 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•24 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.
Comment 75•24 years ago
|
||
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•24 years ago
|
||
Big step backwards here. As of today's build, 2000072920, images no longer reload. --Doug
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 77•24 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•24 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•24 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•24 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•24 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•24 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•24 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•24 years ago
|
||
Moving to ETA 8/02. Go pnunn! Go neeti! ;-)
Whiteboard: [nsbeta2+] ETA 8/01 → [nsbeta2+] ETA 8/02
Assignee | ||
Comment 85•24 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
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 86•24 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•24 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•24 years ago
|
||
As of today's build, 2000080605, the bug seem to be fixed again. Thanks, --Doug
Comment 89•24 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.
Description
•