Closed Bug 332292 Opened 18 years ago Closed 18 years ago

send to submission with @replace="instance" no longer working

Categories

(Core Graveyard :: XForms, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 337688

People

(Reporter: aaronr, Unassigned)

Details

Attachments

(2 files)

followup to bug 316875.  While using a xf:send to a submission with @replace="instance" and @ref="instance('xxx')" works on the 1.8.0 branch, it no longer works with the trunk.  Well, that isn't perfectly accurate.  The first replace instance works.  After that it no longer works.  However, as Allan observed, if you replace the xf:send with a xf:submit to the same submission element, it works just fine on the trunk.  The codepath is pretty much the same, the big difference is that the codepath is initiated with an xforms-submit event dispatch and handling when xf:send is used.

The issue appears to lie with security principals.  When nsXFormsSubmissionElement::Submit is called, it will call GetBoundInstanceData.  In the failing case, this will fail during nsXFormsUtils::EvaluateXPath trying to evaluate the @ref.  When EvaluateXPath calls EvaluateWithContext, xpath will call nsContentUtils::CanCallerAccess, passing in the contextNode.  This will fail because the contextNode won't have a principal.

In the case where we are using the xf:submit, when we get to CanCallerAccess, the contextNode still won't have a principal, but it doesn't matter because we don't get to that check.  In this case CanCallerAccess won't get back a subjectPrincipal, so it will return successful right away.

So I guess the question is should the contextNode always have a principal?  And if so, why don't we have one?  I'm guessing this is it because usually when CanCallerAccess is called, they never seem to jump out because subjectPrincipal is null except in our xf:submit case.
Attached file testcase
(In reply to comment #2)
> Created an attachment (id=216793) [edit]
> testcase
> 

You can tell if the replace instace fails by either watching the debug output or checking the status bar to see if it is hitting bugzilla to grab the data.  Or put a breakpoint on nsXFormsSubmissionElement::LoadReplaceInstance.  It won't get hit in the failing case.
(In reply to comment #2)
> Created an attachment (id=216793) [edit]
> testcase
> 

Oops, recreation scenario:

Click on the testcase attachment to load it.  You'll see two triggers and a bunch of 'div's.  If you click on the 'Will Fail Replace' trigger, you'll see in the status that it goes out to bugzilla to grab the instance.  However, any subsquent click on the 'Will Fail Replace' trigger won't do that.  Any click of the 'Wont Fail Replace' button will successfully go to bugzilla to grab the new instance.
I don't have a build with xforms currently, so I can't test the testcases. But all nodes should have a principal. This should especially be the case on trunk where we're more consistent in how and when we set up the principal.
looks like the node no longer has the problem where it has no principal on the trunk.  Now the principal is a nsNullPrincipal, which will still cause nsContentUtils::CanCallerAccess to fail when it calls CheckSameOriginPrincipal.
one of the principal patches that went in the trunk looks to have fixed this.  We should look at this again in the next couple of weeks and if it is still fixed we should close it.
Assignee: aaronr → xforms
This must be a dupe of 337688.

*** This bug has been marked as a duplicate of 337688 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: