Adam Barth abarth-mozilla at
Wed Sep 7 00:14:10 PDT 2011

I should also say that I think this API is great.  The only question
in my mind is whether we want more like it, but we can tackle that


On Mon, Aug 29, 2011 at 4:50 PM, Adam Barth
<abarth-mozilla at> wrote:
> On Mon, Aug 29, 2011 at 1:39 PM, Josh Aas <josh at> wrote:
>> Thanks for the feedback.
>> I think the other values discussed here - HTML5 sandboxing, document.domain - should be separate NPN variables if we do something for them at all. I'd like to move the move the current spec forward without them.
>> I think we should stick with unicode serialization because that's what we are using already in other parts of NPAPI. I'm not convinced that ease-of-use outweighs consistency here.
>> Do people see any more issues with the existing spec?
> Apparently this API might not work perfectly for Flash.  I don't
> understand the full details (we'd have to get someone from Adobe to
> help us sort those out), but apparently Flash has slightly different
> rules for handling some situations, like about:blank, than HTML5.
> One approach is to expose both NPNVdocumentOrigin and NPNVdocumentURL,
> which would let Flash read the document's URL without need to resort
> to window.location madness.
> Adam
>> ----- Original Message -----
>> From: "Boris Zbarsky" <bzbarsky at MIT.EDU>
>> To: "Adam Barth" <abarth-mozilla at>
>> Cc: plugin-futures at
>> Sent: Wednesday, August 24, 2011 12:40:10 AM
>> Subject: Re: DocumentOrigin
>> On 8/14/11 6:22 PM, Adam Barth wrote:
>>> On Sun, Aug 14, 2011 at 10:33 AM, Boris Zbarsky<bzbarsky at>  wrote:
>>>> On 8/14/11 3:50 AM, Adam Barth wrote:
>>>>> 1) Do we want to communicate the document.domain value, if any?
>>>> Might not be a bad idea.  How does HTML represent that nowadays?
>>> Maybe it's best to use a separate NPN_GetValue for the document.domain
>>> value?  I think HTML5 represents it as the "effective script origin"
>>> or something like that.
>> Yeah, that might be the way to go.
>> -Boris
>> _______________________________________________
>> plugin-futures mailing list
>> plugin-futures at

More information about the plugin-futures mailing list