328524 - copy handles textnodes wrong

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, defect)

Description

[Doron Rosenberg (IBM)]

We assume that text always goes into one textnode - however, Mozilla will split large textnodes into several.

Comment 1

[aaronr]

You know anyone who can point us to an example of where this happens?  Testcase?

Comment 2

[Doron Rosenberg (IBM)]

Just create a really long string :)

Comment 3

[Allan Beaufour]

(In reply to comment #0)
> We assume that text always goes into one textnode - however, Mozilla will split
> large textnodes into several.

Where do we do this? Could you elaborate a bit? :)

Comment 4

[Doron Rosenberg (IBM)]

Copy code assumes only one textnode can exist, and not a few one after each other. 

Comment 5

[Allan Beaufour]

(In reply to comment #4)
> Copy code assumes only one textnode can exist, and not a few one after each
> other. 

Problem is that, in XForms only the first text node is targeted by single node bindings. So we must not consider "following text nodes" -- unless they have been split. So unless it is possible to distinguish "text nodes that are split" from "normal text nodes", I guess this is impossible to fix.
[http://www.w3.org/TR/2006/REC-xforms-20060314/slice8.html#ui-processing]

Comment 6

[Doron Rosenberg (IBM)]

> Problem is that, in XForms only the first text node is targeted by single node
> bindings. So we must not consider "following text nodes" -- unless they have
> been split. So unless it is possible to distinguish "text nodes that are split"
> from "normal text nodes", I guess this is impossible to fix.
> [http://www.w3.org/TR/2006/REC-xforms-20060314/slice8.html#ui-processing]
> 
<foo>bla bli arh</foo> per the DOM spec should be one text node, but we would split it if it were long enough.  So anytime you have multiple text nodes following eachother, I believe we can safely assume they were split up.

Comment 7

[Allan Beaufour]

Attachment: Form with text node siblings

(In reply to comment #6)
> > Problem is that, in XForms only the first text node is targeted by single node
> > bindings. So we must not consider "following text nodes" -- unless they have
> > been split. So unless it is possible to distinguish "text nodes that are split"
> > from "normal text nodes", I guess this is impossible to fix.
> > [http://www.w3.org/TR/2006/REC-xforms-20060314/slice8.html#ui-processing]
> > 
> <foo>bla bli arh</foo> per the DOM spec should be one text node, but we would
> split it if it were long enough.  So anytime you have multiple text nodes
> following eachother, I believe we can safely assume they were split up.

No señor. Someone could be wicked enough to construct a document with text node siblings, like this form. Here the text nodes are not split, just because they are siblings.

Comment 8

[aaronr]

This bug SHOULD be fixed by bug 357652.  Keeping open to verify that fact.

Comment 9

[aaronr]

> Created an attachment (id=223744) [details]
> Form with text node siblings
> 
> (In reply to comment #6)
> > > Problem is that, in XForms only the first text node is targeted by single node
> > > bindings. So we must not consider "following text nodes" -- unless they have
> > > been split. So unless it is possible to distinguish "text nodes that are split"
> > > from "normal text nodes", I guess this is impossible to fix.
> > > [http://www.w3.org/TR/2006/REC-xforms-20060314/slice8.html#ui-processing]
> > > 
> > <foo>bla bli arh</foo> per the DOM spec should be one text node, but we would
> > split it if it were long enough.  So anytime you have multiple text nodes
> > following eachother, I believe we can safely assume they were split up.
> 
> No señor. Someone could be wicked enough to construct a document with text
> node siblings, like this form. Here the text nodes are not split, just because
> they are siblings.
> 

from comments to bug 357652:

// XForms specs 8.1.1 (http://www.w3.org/TR/xforms/slice8.html#ui-processing)
// says: 'if text child nodes are present, returns the string-value of the
// first text child node. Otherwise, returns "" (the empty string)'.
// The 'text child node' that is mentioned above is from the xforms
// instance document which is, according to spec, is formed by
// 'creating an XPath data model'. So we need to treat 'text node' in
// this case as an XPath text node and not a DOM text node.
// DOM XPath specs (http://www.w3.org/TR/2002/WD-DOM-Level-3-XPath-20020328/xpath.html#TextNodes)
// says:
// 'Applications using XPath in an environment with fragmented text nodes
// must manually gather the text of a single logical text node possibly
// from multiple nodes beginning with the first Text node or CDATASection
// node returned by the implementation'.

// Therefore we concatenate contiguous CDATA/DOM text nodes and return
// as node value.

Comment 10

[aaronr]

Attachment: testcase2

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

RIP xforms