Custom submission headers are broken

[GoogleCodeExporter]

The attached forms (one HTML, one XHTML) contain a submission that should 
fail due to a bad resource. The submission itself contains a custom header 
element. These forms display a number of different problems in different 
browsers, which may or may not be rooted in the same cause.

In HTML mode in Firefox, it can be seen that xf:header and its children are 
not decorated, causing the browser to throw an exception from xforms-
submission.js#setHeaders() when nodelist[0].getValue() is called. This has 
the effect of terminating submission processing before the xforms-submit-
error event could be dispatched.

In XHTML mode in Firefox, xf:header is decorated correctly and the test 
passes (i.e. the submission fails sanely).

In HTML mode in Safari, the test passes.

In XHTML mode in Safari, the test passes, but the header name and value 
text gets displayed in the page erroneously.

In both HTML and XHTML modes in Internet Explorer, the test fails and the 
header name and value text gets displayed in the page erroneously.

I may branch specific bugs off into their own distinct issues that block 
this one, as more root-cause analysis is performed.

Original issue reported on code.google.com by phil.boo...@gtempaccount.com on 24 Nov 2009 at 11:38

Attachments:

• submission-header.html
• submission-header.xhtml

[GoogleCodeExporter]

I've discovered that this issue does not seem to occur in IE 7 (I was using IE 
8 
before).

Original comment by phil.boo...@gtempaccount.com on 27 Nov 2009 at 1:14

[GoogleCodeExporter]

Having looked at the code, it seems that the decoration of header's children is 
an 
interesting area. In Firefox and IE, it is postponed until the entire documents 
is 
ready, and then applied with the aid of the CSS class 'header-ready'. I'm not 
yet 
aware of why it has to be done like this.

Anyway, a consequence of this is that the test will actually pass in Firefox 
HTML 
mode, provided you allow 'sufficient' time for the decoration to occur. In 
terms of 
automating tests in Selenium, this means waiting until some time after 
xforms-ready 
has been dispatched.

Obviously this is in no way a solution in and of itself, but I thought it was 
worth 
noting.

Original comment by phil.boo...@gtempaccount.com on 27 Nov 2009 at 1:21

[GoogleCodeExporter]

I never realised until this morning, hence the previous comment, but header 
supports 
@nodeset. So decoration has to be postponed until the iterations can be worked 
out 
druing rewire().

Original comment by phil.boo...@gtempaccount.com on 30 Nov 2009 at 2:29

[GoogleCodeExporter]

A fix is awaiting review at r3201.

The fix itself is somewhat hackish. In the problem cases, the call to 
UX.addClassName 
in Header.onDocumentReady() is not working (decoration of child elements does 
not 
occur). Yet, if the call is made in the constructor, it correctly invoked child 
decoration. I've no idea why that is the case, but it is.

The other part of the fix is to add a binding rule for header to the CSS, so 
that it 
gets decorated (again, it wasn't until now in the problem cases).

Original comment by phil.boo...@gtempaccount.com on 30 Nov 2009 at 3:52

[GoogleCodeExporter]

Original comment by phil.boo...@gtempaccount.com on 30 Nov 2009 at 3:57

• Changed state: InReview

[GoogleCodeExporter]

In trunk at r3205.

Original comment by phil.boo...@gtempaccount.com on 2 Dec 2009 at 11:57

• Changed state: Fixed
• Added labels: Iteration-20091127
• Removed labels: Iteration-20091120