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. firstname.lastname@example.org, 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 (email@example.com)
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
Assignee: gagan → davidm
*** This bug has been marked as a duplicate of 21137 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
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 → ---
This bug is still in M15. --Doug
*** 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
Last Resolved: 19 years ago → 19 years ago
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
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
*** 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.
Whiteboard: 1d → [nsbeta2+] 1d
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
Last Resolved: 19 years ago → 18 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 → ---
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
Last Resolved: 18 years ago → 18 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. firstname.lastname@example.org: 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.