263084 - xforms requires a way to observe and maybe abort webnavigation loads

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, enhancement)

Description

[Darin Fisher]

xforms requires a way to observe and maybe abort webnavigation loads.

xforms submission has many modes of operation, but in all cases it is critical
that some extra events fire on the xforms model (or submission) element before
an xforms submission can be considered complete.

one case is when a xforms submission intends to replace the entire document
being viewed with the contents returned from the server.  this case is meant to
mimic normal HTML form submission.  however, with xforms there's a twist.  it is
necessary to dispatch those pesky events prior to replacing the content in the
page.  moreover, the event dispatched varies depending on whether or not form
submission yielded a success and whether or not there is a response body.

so, the xforms submission code needs to target a load to the current docshell,
but it needs to intercept OnStartRequest from necko, so that it can determine
if: 1) the response has succeeded, and 2) the response contains a body.

i spoke to bz about this problem over IRC, and we talked about the possibility
of somehow overriding the primary nsIURIContentListener passed to
nsIURILoader::OpenURI, but there are cases where the content listener is never
invoked (e.g., when the necko request fails due to some low-level network
failure).  in those error cases, xforms still needs to be notified.

so, we thought it might make sense to tack on an observer, who is notified
before and after content dispatch (nsDocumentOpenInfo::DispatchContent).  we'd
notify the observer that the request is about to be dispatched, giving the
observer the opportunity to inspect the request and possibly veto the dispatch.  
we might be able to use nsIRequestObserver for the observer interface. 
OnStartRequest would be called before dispatch, and OnStopRequest would be
called after dispatch or if there is an error loading the request.

we'd then need to configure docshell (a.k.a. webnavigation) so that it can
accept our nsIRequestObserver implementation and pass it down to the URI loader
via OpenURI's aWindowContext parameter.  it might be sufficient to augment
nsIDocShellLoadInfo with a new attribute.

Comment 1

[Darin Fisher]

I found an alternate solution that involves using nsIDocShell::LoadStream when I
want to feed new content into the browser (which corresponds to the
replace="all" submission mode).  So, I no longer need to fix this bug.  Marking
WONTFIX.

Comment 2

[Leigh L. Klotz, Jr.]

Does this workaround also handle <submission replace="none"/>, when there is no
expectation of returned content, just status?

Comment 3

[Darin Fisher]

Yes, indeed it does.  My solution gives me control over the network load.  I get
a callback when response headers are available, allowing me to easily process
errors.  At that point, I can decide whether I want to stream the data to the
XML parser to generate a new instance document, stream it to the browser, or
simply do nothing with it.  Right now, using nsIDocShell::loadStream for
replace="all" is a bit of hack since it requires the entire response to be
downloaded before it is fed into the browser.  In the future, I may make use of
nsIWebBrowserStream instead to incrementally feed data into the browser.

Comment 4

[Darin Fisher]

I also wait until the entire response stream is downloaded before firing the
xforms-submit-done/-error events.  That would have to change if I switched to
nsIWebBrowserStream since the page being viewed would receive the 'unload' DOM
event once we started streaming new data into the browser.

Leigh: is it expected that xforms-submit-done/-error are delayed until the
entire submission response is received?

Comment 5

[Leigh L. Klotz, Jr.]

(In reply to comment #4)
> Leigh: is it expected that xforms-submit-done/-error are delayed until the
> entire submission response is received?
For xforms-submit-done, definitely.  I can motivate it with a use case (you
might want to wait until the response gets back and then take some action based
on it, and you need the whole instance content to be there), but the 1.o Rec
does say it at http://www.w3.org/TR/xforms/index-all.html#evt-submitdone
("ispatched in response to: completion of submit processing, including
processing any returned document.").

For xforms-submit-error in XForms 1.0, I don't think there is a way to tell when
it is dispatched if you use only the published interfaces, since there is no way
to extract any new information from the error, as XForms 1.0 claims to make
available only the submission URI.  I suspect that XForms 1.1 will allow you to
obtain the response code, which is known only after the submission begins to
return.  

Since at some point returned information from the error may be made available
via IDL-defined accessors or through context info, in preparation for XForms 1.1
(or to allow JavaScript access inside Mozilla) it may be a good idea to dispatch
xforms-submit-error after the error response is all received.

I will contribute one use case for xforms-submit-done and xforms-submit-error
handling.

Also, note that http://www.w3.org/TR/xforms/index-all.html#evt-submitError
incorrectly says that xforms-submit-error is dispatched to the model; I am told
that a forthcoming errata document will correctly note that xforms-submit-error,
like xforms-submit-done, is dispatched to the submission element.  Otherwise
there is no proper way to handle errors when there are multiple submissions per
model.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

> In the future, I may make use of
> nsIWebBrowserStream instead to incrementally feed data into the browser.

for that to work, you need to either make docshell implement that or make
mozilla use nsIWebBrowser...

Comment 7

[Darin Fisher]

> For xforms-submit-done, definitely.  I can motivate it with a use case (you
> might want to wait until the response gets back and then take some action 
> based on it, and you need the whole instance content to be there)...

Sorry, I was actually asking about the replace="all" case.  In that case, the
xforms document does not have a handle to the response data.  So, for example,
if the last 10 bytes out of a 100,000 byte response (replace="all") cannot be
delivered, should xforms-submit-error be generated?  If yes, then it means that
I must buffer the entire xforms submission response in the replace="all" case
before streaming it into the browser.  That is what I am doing now, but I just
want to make sure that that is correct.


> I suspect that XForms 1.1 will allow you to
> obtain the response code, which is known only after the submission begins to
> return.  

Will it also give access to the server-generated error page?  Some HTTP servers
are configured to send a useful error page when something goes wrong.  Are there
provisions for exposing that to the xforms-submit-error handler somehow?



> it may be a good idea to dispatch xforms-submit-error after the error response 
> is all received.

That is what the code currently does.


> I will contribute one use case for xforms-submit-done and xforms-submit-error
> handling.

Thank you.


> I am told that a forthcoming errata document will correctly note that 
> xforms-submit-error, like xforms-submit-done, is dispatched to the submission 
> element.

Yup, I've already seen this errata, and the current implementation dispatches
both events to the <submission> element.


biesi: yup, that's going to be fun ;)

Comment 8

[Leigh L. Klotz, Jr.]

I agree with you that these are harder questions that the one I answered (funny
how that works out). I think you do need point out to the WG the inefficiency
inherent in the xforms-submit-done replace="all" buffering that has to be done
just in case of error, and ask about the disposition for response content in the
xforms-submit-error in all replace="all|none|instance" cases.  Offhand I don't
see any impact from the instance replacement XPath addition in 1.1 to this area,
but I'm sure you're already aware of it.