Closed Bug 327438 Opened 19 years ago Closed 19 years ago

When a cached image changes on a server Firefox does not detect it

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: cv2pf6ip50, Unassigned)

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 When Firefox has a image from a visited site stored in its disk cache and this image is updated on the server, Firefox does not detect it (I've been waiting for several weeks). Internet Explorer 6 dected it immediately. Opera has no problems either. In Firefox, I've been waiting for weeks for the image to change. In vain. The change is still undetected. The only way to work around that in FF is to hit F5. Firefox should check the timestamp of a cached image at least once per session. Reproducible: Always Actual Results: Updated image is not detected (the cached version was used instead).
Which site, which image?
(In reply to comment #1) > Which site, which image? It does not matter. The server in question sends correct file timestamps. Again, IE6 detected the change immediately, while in Firefox it goes undetected for weeks. There's obviously a problem.
What is the value of the pref setting browser.cache.check_doc_frequency? (you can see this in about:config) Please list at least one image URL to test this, even if you think that the server is not at fault here.
(In reply to comment #3) > What is the value of the pref setting browser.cache.check_doc_frequency? All settings are at default. I've never changed settings in about:config and AFAIK, Firefox does not have this option configurable in the GUI. Anyway, I checked it now and found the following: browser.cache.check_doc_frequency = 3 (status = default). > Please list at least one image URL to test this I'm not going to give you any URL to test that. Just test it against any Apache 1.3.x server where you are allowed to update images.
(In reply to comment #4) > > Please list at least one image URL to test this > > I'm not going to give you any URL to test that. Just test it against any Apache > 1.3.x server where you are allowed to update images. > It *does* matter. There could be something wrong with the setting of this particular server or its headers. Are you using a proxy-server by any chance (if you're using an ISP, it might even be an invisble one) ? Check here : http://gemal.dk/browserspy/proxy.php .
(In reply to comment #5) > There could be something wrong with the setting of this particular server Well, if there was something wrong with the server, then IE6 and Opera would have problems too. > Are you using a proxy-server by any chance Again, this argument is invalid, because IE6 and Opera have no problems.
What is also relevant here is that changes in HTML on the server in question are detected correctly by Firefox. Only images get different treatment. Probably yet another inconsistency/flaw introduced in the name of "Fast Browsing(R)".
Reporter, whether cached data is used or not depends on your cache related option settings of your browser and server's header responses relate to caching. See http://livehttpheaders.mozdev.org/index.html and install extention of LiveHTTPHeaders, and get HTTP header log of both "Shift+Reload"(no cache is used) and "Reload"(usually cache is used, but depends on your client settings and server settings), then compare flow(HTTP headrs sent and received). Please note that no timestamp check is done if cache is still alive by "max-age" sent by server, even if content at server is already updated. This is rule defined by HTTP protocol, and this depends on, as I said first, your cache related option settings of your browser and server's cache related settings. See HTTP 1.1 protocol for detail. - http://www.w3.org/Protocols/ - http://www.w3.org/Protocols/rfc2616/rfc2616.txt (at least chapter "13 Caching in HTTP") In many cases, "already updated at server but not updated by Firefox" is due to lack of "Shift+Reload" use even though it is required, Is "Shift+Reload" a solution? Another possibility. Mozilla family has a bug on <img> when reload if <img src> URI is redirected randomly. See Bug 281486 for the issue. Is this your case? >Probably yet another inconsistency/flaw introduced in the name of "Fast Browsing(R)". Do you mean that problem didn't occur if browser.sessionhistory.max_total_viewers and browser.sessionhistory.max_viewers are set to zero, but problem occurs always if they are reset to default? Anyway, bugzilla.mozilla.org is not cutomer suport center nor help center. Please explain not only your experiencing problem but also what/which/where is Firefox's "bug" do you believe(or is convinced or prejudice) clearly with evidence. In this bug's case, at leaset HTTP header log and your cache related option settings of Firefox, prefs.js entries, are to be presented as evidence of Firefox's fault.
(In reply to comment #8) > See http://livehttpheaders.mozdev.org/index.html and install extention of > LiveHTTPHeaders LiveHTTPHeaders shows that the images are not requested from the server at all. > and get HTTP header log of both "Shift+Reload"(no cache is > used) and "Reload" You missed the point. I want Firefox to detect the change _without_ using Shift+Reload or Reload. > Please note that no timestamp check is done if cache is still alive by > "max-age" sent by server, even if content at server is already updated. Then this is the flaw. Max-age does _not_ mean that you are not supposed to check the timestamp. Max-age just determines for how long time you can keep the cached document in the cache. But decent browsers (IE6, Opera) check timestamps once per session (if configured to do so automatically) to see if the image changed. > server's cache related settings. The server uses default settings of Apache 1.3.x that came with Debian. > In many cases, "already updated at server but not updated by Firefox" is due > to lack of "Shift+Reload" use even though it is required, I suggest you re-read my report. I explicitly say that "The only way to work around that in FF is to hit F5." > Is "Shift+Reload" a solution? No, see above. > Mozilla family has a bug on <img> when reload if <img src> URI is redirected > randomly. No, there are no random redirections. > Do you mean that problem didn't occur if > browser.sessionhistory.max_total_viewers and browser.sessionhistory.max_viewers > are set to zero, but problem occurs always if they are reset to default? Ok, I'll say it again, I've never changed _any_ settings in Firefox. > Anyway, bugzilla.mozilla.org is not cutomer suport center nor help center. I'm not your customer. I don't use Firefox. I'm just a webmaster annoyed by your browser. I use it only occassionally when I update my site to check that it is rendered correctly (therefore I leave all Firefox settings at default). > Please explain not only your experiencing problem but also what/which/where is > Firefox's "bug" do you believe(or is convinced or prejudice) clearly with > evidence. I'm not a Firefox tester, nor a developer. It is _your_ task (or testers') to test Firefox with Apache 1.3.x server with its default settings and Firefox with its default settings. Our server is not your test server. However, I already identified the flaw (see above).
I did a Shift+Reload and checked the output of LiveHTTPHeaders. Just as I expected there was no "Max-age" field, nor any "Expires-after" headers sent from the server in question.
(In reply to comment #9) You said in comment #0 : > Firefox should check the timestamp of a cached image at least once per session. What do you mean by "session"? Do you mean you started Firefox from shortcut to open new session? If yes, please note followings. IE always starts new session(new process) when started from shortcut, but Firefox opens new window. This is one of differences of design between IE and Firefox. To start new session, next procedure is required. SET MOZ_NO_REMOTE=1, then start Firefox with this environment variable. (This became true by Fx 1.5 even when Linux. See Bug 280725 and 289383. See also bug 325509 for -no-remote switch of future release.) So if session cookie has relation to problem, or if cache option of "Once per session" is involved, please be carefull when try to understand what is happning. > I suggest you re-read my report. I explicitly say that "The only way to work > around that in FF is to hit F5." Oh, sorry. I missed it. You say in comment #0 : > Internet Explorer 6 dected it immediately. Opera has no problems either. > In Firefox, I've been waiting for weeks for the image to change. > In vain. The change is still undetected. > this image is updated on the server, Firefox does not detect it > (I've been waiting for several weeks). What do you mean by "detect"? Since <img> is updated when F5(Reload, not super-Reload) as you said, Firefox asks timestamp to server correctly(If-Modified-Since:) when server access is invoked, according to browser.cache.check_doc_frequency=3 (default, "When the page is out of date"). See HTTP header log. What do you mean by "I've been waiting for weeks for the image to change". Opened a page in a tab, then no action on the page? (action which invokes server access for the page content.) If yes, it seems that "automatic/periodical reload/update" is effective or not. As far as I remeber, IE(Opera too) has periodical reload option. Do you know such feature of pure Firefox? > > and get HTTP header log of both "Shift+Reload"(no cache is > > used) and "Reload" > > You missed the point. I want Firefox to detect the change _without_ using > Shift+Reload or Reload. This is simply suggestion to you - see HTTP log first in order to know real flow. > > Please note that no timestamp check is done if cache is still alive by > > "max-age" sent by server, even if content at server is already updated. > > Then this is the flaw. Max-age does _not_ mean that you are not supposed to > check the timestamp. As I said twice, behaviour depends on cache related option settings. Because I've found that your cache setting was "When the page is out of date", I think now you can see If-Modified-Since: header, if(and only if) HTTP flow is invoked for the page. See real HTTP log in your environment first. > No, there are no random redirections. I see. You are lucky. > I'm not a Firefox tester, nor a developer. It is _your_ task (or testers') to > test Firefox with Apache 1.3.x server with its default settings and Firefox > with its default settings. Again, here is bugzilla, not customer support center nor help center.
(In reply to comment #11) > (In reply to comment #9) > What do you mean by "session"? By "session" I meant the period between browser launch and browser exit. This is what session generally means. I did _not_ mean any specialized term such as php session (based on cookie) or anything like that. > So if session cookie has relation to problem No, no cookies nor php sessions are involved. > What do you mean by "detect"? By "detect" I mean to detect that the cached image was updated on the server. According to timestamp or file size. > What do you mean by "I've been waiting for weeks for the image to change". I boot Windows, I launch Firefox, I click the bookmark of the site. I browse to the page with images (eg. images.html). Firefox correctly detected that the text on the page images.html changed WITHOUT RELOAD. BUT, it did NOT detect that the image linked from images.html changed too. I've checked that the stock Apache server sends CORRECT time stamps and does not send any Max-age nor any Expires-after fields. > This is simply suggestion to you - see HTTP log first in order to know real > flow. I've checked the raw access Apache log. The only item that Firefox requests is the page images.html, but it does not check whether the images linked from images.html changed. > if(and only if) HTTP flow is invoked for the page. What's this supposed to mean? > > No, there are no random redirections. > I see. You are lucky. Huh? > Again, here is bugzilla, not customer support center nor help center. In case you haven't noticed -- I am reporting a bug here.
(In reply to comment #12) > > What do you mean by "I've been waiting for weeks for the image to change". > I boot Windows, I launch Firefox, I click the bookmark of the site. I browse to > the page with images (eg. images.html). Firefox correctly detected that the > text on the page images.html changed WITHOUT RELOAD. BUT, it did NOT detect > that the image linked from images.html changed too. Attach HTTP header log when "Shift+Reload" and "Reload". Attach HTTP header log when first access to server by click of the bookmark after restart of Firefox. And, if possible, let us know URI where problem occured or occurs, or attach the HTML on which problem occured, or attach simple/minimized test case. > I've checked the raw access Apache log. The only item that Firefox requests is > the page images.html, but it does not check whether the images linked from > images.html changed. Firefox sends HTTP GET with no-cache when initial access (same as Shift+Reload), and usually sends HTTP GET with If-Modified-Since: when next normal Load (same as Reload). Since no Apach log for image file, problem looks for me : HTTP GET with If-Modified-Since is not sent correctly for image when normal Road, and this occurs only when bfcache is enabled. (Not problem of "failed to detect". Problem of "never try to detect") Questions to clarify. - image file of same site as HTML? Or image file of different site? - script generated <img>? - src attribute's value is changed by script? - <img> is placed in <iframe>? - "image is updated" means image file is replaced by new one"? Or redirected URI is changed? > > if(and only if) HTTP flow is invoked for the page. > What's this supposed to mean? It meant; If your case is problem of "no automatic update feature in FF", HTTP access to server will never be invoked, then no HTTP flow will be seen. > > > No, there are no random redirections. > > I see. You are lucky. > Huh? Oh, sorry unclear words. You are lucky because you won't experience Bug 89419 and/or Bug 279048, then you needn't care on them.
When attach log file thru link of "Create a New Attachment", please specify "text/plain", for ease of viewing by browser. By the way... > > Again, here is bugzilla, not customer support center nor help center. > In case you haven't noticed -- I am reporting a bug here. If so, why HTTP header log data is not presented to us yet? You only say 'LiveHTTPheadrs log shows...' or 'There is no "Max-Age"...'. Do I have to ask you question of "Does xxxx header exist?" or "What data is specified as yyyy parameter" for each related/suspectable HTTP headers? :-) (Because I didn't say "attach log" until comment #13?)
(In reply to comment #13) > Attach HTTP header log when "Shift+Reload" and "Reload". Irrelevant. Reload and Shift+Reload works normally. > Questions to clarify. > - image file of same site as HTML? Or image file of different site? The same site exactly, but in the folder /images/ > - script generated <img>? No. It's a php page though. > - src attribute's value is changed by script? No. > - <img> is placed in <iframe>? No. > - "image is updated" means image file is replaced by new one"? Yes. Same file name, different content (maybe the same size -- don't know). Different timestamp. > Or redirected URI is changed? No.
(In reply to comment #15) > > Attach HTTP header log when "Shift+Reload" and "Reload". > Irrelevant. Reload and Shift+Reload works normally. Since your case looks that no HTTP GET is issued for image file(you said so), no cache related data for the image file is involved in HTTP flow when problem occurs. How can we know or guess about cahce status of the image file in FF? How can we check about:cache display for the image file is correct or not without normal HTTP flow for the image file? Nomal HTTP flow data for the image file is REQUIRED.
Can you recreate your problem by next very simple case? (0) HTML file <html><head></head><body><img src="image/xxx.jpg"></body></html> (1) Load the HTML thru bookmark (2) Shift+Reload (Force access with no-cache, emulate initial access) (3) Reload (emulate last normal access) (4) Update image file at server (timestamp only change is better for test, I think) (5) Restart Firefox, and load thru bookmark
> (timestamp only change is better for test, I think) Ignore above, please. Sorry for spam.
(In reply to comment #17) > Can you recreate your problem by next very simple case? > (0) HTML file > <html><head></head><body><img src="image/xxx.jpg"></body></html> > (1) Load the HTML thru bookmark > (2) Shift+Reload (Force access with no-cache, emulate initial access) > (3) Reload (emulate last normal access) > (4) Update image file at server > (timestamp only change is better for test, I think) > (5) Restart Firefox, and load thru bookmark Well, that's definitely how the problem can be reproduced, yes. I did a reload of the page on 2006-02-20. Now I used about:cache?device=disk and FF shows the following info for the image: Data size: 16050 bytes Fetch count: 10 Last modified: 2006-02-20 22:59:26 Expires: 2006-02-21 14:05:54
(In reply to comment #19) HTTP Header data nor URI/HTML/Test case is not presented to us yet, even though I said "At least HTTP Header data is to be presented", "attach HTTP log" and "HTTP log is required", and other comment poster and me said "present us URI/HTML/test case"... Do you really think "I am reporting a bug here"? My last words to you in this bug : Here is bugzilla, not customer support center nor help center.
(In reply to comment #20) > (In reply to comment #19) > HTTP Header data nor URI/HTML/Test case is not presented to us yet, even though > I said "At least HTTP Header data is to be presented", "attach HTTP log" and > "HTTP log is required", and other comment poster and me said "present us > URI/HTML/test case"... > Do you really think "I am reporting a bug here"? > My last words to you in this bug : > Here is bugzilla, not customer support center nor help center. I am not your tester. Our server is not your test server. I reported a bug and supplied all information that has been available to me. Now I know why Firefox sucks (and why I don't use it -- and I never will). The attitude towards fixing bugs here is simply staggering.
> I am not your tester. Our server is not your test server. That's correct, of course, but there is one important point to remember: Mozilla is a community project supported by volunteers. I can just as well say: "We are not your developers, you didn't pay us, and we have no obligation to do anything for you (including testing and fixing bugs)". This is what WADA was trying to tell you, I think. But that's not really the point here... When I say "community project" this means that above all _cooperation_ is necessary. You may feel that you are not part of this community, but when you expect the Mozilla developers to fix a particular problem you see, we expect some cooperation from you in return. Just coming along and saying something along the lines of "Oh, I've found a bug, but I'm not really willing to help" just won't work (this is somewhat exaggerated, of course). Note that I don't want to imply here that you are not trying to help at all, but refusing to give a simple test URL - which would be the easiest thing to do - without any reason is not cooperation in my book. And claiming that you "supplied all information that has been available to [you]" doesn't help either. In the end, the fact remains that you have not convinced any of the bug triagers (including me) that there actually is a bug involved here. There may very well be one, but unless one of us is able to reproduce what you see, there is no way to investigate this further. I certainly cannot see any unexpected behaviour on my Apache 1.3 server in this regard. Maybe you are seeing bug 221036, maybe something else. Who knows? Either you convince us that what you see is really a bug, or I'll have to close this report as WORKSFORME and you have to cope with whatever problem you see on your own. It's just that simple.
(In reply to comment #22) > We are not your developers, you didn't pay us, and we have no obligation to do > anything for you (including testing and fixing bugs) Then why are you here? What are you doing here? When did I say anyone was obliged to fix a bug in Firefox? It is solely up to you if you want Firefox to be buggy or not. It's up to you. I don't use Firefox (I'm just a random webmaster annoyed by your browser). And believe me that I never will use it, especially after I saw the laziness of the developers (laziness to look for bugs in the code without an external test URL). > When I say "community project" this means that above all _cooperation_ is > necessary. That's why I filed a bug report and answered about twenty questions specifying the bug and supplying all details available to me (except my resources). > we expect some cooperation from you in return. See above. > Just coming along and saying something > along the lines of "Oh, I've found a bug, but I'm not really willing to help" So, I did not lend you our server for testing because it's not mine server, then it means that you can't (or lazy to) fix this bug (or even start looking for it!). Another reason to stay away from Firefox and use Opera or IE6 (which more stable, much faster and not as bloated). > I'll have to close this report as WORKSFORME and you have to cope with > whatever problem you see on your own. It's just that simple. Yes, I can imagine that this is the way most bugs are "fixed" in Firefox. That's why IE and Opera have always been better.
Discussions about the merits of Browser A vs. Browser B do not belong here, so please take your rants elsewhere. Thank you. > That's why I filed a bug report and answered about twenty questions specify- > ing the bug and supplying all details available to me (except my resources). I really appreciate this (even if you don't believe it), but what would be most relevant and helpful here is an actual test case, which you still refuse to provide. > So, I did not lend you our server for testing because it's not mine server, Oh, I already imagine your server crashing under the load of one developer testing the image caching on one URL... ;-) Seriously: Even if you don't want to publish the URL here, there are other ways to send such information. Or you can find some other server on the net where you see this, which should be easy to do if it just requires an Apache 1.3.x server with default config. > then it means that you can't (or lazy to) fix this bug (or even start > looking for it!) As I said, I have tested this on my server here and I do not see any problems. And I cannot investigate a problem that I do not see (and blindly looking through the code is not the answer, as any software developer will tell you). If you cannot provide either a test case or a HTTP header log (see comment #13), there is nothing I can do for you.
(In reply to comment #22) > This is what WADA was trying to tell you, But I failed... :-) > Maybe you are seeing bug 221036 Elmar Ludwig, thanks for pointing. I think we've found what is the problem in bug 221036 by your pointing. I think we will be able to close as DUP of bug 221036 in near future, although some addtional tests may be required to know "whether image specific problem is involved or not" and "whether bfcache specific problem is involved or not". Elmar Ludwig, please don't waste your valuable time any more for this bug.
Based on my testing, the bug I reported is solely related to images. So, I don't think it's a true duplicate. However, there are certain similarities.
(In reply to comment #25) > I think we will be able to close as DUP of bug 221036 Elmar Ludwig, read above statement as follows, please. (Sorry for spam) - This bug is to be closed as INVALID, or DUP of Bug 310656 if Bug 310656 is report when browser.cache.check_doc_frequency=3.
Quoting from the other bug thread: "If no expires is specified, a date is calculated based on the last modified of the document, which I believe results in the document expiring about 1/10th of it's age into the future (so if the document was last modified 10 hours ago, Firefox would make it expire in 1 hour - Darin will correct me here)." That clearly seems to be the cause of the problem. Close this bug as duplicate. Next time, instead of asking for irrelevant stuff and resources from reporters, take some time to look in the Firefox code and learn how it works. Maybe you'll actually manage to fix some bugs.
WADA: This is not a dup of 310656. That bug requests to keep pages with very short heuristic expiration times in the cache for at least some miminum time (or to improve the current calculation to that effect), which is a different issue. I _think_ (still lacking a testcase) the problem here is that the image is not refetched because the calculated heuristic expiration time indicates that the cached image is still valid. And this is exactly what bug 221036 is about. Now, whether this is a bug or not really depends on the exact sematics of the different cache settings. According to the specification given here: http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsIRequest.idl#182 one could argue that in the case of VALIDATE_ONCE_PER_SESSION, the calculated heuristic expiration should not be honoured the first time a resource is requested in a session. But this is better discussed in that bug, not here. dtufs@yahoo.com: I'm resolving this now as a duplicate of bug 221036 (as described above). Just one final note from me: Next time, before making bold statements about how to fix bugs, learn something about software development first. *** This bug has been marked as a duplicate of 221036 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
(In reply to comment #29) Elmar: This "Bug"(report which assigned bug number by bugzilla system of bugzilla.mozilla.org) never be DUP of Bug 221036, because Bug 221036 is real bug when "Once per session"(browser.cache.check_doc_frequency=0) and "Heuristic Expiration", and problem of Bug 221036 is : If the Heuristic is used, HTTP GET with If-Modified-Since: is not requested when session is restarted(first access after restart of Firefox), even though user requests "Once per session". When "When the page is out of date"(browser.cache.check_doc_frequency=3), this report's case, expiration time should be always effective including after session restart, even if the expiration date is "Heuristic Expiration". So usually INVALID. But, I think current algorythm of FF is not so good for loose server(sends no information about expiraion) and for user who always says "It works when IE, but not when FF, then bug of FF". I think that using algorythm of "Typical heuristic written in RFC 2616" is not so clever way, and that there are some ways; - default to max-age=0 - default to max-age=several seconds/hours (pre-defined) - default to max-age=several seconds/hours (user choosable) - if "Heuristic Expiration", ignore ""When the page is out of date", and behaive as if "Once per session" is choosed by user when session start. (needless to say, Bug 221036 have to be fixed, before this chice.) Do you want to think about them in Bug 221036? Elmar, please don't increase probablity that clean Bug 221036 will be contaminated by bold statements.
Elmar: > So usually INVALID. Please read above line as; So usually INVALID, if "Heuristic Expiration" case. I feel probability of "Heuristic Expiration" is very high but still uncertain since reporter rejected to present evidence. I think "rejection of presenting evidence" can be a reason why close as INVALID.
Reopen in order to change back to UNCONFIRMED, expecting "Auto-Reply".
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(In reply to comment #30) > This "Bug"(report which assigned bug number by bugzilla system of > bugzilla.mozilla.org) never be DUP of Bug 221036, because Bug 221036 is > real bug when "Once per session"(browser.cache.check_doc_frequency=0) and > "Heuristic Expiration" To quote from bug 221036 comment #0: "When cache "once per session" or "when the page is out of date" is selected and the Web Server does not send the "Expires" header, Mozilla automatically sets an expiration date, so on the next session the page is fetched from the cache and it is not compared with the server one." So, the initial report clearly covers both cases (including the one discussed here). Now, you can argue that the second part of that report is INVALID based on Darin's comments in bug 310656, but this case is clearly covered there. > When "When the page is out of date"(browser.cache.check_doc_frequency=3), > this report's case, expiration time should be always effective including > after session restart, even if the expiration date is Heuristic Expiration. > So usually INVALID. I'm actually not quite sure about this, because the case Darin commented about is slightly different (and because caches should be conservative in general), but I tend to think so as well. Darin should to decide that. > But, I think current algorythm of FF is not so good for loose server(sends > no information about expiraion) and for user who always says "It works when > IE, but not when FF, then bug of FF". Do you want to think about them in > Bug 221036? Yes, this doesn't belong here. > Elmar, please don't increase probablity that clean Bug 221036 will be > contaminated by bold statements. Hmm, now that is a valid argument. :-) I'm not going to start a discussion here about whether this bug is a duplicate or invalid. If you think it is invalid for lack of a testcase, make it so.
> If you think it is invalid for lack of a testcase, make it so. Exactly, just close it. Why bother? Don't bother to look in the source code. Why should you waste your time? Why learn how Firefox works? Why even *start* looking for a bug? No external test URL, then I'm too lazy to do anything. Be just as lazy as you have been. Oh God. Long live the IE.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.