Security Manager vetoed action

[John J. Barton]

I'm working on
http://code.google.com/p/fbug/issues/detail?id=2343
Firebug doesn't display or debug XBL anonymous content
which I hope amounts to cleaning up some code from chromebug and adding
to Firebug.

I hit a problem, I get an error message "Security Manager vetoed action"
with the line number point to:
delete node.__walkingAnonymousChildren; // unmark looping
Here node is in an nsIDOMDocumentXBL document loaded in a content
browser. I set:
node.__walkingAnonymousChildren = true; // mark our node as looping
previously, and now I just to clean up.

Why can't this operation succeed?

jjb

[Boris Zbarsky]

On 9/30/09 12:55 AM, John J. Barton wrote:
> I hit a problem, I get an error message "Security Manager vetoed action"
> with the line number point to:
> delete node.__walkingAnonymousChildren; // unmark looping
> Here node is in an nsIDOMDocumentXBL document loaded in a content
> browser.

I assume |node| is just something that looks like a DOM node to you (as
in, you didn't do wrappedJSObject on it or anything?

If so, looks like the issue is that XPC_NW_DelProperty will throw
NS_ERROR_XPC_SECURITY_MANAGER_VETO, in general, when touching content
from chrome. Not sure why that code is as it is; this was part of the
initial XPCNativeWrapper landing. Looks wrong to me; worth filing a bug
on and ccing ":jst" and "brendan@moz" and probably "mrbkap" and ":bz".
Minimal-ish testcase:

javascript: var foo = new XPCNativeWrapper(document.body); foo.bar =
'x'; delete foo.bar;

Of course I'm not quite sure why you need the __walkingAnonymousChildren
thing at all... Why do you need it?

-Boris

[John J. Barton]

Boris Zbarsky wrote:
> On 9/30/09 12:55 AM, John J. Barton wrote:
>> I hit a problem, I get an error message "Security Manager vetoed action"
>> with the line number point to:
>> delete node.__walkingAnonymousChildren; // unmark looping
>> Here node is in an nsIDOMDocumentXBL document loaded in a content
>> browser.
>
> I assume |node| is just something that looks like a DOM node to you (as
> in, you didn't do wrappedJSObject on it or anything?

Just a node, no wrappedJSObject.

>
> If so, looks like the issue is that XPC_NW_DelProperty will throw
> NS_ERROR_XPC_SECURITY_MANAGER_VETO, in general, when touching content
> from chrome. Not sure why that code is as it is; this was part of the
> initial XPCNativeWrapper landing. Looks wrong to me; worth filing a bug
> on and ccing ":jst" and "brendan@moz" and probably "mrbkap" and ":bz".
> Minimal-ish testcase:
>
> javascript: var foo = new XPCNativeWrapper(document.body); foo.bar =
> 'x'; delete foo.bar;

https://bugzilla.mozilla.org/show_bug.cgi?id=519901

>
> Of course I'm not quite sure why you need the __walkingAnonymousChildren
> thing at all... Why do you need it?

I don't, I tried something different and Firebug now supports anonymous
children (XBL), thanks.
jjb

[Boris Zbarsky]

On 10/1/09 12:31 AM, John J. Barton wrote:
>> Of course I'm not quite sure why you need the
>> __walkingAnonymousChildren thing at all... Why do you need it?
>
> I don't, I tried something different and Firebug now supports anonymous
> children (XBL), thanks.

Excellent!

I guess my question is why you needed some sort of guard-like thing at
all (whether __walkingAnonymousChildren or the "something different" you
ended up with)...

-Boris

[John J. Barton]

In the case where XBL may be present, each node has in effect two lists,
anonymous nodes and not-anonymous nodes. Firebug has a sophisticated
system called insideOut box to show just the right HTML nodes with
minimal rendering. This is critical if you are using nodes to show
nodes, since you have a >10x expansion factor.

The actual algorithm is (or was) a black box, but we knew where the
request-for-next-node code was. So I was hacking in the anonymous list
by first returning anonymous nodes while marking the node with
__walkingAnonymousChildren and, when they were exhausted, deleting the
mark and returning non-anonymous nodes until they were finished.

Building a side table or other solutions would have required knowing
when to clean up.

I ended up figuring out the code and doing the iteration properly. This
was feasible because Chromebug's JS debugger is working well now so I
could step through the code. My previous efforts at tracing it was not
successful (too much output and maybe I knew too little).

jjb