187612 - <meta> refresh doesn't send STATE_REDIRECTING to web progress listeners

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Darin Fisher]

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)?

Comment 1

[Michael Buckland]

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

Comment 2

[Adam Lock]

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.

Comment 3

[Darin Fisher]

adam: [e-mail] 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?

Comment 4

[nws]

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?  

Comment 5

[Adam Lock]

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.

Comment 6

[Michael Buckland]

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

Comment 7

[Juan José Mata]

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

Comment 8

[RobertJ]

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

Comment 9

[Darin Fisher]

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!! :)

Comment 10

[Andrew Hagen]

Related to bug 168215?