Last Comment Bug 332292 - send to submission with @replace="instance" no longer working
: send to submission with @replace="instance" no longer working
Status: RESOLVED DUPLICATE of bug 337688
:
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: xforms
: Stephen Pride
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-30 16:10 PST by aaronr
Modified: 2016-07-15 14:46 PDT (History)
4 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
instance data for testcase (99.73 KB, text/xml)
2006-03-30 16:12 PST, aaronr
no flags Details
testcase (752 bytes, application/xhtml+xml)
2006-03-30 16:14 PST, aaronr
no flags Details

Description aaronr 2006-03-30 16:10:03 PST
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.
Comment 1 aaronr 2006-03-30 16:12:23 PST
Created attachment 216792 [details]
instance data for testcase
Comment 2 aaronr 2006-03-30 16:14:05 PST
Created attachment 216793 [details]
testcase
Comment 3 aaronr 2006-03-30 16:17:25 PST
(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.
Comment 4 aaronr 2006-03-30 16:21:14 PST
(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.
Comment 5 Jonas Sicking (:sicking) No longer reading bugmail consistently 2006-04-12 02:08:15 PDT
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.
Comment 6 aaronr 2006-04-14 17:31:52 PDT
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.
Comment 7 aaronr 2006-05-12 16:18:10 PDT
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.
Comment 8 Allan Beaufour 2006-05-29 08:26:01 PDT
This must be a dupe of 337688.

*** This bug has been marked as a duplicate of 337688 ***

Note You need to log in before you can comment on or make changes to this bug.