264991 - Support xforms submission replace attribute

Status: RESOLVED FIXED

(Core Graveyard :: XForms, enhancement)

Description

[Darin Fisher]

Support xforms submission replace attribute.

see file:///home/darinf/packages/xforms-spec/slice11.html#submit-event

Comment 1

[Darin Fisher]

Attachment: v1 patch

This patch takes a simplistic approach to xforms submission.  Instead, of using
a different loader for each type of replacement, I use Necko directly to load
the submission response into a memory buffer (a pipe).	Then I process the data
in the pipe.  For replace='all', I use nsIDocShell::loadStream, and for
replace='instance', I use nsIDOMParser::parseFromStream.  This seems to work
well, and should be fine for reasonably sized responses.

We may wish to optimize replace='all' in the future by calling
nsIDocShell::loadStream from within OnStartRequest before all of the data has
been downloaded.  This would require some careful wrangling of object
ownership, etc., but I think it could be done.

In the future, we could also invent a way to invoke the DOM parser on a
sequence of data chunks.  Or, maybe we could create a special interface for
that.

The benefits of the current solution is that we don't have N different
codepaths leading up to calling AsyncOpen.  Using document.load is not a good
option since it does not provide a way to configure the upload stream.	And,
using webnavigation.loadURI is not a good option either because it does not
give us a way to abort the replacement of the current page if the resulting
document is empty (that's an xforms requirement!) -- see bug 263084, which
becomes somewhat obsolete by this patch.

Comment 2

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

+  // create a pipe in which to store the response

hmm, wouldn't nsIStreamLoader be easier?

Comment 3

[Darin Fisher]

(In reply to comment #2)
> +  // create a pipe in which to store the response
> 
> hmm, wouldn't nsIStreamLoader be easier?

yes, but the pipe uses much more optimal storage.  nsIStreamLoader forces all of
the content into a continguous buffer, whereas nsIDOMParser and nsIDocShell can
load content from a nsIInputStream, which can be a segmented buffer (which is
what nsPipe implements).

Comment 4

[Darin Fisher]

fixed-on-trunk