permission denied accessing XULElement.parentNode with video controls XBL
Chris Double
native controls for play, pause, etc. These are currently implemented
using XBL. The XBL code gets it's parent node (which is the HTML video
element) and attaches events to listen for when it should enable play,
pause, etc, and to handle the button presses.
This worked fine until recently, until bug 410119 was committed and
then it broke. I get 'permission denied accessing
XULElement.parentNode' when trying to access the html video DOM
element from XBL. Here's the snippet of XBL:
<binding id="videoControls">
...
<implementation>
<constructor>
this.init();
</constructor>
<method name="init">
<body>
<
Boris Zbarsky
> This worked fine until recently, until bug 410119 was committed and
> then it broke.
So in your case, the <xul:videocontrols> is native-anonymous. But the XBL is
running with the permissions of the page the <video> is in, and hence can't
access any properties on the <xul:videocontrols> (including .parentNode)...
This would have bitten you much earlier if you weren't using a XUL-namespace tag
for the controls.
> Is it not possible to access HTML DOM nodes from within XBL like this?
The problem is not so much the XBL as the native anonymous content. Would it
make any sense to attach the binding to the <video> itself, so the controls are
XBL-bound content, not native anonymous content? That would enable web pages to
access them, which might be pretty suboptimal, but might be worth it in terms of
having this work...
Another possible option is to have this XBL binding implement
nsISecurityCheckedComponent and use that to allow gets for certain properties.
That might be the least-invasive change in you case, and as long as the XBL
document lives at a "content" chrome URI should work, I think.
-Boris
Jonas Sicking
Will that really work even though the binding is running with page
privileges? It shouldn't IIRC.
/ Jonas
Boris Zbarsky
>> Another possible option is to have this XBL binding implement
>> nsISecurityCheckedComponent and use that to allow gets for certain
>> properties. That might be the least-invasive change in you case, and
>> as long as the XBL document lives at a "content" chrome URI should
>> work, I think.
>
> Will that really work even though the binding is running with page
> privileges? It shouldn't IIRC.
The security check for whether xbl:implements is allowed is based on the
principal of the binding document. If that were not the case, remote XUL (which
uses chrome bindings which use implements) would break terribly.
-Boris
Chris Double
> Another possible option is to have this XBL binding implement
> nsISecurityCheckedComponent and use that to allow gets for certain properties.
That approach worked fine, thanks!
Chris.
--
http://www.bluishcoder.co.nz
Neil
> Another possible option is to have this XBL binding implement
> nsISecurityCheckedComponent and use that to allow gets for certain
> properties.
Whoa, we could have made tooltips/scrollbars really anonymous ages ago,
and not just when we removed their use of JS (not that I disagree with
the removal of the JS)!?
--
Warning: May contain traces of nuts.