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

RESOLVED DUPLICATE of bug 337688

Status

Core Graveyard
XForms
RESOLVED DUPLICATE of bug 337688
11 years ago
a year ago

People

(Reporter: aaronr, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

99.73 KB, text/xml
Details
752 bytes, application/xhtml+xml
Details
(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 216792 [details]
instance data for testcase
(Reporter)

Comment 2

11 years ago
Created attachment 216793 [details]
testcase
(Reporter)

Comment 3

11 years ago
(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.
(Reporter)

Comment 4

11 years ago
(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.
(Reporter)

Comment 6

11 years ago
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.
(Reporter)

Comment 7

11 years ago
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.

Updated

11 years ago
Assignee: aaronr → xforms

Comment 8

11 years ago
This must be a dupe of 337688.

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