DocumentOrigin

Josh Aas josh at mozilla.com
Fri Sep 9 10:18:24 PDT 2011


I think we're good to go here. Proposal accepted with a value of 22 assigned to NPNVdocumentOrigin. Thanks to everyone who helped out!

--
Josh Aas
Mozilla Corporation

----- Original Message -----
From: "Rajesh Gwalani" <rgwalani at adobe.com>
To: "Adam Barth" <abarth-mozilla at adambarth.com>, "Josh Aas" <josh at mozilla.com>
Cc: "Boris Zbarsky" <bzbarsky at mit.edu>, plugin-futures at mozilla.org
Sent: Wednesday, September 7, 2011 1:50:24 PM
Subject: RE: DocumentOrigin

The current proposal works for the Flash Runtime.

I second Adam's comment that we need to have a separate discussion about adding more like these.

--
Rajesh

-----Original Message-----
From: plugin-futures-bounces at mozilla.org [mailto:plugin-futures-bounces at mozilla.org] On Behalf Of Adam Barth
Sent: Wednesday, September 07, 2011 12:14 AM
To: Josh Aas
Cc: Boris Zbarsky; plugin-futures at mozilla.org
Subject: Re: DocumentOrigin

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 separately.

Adam


On Mon, Aug 29, 2011 at 4:50 PM, Adam Barth <abarth-mozilla at adambarth.com> wrote:
> On Mon, Aug 29, 2011 at 1:39 PM, Josh Aas <josh at mozilla.com> 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 adambarth.com>
>> Cc: plugin-futures at mozilla.org
>> 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 mit.edu>  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 mozilla.org
>> https://mail.mozilla.org/listinfo/plugin-futures
>>
>
_______________________________________________
plugin-futures mailing list
plugin-futures at mozilla.org
https://mail.mozilla.org/listinfo/plugin-futures


More information about the plugin-futures mailing list