293436 - Generating binding exceptions incorrectly

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[aaronr]

Placeholder bug.  We currently generate binding exceptions where other
processors don't.  Most of the places make sense, but David says that in a March
f2f everyone decided that only bad @model and binding attributes should generate
xforms-binding-exceptions.

So we need to fix xf:send, xf:setindex and xf:submit.  Also a bad nodeset on a
xf:bind shouldn't generate them.

Comment 1

[aaronr]

Attachment: testcase for xf:send

Comment 2

[aaronr]

Attachment: testcase for xf:submit

Comment 3

[aaronr]

Attachment: testcase for xf:setindex

Comment 4

[aaronr]

I couldn't get the code for generating the xforms-binding-exception to fire with
an invalid nodeset value on xf:bind, but that probably means that we should move
the ReportError there.  Looks like the evaluation isn't returning a failing rv,
but rather an empty result set.

Comment 5

[Allan Beaufour]

Attachment: Patch

Comment 6

[aaronr]

Comment on attachment 192197 [details] [diff] [review]
Patch

>===================================================================
>RCS file: /cvsroot/mozilla/extensions/xforms/nsXFormsSendElement.cpp,v
>retrieving revision 1.3
>diff -u -p -U8 -r1.3 nsXFormsSendElement.cpp
>--- nsXFormsSendElement.cpp	8 Apr 2005 15:40:54 -0000	1.3
>+++ nsXFormsSendElement.cpp	10 Aug 2005 13:25:26 -0000
>@@ -71,17 +71,17 @@ nsXFormsSendElement::HandleAction(nsIDOM
> 
>   nsCOMPtr<nsIDOMElement> el;
>   doc->GetElementById(submissionID, getter_AddRefs(el));
> 
>   if (!el || !nsXFormsUtils::IsXFormsElement(el, submission)) {
>     const PRUnichar *strings[] = { submissionID.get(), submission.get() };
>     nsXFormsUtils::ReportError(NS_LITERAL_STRING("idRefError"),
>                                strings, 2, mElement, mElement);
>-    return nsXFormsUtils::DispatchEvent(mElement, eEvent_BindingException);
>+    return NS_OK;
>   }

I know that I said in the bug that they agreed to this in that f2f, but since
it never got mentioned in the new errata, should we still do this for the send
element?  Without mention in the errata, I would think that 4.5.1 still applies
to the send element.

The rest of the patch looks fine.

Comment 7

[Allan Beaufour]

(In reply to comment #6)
> I know that I said in the bug that they agreed to this in that f2f, but since
> it never got mentioned in the new errata, should we still do this for the send
> element?  Without mention in the errata, I would think that 4.5.1 still applies
> to the send element.

Darn. I was actually looking around the spec. but didn't bother to read 4.5.1 :(
Yes, send should still generate the event.

Comment 8

[Allan Beaufour]

Attachment: Patch wo send changes

Comment 9

[aaronr]

Comment on attachment 192342 [details] [diff] [review]
Patch wo send changes


> NS_HIDDEN_(nsresult)
> NS_NewXFormsSetIndexElement(nsIXTFElement **aResult)
>Index: nsXFormsTriggerElement.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/extensions/xforms/nsXFormsTriggerElement.cpp,v
>retrieving revision 1.17
>diff -u -p -U8 -r1.17 nsXFormsTriggerElement.cpp
>--- nsXFormsTriggerElement.cpp	26 Jun 2005 18:30:17 -0000	1.17
>+++ nsXFormsTriggerElement.cpp	10 Aug 2005 13:25:26 -0000
>@@ -122,17 +122,17 @@ nsXFormsSubmitElement::HandleDefault(nsI
>   nsCOMPtr<nsIDOMElement> submissionElement;
>   ownerDoc->GetElementById(submissionID, getter_AddRefs(submissionElement));
>   nsCOMPtr<nsIXFormsSubmissionElement> xfSubmission(do_QueryInterface(submissionElement));
>   
>   if (!xfSubmission) {
>     const PRUnichar *strings[] = { submissionID.get(), submission.get() };
>     nsXFormsUtils::ReportError(NS_LITERAL_STRING("idRefError"),
>                                strings, 2, mElement, mElement);
>-    return nsXFormsUtils::DispatchEvent(mElement, eEvent_BindingException);
>+    return NS_OK;
>   }
> 
>   xfSubmission->SetActivator(this);
>   nsXFormsUtils::DispatchEvent(submissionElement, eEvent_Submit);
> 
>   *aHandled = PR_TRUE;
>   return NS_OK;
> }

Da*nit!  I didn't look closely enough at this one.  xf:submit also falls under
4.5.1.	With that removed, r=me

Comment 10

[Allan Beaufour]

(In reply to comment #9)
> Da*nit!  I didn't look closely enough at this one.  xf:submit also falls under
> 4.5.1.	With that removed, r=me

Well, then we're two.... so we're down to setindex begin the only element
needing a fix...

Comment 11

[Allan Beaufour]

Attachment: Patch

(In reply to comment #10)
> (In reply to comment #9)
> > Da*nit!  I didn't look closely enough at this one.	xf:submit also falls
under
> > 4.5.1.	With that removed, r=me
> 
> Well, then we're two.... so we're down to setindex begin the only element
> needing a fix...

The two "spec. reading masters" :-) have now drilled it down to only fixing
setindex

Comment 12

[Allan Beaufour]

Checked in to trunk

Comment 13

[aaronr]

Allan, anything else for this bug, or can we resove+fix this?  If resolve+fix
it, then we need to remove the xf-to-branch status since the current patch is
already in the branch.