a page like www.broadcast.com, which redirects using a meta refresh triggers a DOCUMENT START/STOP pair followed by another DOCUMENT START/STOP pair. because of this it is impossible from the nsIWebProgressListener interface to determine the end of a document load. if the first document is being refreshed right away (timeout=0), then it seems like this should generate a STATE_REDIRECTING event to give webprogresslistener's a chance to detect the fact that another DOCUMENT START/STOP is pending. thoughts? is this a real bug? or, is there a way to accomplish what i am trying to accomplish using the existing interface(s)?

Discussed in bug triage meeting. Adam, can you respond to Darin's question?

Meta refresh is setup from the nsIURIContentListener::doContent and from calls to nsIRefreshURI::setupRefreshURI made while the content is being parsed in the content sinks. In other words it doesn't happen through the same mechanisms as the web progress listener. It is thus tricky to know what order it happens in relation to other notifications. It might be possible to suppress the intervening START / STOP pair but I wonder if the effort required is justified considering we don't even know if this is a bug. Is this double START/STOP affecting something or is it just something you noticed Darin? Personally I'd be inclined to mark this WONTFIX.

adam: NancySumner1@aol.com contacted me about this issue. she is trying to develop an embedding application that needs to know when a page has finished loading. that means taking into account meta refreshes with a zero timeout, which act very much like server redirects. how can an embedder learn when a meta refresh occurs? is there some other notification API that an embedder can hook into?

Darin summed up the issue I ran into well. :-) This isn't a bit deal if the start/stop messages coming in to nsIWebProgressListener::OnStateChange are just being used to update progress in the UI, but if you need to perform an action of some kind when the page is _completely_ done loading (one example - you may not want to allow printing in the UI until the final "stop" message has come in), it is a problem. When there is a meta refresh happening, I just see multiple sets of start/stop messages coming in and can't tell when the load is finally done. Is there some other way to detect this that I am unaware of?

Refresh timers are queued until the docshell is not busy, i.e. at the end of a page load. In theory (though this would have to be confirmed) it would happen after the various web progress notifications had happened. Therefore if there were a new method on nsIRefreshURI - for example getNextRefresh() that returned the seconds and URI of the next refresh or failure - it might be possible to call this to determine when the next one is due to fire from the OnStateChange handler. http://lxr.mozilla.org/seamonkey/source/webshell/public/nsIRefreshURI.idl The issue of child frames would also have to be dealt with. Each docshell implements nsIRefreshURI so it would be possible on a per-frame basis to determine when the next refresh timer would fire. I believe that the parent frame will be flagged busy while subframes are loading so it should possible to do all this from the one progress listener. This is all very hairy code so the order in which things happen and when are docshells busy would have to be verified.

Discussed in edt - plussing. adamlock, please target appropriate milestone.

5/5 EDT triage: minusing topembed+ status. Dropping this from the radar to better focus on existing working set.

I not sure if this is related however rather than create a new bug I thought I'd add it here. I'm using Mozilla 1.5 on Mac OS 10.2.6 The following TAG doesn't perform the redirect <META http-equiv="refresh" content="0; url=pgLoginNew.jsp"> The HTML code just shows up in the browser window. I know that the HTML standard discourages this technique but it is in the standard. bob

Robert: thanks for the info, but can you please file a new bug report since the issue you are seeing is unrelated to this bug report. thanks!! :)

Related to bug 168215?