Closed
Bug 136958
Opened 22 years ago
Closed 22 years ago
META HTTP-EQUIV="refresh" stops working after a while
Categories
(Core :: XPCOM, defect, P1)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
People
(Reporter: ulrichsk, Assigned: dougt)
Details
Attachments
(2 files)
The refresh stops working ervery 60 minutes after the browsert was started. The following HTML-Code illustrates the problem: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > <html> <head> <title></title> <META HTTP-EQUIV="refresh" CONTENT="60; url=file:///F:/y.html"> </head> <script> var mow = new Date(); document.write('Status ('+mow.getHours()+':'+mow.getMinutes()+':'+mow.getSeconds()+'):<br>'); </script> </body> </html>
i forgot to mention, that if i have Cinema/2 (TV-Program) running, refresh doesnt work at all.
Comment 2•22 years ago
|
||
docshell handles refresh, IIRC
Assignee: Matti → adamlock
Component: Browser-General → Embedding: Docshell
QA Contact: imajes-qa → adamlock
Comment 3•22 years ago
|
||
I don't see this problem. Mine ran for 12 hours. There must be something else stopping the timers. Please check on a current build.
Version 0.9.8 and perhaps 0.9.7 had this problem on my system too. Seems that other applications affect the timer behavior (see my 2. comment regarding Cinema/2). Some idea how i can start some investigations?
For reference, the refresh mechanism in docshell is here: http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#3423 I have set my timer running and I will report the results in an hour. Note that I had to change the original HTML because it was malformed (no <BODY> tag). Also note that content="60" means 60 seconds, not 60 minutes, which means it should refresh 60 times before exhibiting the reported problem.
Marking WORKSFORME. I left the timer running 90 minutes and timers were still working correctly at the end of that time. For reference, by HTML was this (lines in JS may wrap) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > <html> <head> <title></title> <meta HTTP-EQUIV="refresh" CONTENT="60; url=file:///c:/m/test/136958.html"> <body> <script> var mow = new Date(); document.write('Status('+mow.getHours()+':'+mow.getMinutes()+':'+mow.getSeconds()+'):<br>'); </script> </head> </body> </html>
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Please note I tested on Win32. I do not have any way to test OS/2. If you believe this is a problem with timers on OS/2 then it may be best to reopen this bug, but it will be reassigned to the appropriate maintainers..
Thanks for the link and comments. It seems that this bug caused by a problem with the OS/2 timers, so the OS/2 experts should have a look at this. So i will reopen this bug. But how can i assign it to the appropriate OS/2 maintainers? You are right, the <body>--tag was missing in this html-code. Yes, 60 seconds refresh time is that what i meant. After 60 or 59 refreshs, refreshing stops. You can start it again by reloading (F5) the page.. It is important to emphasize that the refresh stops working ervery 60 minutes after the BROWSER was started, i.e. with a browser start at 8:17 the refresh will stop working at 9:17, 10:17, 11:17, ...
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reassign
Component: Embedding: Docshell → NSPR
Product: Browser → NSPR
Comment 10•22 years ago
|
||
Reassigning to NSPR. Could be a problem with timers on OS/2.
Assignee: adamlock → wtc
QA Contact: adamlock → wtc
Comment 11•22 years ago
|
||
Michael, could you take a look at this bug? Thanks.
Comment 12•22 years ago
|
||
There are no OS/2 specific timers. All the timer code is cross platform now. I tried this on my machine and was able to run for quite a while. Does anyone know if there is NSPR logging for the timers?
Comment 13•22 years ago
|
||
This should definitely be in the browser boat. I can get it to fail. when it fails, I see tons of extra timer creations in the log after the failure. This looks like an XP timer failure. I need some advice on how to try to track it down. It happens after about 20 minutes for me. 6[2d3e08]: waiting for 3599676 6[2d3e08]: waiting for 3599994 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstance({6049b261-c1e6-11d1-a827-0040959a28c9}) succeeded 0[2a4220]: $$$ processing event 0[2a4220]: $$$ done processing event 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: $$$ processing event 0[2a4220]: $$$ done processing event 0[2a4220]: nsComponentManager: CreateInstance({6049b261-c1e6-11d1-a827-0040959a28c9}) succeeded 6[2d3e08]: Timer thread woke up -6ms from when it was supposed to 6[2d3e08]: waiting for 3392821 0[2a4220]: $$$ processing event 0[2a4220]: [this=d436b0] time between PostTimerEvent() and Fire(): 0ms 0[2a4220]: [this=d436b0] expected delay time 500ms 0[2a4220]: [this=d436b0] actual delay time 494ms 0[2a4220]: [this=d436b0] (mType is 0) ------- 0[2a4220]: [this=d436b0] delta -6ms 0[2a4220]: UpdateFilter: smoothSlack = -375.3, filterLength = 20 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 0[2a4220]: [this=d436b0] Took 5ms to fire timer callback 0[2a4220]: $$$ done processing event 6[2d3e08]: waiting for 4992 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 6[2d3e08]: waiting for 492 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 0[2a4220]: nsComponentManager: CreateInstance({6049b261-c1e6-11d1-a827-0040959a28c9}) succeeded 0[2a4220]: 211842 [this=c752f8] imgRequest::GetImage 0[2a4220]: $$$ processing event 0[2a4220]: $$$ done processing event 0[2a4220]: nsComponentManager: CreateInstance({6049b261-c1e6-11d1-a827-0040959a28c9}) succeeded 0[2a4220]: 211866 [this=c752f8] imgRequest::GetImage 0[2a4220]: $$$ processing event 0[2a4220]: $$$ done processing event 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 0[2a4220]: nsComponentManager: CreateInstanceByContractID(@mozilla.org/timer;1) succeeded 0[2a4220]: $$$ processing event
Assignee: wtc → dougt
Status: UNCONFIRMED → NEW
Component: NSPR → XPCOM
Ever confirmed: true
Product: NSPR → Browser
QA Contact: wtc → scc
Comment 14•22 years ago
|
||
Stuart, Any advice on how to track this one? See the last comment. Thanks
Comment 16•22 years ago
|
||
More Info. After a while, the Notify in docshell is just simply not happening. I'm still investigating if the timer is simply not kicking.
Comment 17•22 years ago
|
||
This is definitely looking like an XP bug. The timer is being added to the timer thread, but the Run in TimerThread is never executing the timer. I'm still looking to figure out why.
Comment 18•22 years ago
|
||
There is a major timer bug here and I need some help here. Can someone please explain why the only timer ever accessed in ::Run is mTimers[0]? This means that if by some strange coincidence, a timer never drops down to position 0, it never gets executed. That is the issue here. I'm attaching a large log that shows this.
Severity: normal → major
Comment 19•22 years ago
|
||
OK, the best way to look at this log is to search on refresh.html. Before the first refresh.html, notice a DOCSHELL timer created for 60000 and that timer inserted into the timerthread list. You can then see that it is in the list. Farther down you can see a PLEvent created for that timer. Now keep searching on refresh.html until you get to the last one. Again, you see the DOCSHELL timer created and the timer put on the list. If you look at the lists of timers following the last refresh.html, you can see that the timer is in the timer list but it is never executed because it never moves to mTimers[0].
Comment 20•22 years ago
|
||
I just got this to happen on Windows after five hours. Upping severity. Losing timers is a big deal.
Severity: major → critical
OS: OS/2 → All
Hardware: PC → All
Summary: META HTTP-EQUIV="refresh" stops working every 60 minutes (Mozilla 0.9.9 Build ID: 2002031114) → META HTTP-EQUIV="refresh" stops working after a while
Comment 21•22 years ago
|
||
OK, I have tons more info here. I'm moving the bug to NSPR because I am going to use it to change the OS/2 timer code. But there is a major cross-platform bug here. PR_IntervalNow is being used for timers, but it wraps. So there are cases where timers don't fire if they happen around the wrap. OS/2 was seeing the problem sooner because of a crappy timer implementation.
Component: XPCOM → NSPR
Product: Browser → NSPR
Target Milestone: --- → 4.1.2
Version: other → 4.1.2
Comment 22•22 years ago
|
||
Attachment coming up
Assignee: pavlov → wtc
OS: All → OS/2
QA Contact: scc → wtc
Hardware: All → PC
Comment 23•22 years ago
|
||
I'm removing our attempt to do high resolution timers on OS/2 and just switching to the default millisecond timer. If someone can show me a place where Mozilla genuinely needs macrosecond or nanosecond resolution, we will look at putting it back, but this code is simply wrong. Using the millisecond timer is much much safer
Comment 24•22 years ago
|
||
mkaply: I'm sure no one needs < 10ms resolution, but did you mean to say you saw Windows wrapping? Do we need another bug with a different OS setting? /be
Comment 25•22 years ago
|
||
I ran this testcase last night and definitely saw Windows stop similar to OS/2. I believe the case is rare, but can happen. Per the documentation on PR_TimerInterval, it does wrap, so if a timer happens to be scheduled just past the wrap, I think it will be missed. I'm going to talk to pav about it when he gets back on Monday.
Comment 26•22 years ago
|
||
Comment on attachment 80062 [details] [diff] [review] Remove high performance timers from OS/2 r=cls
Attachment #80062 -
Flags: review+
Comment 27•22 years ago
|
||
Taking as wtc's on vacation. We're going to need this on the branch as well.
Assignee: wtc → seawood
Keywords: adt1.0.0,
mozilla1.0
Priority: -- → P1
Target Milestone: 4.1.2 → 4.2.1
Comment 28•22 years ago
|
||
I'll take the branch side since I can actually check it in then (assuming I can actually get a response from drivers for approval)
Comment 29•22 years ago
|
||
The patch has been checked in on the client branch & the NSPR trunk. Checking in nsprpub/pr/src/md/os2/os2inrval.c; /cvsroot/mozilla/nsprpub/pr/src/md/os2/os2inrval.c,v <-- os2inrval.c new revision: 3.7; previous revision: 3.6 done Checking in nsprpub/pr/src/md/os2/os2inrval.c; /cvsroot/mozilla/nsprpub/pr/src/md/os2/os2inrval.c,v <-- os2inrval.c new revision: 3.6.2.1; previous revision: 3.6 done
Comment 30•22 years ago
|
||
Comment on attachment 80062 [details] [diff] [review] Remove high performance timers from OS/2 a=scc for checkin to the mozilla 1.0 branch
Attachment #80062 -
Flags: approval+
Comment 31•22 years ago
|
||
Fix checked in
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 34•22 years ago
|
||
This is a cross-platform bug. The Windows NSPR code is still using the high-res timer, which has the maximum resolution supported by NSPR interval timers, and will therefore wrap at 5 hours. This fix was only fixed on OS/2, by lowering the resolution of the timer in the OS/2 NSPR interval implementation. However, there are other NSPR applications than Mozilla that need high-resolution timing. I have opened a separate bug on this, 164841. As of today, this bug still occurs on Windows since NSPR on Windows has high-resolution timing. It will happen on any platform that has the maximum NSPR timer resolution. The bug is in in the XP browser code, and that's where it should be corrected. Whenever an interval may be longer than 5 hours, the browser must use PRTime and PR_Now(), not PRIntervalTime / PR_IntervalNow().
Status: VERIFIED → REOPENED
OS: OS/2 → All
Hardware: PC → All
Resolution: FIXED → ---
Comment 35•22 years ago
|
||
Actually I believe the wrapping in the XP timer code was fixed.
Comment 36•22 years ago
|
||
Over to Pavlov for verification that the XP timer bug was fixed.
Assignee: seawood → pavlov
Status: REOPENED → NEW
Component: NSPR → XPCOM
Product: NSPR → Browser
Target Milestone: 4.2.1 → ---
Version: 4.1.2 → other
Comment 37•22 years ago
|
||
I believe that http://bugzilla.mozilla.org/show_bug.cgi?id=138791 nsTimer does not handle interval rollover Fixed this
Assignee | ||
Comment 39•22 years ago
|
||
looks like brendan fixed this. Brendan, confirm please.
Comment 40•22 years ago
|
||
I can confirm that bug 138791 is fixed, if that's what you want. Doug, if you have tested this and it worksforyou, please close and I'll mark VERIFIED. /be
Assignee | ||
Comment 41•22 years ago
|
||
ran the test case here for the last 8 hours and it is still refreshing.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•