Re: On starting WebWorkers with blob: URLs...

2014-03-20 Thread Jonas Sicking 
On Wed, Mar 19, 2014 at 8:05 AM, Anne van Kesteren  wrote:
>> This is because we have been bit several times by having code from
>> security context A (in our case code from chrome://) receive a URL
>> from code from security context B. A would then load that URL. This
>> way B can trick A into creating content that B controls, but that runs
>> with As privileges.
>>
>> I'd love it if the web also had such an opt-in flag, but I don't know
>> how possible that is to create.
>
> We could have an attribute on the various loading contexts, no?

We could. Would love to see proposals for that. Right now the
specification for origin handling is fiction and as far as I know
there is no proposal that all involved parties agree to. An important
question is if we can fix data:'s origin handling, without making it
complicated enough that we don't want to use it for anything else.

/ Jonas

Re: Should events be preferably sent to the Window or the nearest object?

2014-03-20 Thread Marcos Caceres 


On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote:
> > Agreed. The exact target isn't very important here, and so being  
> consistent with legacy event firing for the same system is probably  
> a good idea.

Agree. Let's go with consistency, even though it feels a bit weird.

Re: Push API register - vendor specific details

2014-03-20 Thread Jonas Sicking 
On Thu, Mar 20, 2014 at 8:19 AM, Michael van Ouwerkerk
 wrote:
> An example call might look like this:
> navigator.push.register({
> gcmSenderId: 'some value',
> apnsPushId: 'some other value'
> });

Let me play devil's advocate a bit.

We have already given up on having the "server side" of push as a
standardized protocol for now. It seems like we are now doing the same
with the client side.

Given this, what is the advantage of having a push specification on
the form of what you are proposing, over having a push API that simply
looks like

x = navigator.pushProtocol; // "gcm", "apns", "mozillapush"

So the whole spec would be that single property. Possibly we would
also define the name for the ServiecWorker event that is used to
notify about incoming notifications.

After a page checks that property, it could then call a protocol
specific API and pass protocol specific arguments in order to do any
registration. Or if the protocol doesn't require a registration then
the page can simply do nothing. In order to push a message would send
a protocol specific network message to a protocol server.

You would then get the defined event in the ServiceWorker, but this
event contains protocol specific data. If the protocol supports
delivering a message body, then this body is included in the event.

In fact, if we encourage different protocol implementors to use
different names for the "register push" function, then we could use
normal feature detection (`if ("registerGCMPush" in navigator)`) and
get rid of the navigator.pushProtocol property too.

>From a developer point of view, what would be the difference between
what you are proposing and this approach? Possibly you'd have to write
a slightly larger switch statement because the "register for push"
function might have different names in different protocols. But the
upshot is that we can make both registration and message delivery have
access to more protocol-specific features.

Neither approach really feels like a "standard" though.

And both solutions sets a bit of a scary precedence. The web succeeded
in part because it was based on standards. Standards that made the
same code run across all browsers that implemented that standard.

That said, I definitely appreciate the desire to integrate with
existing push servers. But I don't know how to do that while really
sticking with the goal of having a standardized web.

/ Jonas

Re: Push API - use parameterized Promise types

2014-03-20 Thread Mounir Lamouri 
On Fri, 21 Mar 2014, at 2:28, Michael van Ouwerkerk wrote:
> In WebIDL we can now use parameterized Promise types:
> http://heycam.github.io/webidl/#idl-promise
> 
> My suggestion is that we make some minor changes in the Push API spec to
> take advantage of this. It reads much better and the prose can be
> simplified.
> 
> The following promise types:
> 
> interface PushManager {
> Promise register ();
> Promise unregister (DOMString pushRegistrationId);
> Promise registrations ();
> };
> 
> Can be changed like this:
> 
> interface PushManager {
> Promise register ();
> Promise unregister (DOMString pushRegistrationId);
> Promise registrations ();
> };
> 
> What do you think?

I wrote a quick patch for Respec (the tool being used for a few spec,
including that one) so it will correctly recognize parameterized
Promise: https://github.com/darobin/respec/pull/299 It's far from
perfect but hopefully Robin et al will help fix this quickly.

-- Mounir

Re: Push API - use parameterized Promise types

2014-03-20 Thread Boris Zbarsky 

On 3/20/14 11:46 AM, Michael van Ouwerkerk wrote:

So it is not normative? It seems it would be very informative though, so
still worth adding to the spec. But it seems it would be even better if
it was changed to be normative.


It's normative in the sense that the implementation of the method needs 
to return that value.


But the method call processing model in WebIDL itself doesn't enforce 
that, per se.  It assumes that specs that in their IDL say they return a 
Foo cannot in fact return anything other than a Foo and that therefore a 
Foo is what will be returned and needs to be converted from JS.  If 
WebIDL did _not_ assume that, it would presumably need some verbiage 
like "if the returned value is not a Foo, throw a TypeError"... but is 
that useful?


-Boris

Re: Push API - use parameterized Promise types

2014-03-20 Thread Boris Zbarsky 

On 3/20/14 11:39 AM, Domenic Denicola wrote:

If you return something that doesn't match the declared return value, that's a 
spec bug, but it has no impact on anything.


True, though the spec bug may make the spec not implementable (e.g. in a 
UA that autogenerates code from the IDL for a statically typed language, 
the thing being returned may not be of the right type, etc).


That's a good thing, of course; better spec bugs that are caught as soon 
as you try to implement the spec than subtle ones.  ;)


Also, for callback interfaces and callbacks the behavior is reversed: 
there return values get coerced while arguments are just whatever they are.


-Boris

RE: Push API - use parameterized Promise types

2014-03-20 Thread Luke Hoban 
I agree that there is significant readability value to the consumer of a 
WebIDL-based API spec if the return types of Promise-returning APIs are 
captured in the IDL.  For the same reason that documenting return types is 
valuable to readability even though not enforced in the JavaScript projection 
of WebIDL.  The IDL serves a useful documentation purpose even beyond the 
explicit semantics it conveys.

Luke

From: Michael van Ouwerkerk
Sent: ‎3/‎20/‎2014 11:46
To: Domenic Denicola
Cc: public-webapps
Subject: Re: Push API - use parameterized Promise types
So it is not normative? It seems it would be very informative though, so still 
worth adding to the spec. But it seems it would be even better if it was 
changed to be normative. 

Thanks,

Michael




On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola  
wrote:
From: Michael van Ouwerkerk 
> Ah I didn't know it has no effect on return values. Why not?
Well, I believe it's the same with all WebIDL method return values. If you 
return something that doesn't match the declared return value, that's a spec 
bug, but it has no impact on anything. (This is unlike argument values, where 
if the user passes in something that doesn't match the declared parameter type 
then conversion is performed.)

Re: Should events be preferably sent to the Window or the nearest object?

2014-03-20 Thread Tab Atkins Jr. 
On Thu, Mar 20, 2014 at 8:33 AM, Ian Hickson  wrote:
> On Fri, 21 Mar 2014, Mounir Lamouri wrote:
>> I would love to gather the opinion of public-webapps on a discussion
>> Hixie and I had for two different APIs recently: if an array |foo| can
>> change, should the change event be fired on its parent or the window
>> (its grandparent)? The two cases we discussed with Hixie were
>> navigator.languages and screen.orientation for which Hixie thinks the
>> change events should be fired on the window so developers can do > onlanguagechange="..." onorientationchange="..."> but I feel that having
>> the change event sent on the parent would make things more
>> self-contained.
>>
>> I would love to hear people's opinion on this.
>>
>> (Note: sending an orientationchange event to the window object would
>> have other implications because there is a proprietary API that does
>> that but this is entirely orthogonal.)
>
> To be clear, my opinion is just that we should be consistent. If the event
> is related to the Document, then we should fire it at the Document. If
> it's related to the , we should fire on the . Some objects are
> already EventTargets, including many new objects. I'm just saying that for
> existing objects that aren't EventTargets, and for which events have
> historically been sent to the Window, we should continue to send events to
> the Window, so that we don't end up sending some events to the object and
> some to the Window. In the case of Navigation, "online" and "offline"
> events go to the Window. In the case of Screen, "resize" and "scroll"
> events go to the Window. So it makes sense to put new events there too.

Agreed.  The exact target isn't very important here, and so being
consistent with legacy event firing for the same system is probably a
good idea.

~TJ

RE: Push API - use parameterized Promise types

2014-03-20 Thread Domenic Denicola 
I still don't understand what you mean by normative vs. informative in this 
context, so I can't say whether my original statement bolsters one or the other 
:P


How would implementations differ if it were normative vs. if it were 
informative?



From: Michael van Ouwerkerk 
Sent: Thursday, March 20, 2014 11:59
To: Domenic Denicola
Cc: public-webapps
Subject: Re: Push API - use parameterized Promise types

Well, I interpreted your comment that way ("it has no impact on anything"). 
Maybe normative vs informative is not what you meant though?

/m



On Thu, Mar 20, 2014 at 3:56 PM, Domenic Denicola 
mailto:dome...@domenicdenicola.com>> wrote:
I am not sure what you mean in this context by normative vs. informative. How 
would implementations differ if it were normative vs. if it were informative?

From: Michael van Ouwerkerk
Sent: ?3/?20/?2014 11:46
To: Domenic Denicola
Cc: public-webapps
Subject: Re: Push API - use parameterized Promise types

So it is not normative? It seems it would be very informative though, so still 
worth adding to the spec. But it seems it would be even better if it was 
changed to be normative.

Thanks,

Michael





On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola 
mailto:dome...@domenicdenicola.com>> wrote:
From: Michael van Ouwerkerk 
mailto:mvanouwerk...@google.com>>

> Ah I didn't know it has no effect on return values. Why not?

Well, I believe it's the same with all WebIDL method return values. If you 
return something that doesn't match the declared return value, that's a spec 
bug, but it has no impact on anything. (This is unlike argument values, where 
if the user passes in something that doesn't match the declared parameter type 
then conversion is performed.)

Re: Push API - use parameterized Promise types

2014-03-20 Thread Michael van Ouwerkerk 
Well, I interpreted your comment that way ("it has no impact on anything").
Maybe normative vs informative is not what you meant though?

/m



On Thu, Mar 20, 2014 at 3:56 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

>  I am not sure what you mean in this context by normative vs.
> informative. How would implementations differ if it were normative vs. if
> it were informative?
>  --
> From: Michael van Ouwerkerk 
> Sent: ‎3/‎20/‎2014 11:46
> To: Domenic Denicola 
> Cc: public-webapps 
> Subject: Re: Push API - use parameterized Promise types
>
>  So it is not normative? It seems it would be very informative though, so
> still worth adding to the spec. But it seems it would be even better if it
> was changed to be normative.
>
>  Thanks,
>
>  Michael
>
>
>
>
>
> On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
>
>> From: Michael van Ouwerkerk 
>>
>>  > Ah I didn't know it has no effect on return values. Why not?
>>
>>  Well, I believe it's the same with all WebIDL method return values. If
>> you return something that doesn't match the declared return value, that's a
>> spec bug, but it has no impact on anything. (This is unlike argument
>> values, where if the user passes in something that doesn't match the
>> declared parameter type then conversion is performed.)
>
>
>

RE: Push API - use parameterized Promise types

2014-03-20 Thread Domenic Denicola 
I am not sure what you mean in this context by normative vs. informative. How 
would implementations differ if it were normative vs. if it were informative?

From: Michael van Ouwerkerk
Sent: ‎3/‎20/‎2014 11:46
To: Domenic Denicola
Cc: public-webapps
Subject: Re: Push API - use parameterized Promise types

So it is not normative? It seems it would be very informative though, so still 
worth adding to the spec. But it seems it would be even better if it was 
changed to be normative.

Thanks,

Michael





On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola 
mailto:dome...@domenicdenicola.com>> wrote:
From: Michael van Ouwerkerk 
mailto:mvanouwerk...@google.com>>

> Ah I didn't know it has no effect on return values. Why not?

Well, I believe it's the same with all WebIDL method return values. If you 
return something that doesn't match the declared return value, that's a spec 
bug, but it has no impact on anything. (This is unlike argument values, where 
if the user passes in something that doesn't match the declared parameter type 
then conversion is performed.)

Re: Push API - use parameterized Promise types

2014-03-20 Thread Michael van Ouwerkerk 
So it is not normative? It seems it would be very informative though, so
still worth adding to the spec. But it seems it would be even better if it
was changed to be normative.

Thanks,

Michael





On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> From: Michael van Ouwerkerk 
>
> > Ah I didn't know it has no effect on return values. Why not?
>
> Well, I believe it's the same with all WebIDL method return values. If you
> return something that doesn't match the declared return value, that's a
> spec bug, but it has no impact on anything. (This is unlike argument
> values, where if the user passes in something that doesn't match the
> declared parameter type then conversion is performed.)

RE: Push API - use parameterized Promise types

2014-03-20 Thread Domenic Denicola 
From: Michael van Ouwerkerk 

> Ah I didn't know it has no effect on return values. Why not?

Well, I believe it's the same with all WebIDL method return values. If you 
return something that doesn't match the declared return value, that's a spec 
bug, but it has no impact on anything. (This is unlike argument values, where 
if the user passes in something that doesn't match the declared parameter type 
then conversion is performed.)

Re: Push API - use parameterized Promise types

2014-03-20 Thread Michael van Ouwerkerk 
Ah I didn't know it has no effect on return values. Why not?

/m



On Thu, Mar 20, 2014 at 3:31 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> From: Michael van Ouwerkerk 
>
> > It reads much better and the prose can be simplified.
>
> I am curious about the prose simplifications you mention? From talking to
> heycam, the value in the angle-brackets has no impact when used on the
> return type of a method, so I can't imagine it simplifying anything...

Re: Should events be preferably sent to the Window or the nearest object?

2014-03-20 Thread Ian Hickson 
On Fri, 21 Mar 2014, Mounir Lamouri wrote:
> 
> I would love to gather the opinion of public-webapps on a discussion 
> Hixie and I had for two different APIs recently: if an array |foo| can 
> change, should the change event be fired on its parent or the window 
> (its grandparent)? The two cases we discussed with Hixie were 
> navigator.languages and screen.orientation for which Hixie thinks the 
> change events should be fired on the window so developers can do  onlanguagechange="..." onorientationchange="..."> but I feel that having 
> the change event sent on the parent would make things more 
> self-contained.
> 
> I would love to hear people's opinion on this.
> 
> (Note: sending an orientationchange event to the window object would 
> have other implications because there is a proprietary API that does 
> that but this is entirely orthogonal.)

To be clear, my opinion is just that we should be consistent. If the event 
is related to the Document, then we should fire it at the Document. If 
it's related to the , we should fire on the . Some objects are 
already EventTargets, including many new objects. I'm just saying that for 
existing objects that aren't EventTargets, and for which events have 
historically been sent to the Window, we should continue to send events to 
the Window, so that we don't end up sending some events to the object and 
some to the Window. In the case of Navigation, "online" and "offline" 
events go to the Window. In the case of Screen, "resize" and "scroll" 
events go to the Window. So it makes sense to put new events there too.

IMHO.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

RE: Push API - use parameterized Promise types

2014-03-20 Thread Domenic Denicola 
From: Michael van Ouwerkerk 

> It reads much better and the prose can be simplified.

I am curious about the prose simplifications you mention? From talking to 
heycam, the value in the angle-brackets has no impact when used on the return 
type of a method, so I can't imagine it simplifying anything...

Push API - use parameterized Promise types

2014-03-20 Thread Michael van Ouwerkerk 
In WebIDL we can now use parameterized Promise types:
http://heycam.github.io/webidl/#idl-promise

My suggestion is that we make some minor changes in the Push API spec to
take advantage of this. It reads much better and the prose can be
simplified.

The following promise types:

interface PushManager {
Promise register ();
Promise unregister (DOMString pushRegistrationId);
Promise registrations ();
};

Can be changed like this:

interface PushManager {
Promise register ();
Promise unregister (DOMString pushRegistrationId);
Promise registrations ();
};

What do you think?

Regards,

Michael

Should events be preferably sent to the Window or the nearest object?

2014-03-20 Thread Mounir Lamouri 
Hi,

I would love to gather the opinion of public-webapps on a discussion
Hixie and I had for two different APIs recently: if an array |foo| can
change, should the change event be fired on its parent or the window
(its grandparent)? The two cases we discussed with Hixie were
navigator.languages and screen.orientation for which Hixie thinks the
change events should be fired on the window so developers can do  but I feel that having
the change event sent on the parent would make things more
self-contained.

I would love to hear people's opinion on this.

(Note: sending an orientationchange event to the window object would
have other implications because there is a proprietary API that does
that but this is entirely orthogonal.)

Thanks,
-- Mounir

Push API register - vendor specific details

2014-03-20 Thread Michael van Ouwerkerk 
To prevent abuse, many platforms require vendor specific registration
details for interacting with their push messaging systems. This allows e.g.
for banning spammers.

On Android, Google Cloud Messaging (GCM) is the canonical push messaging
system. Client registration requires passing a sender id and returns a
registration id:
http://developer.android.com/google/gcm/gs.html

iOS native apps:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ProvisioningDevelopment.html

Safari Push Notifications (currently desktop only):
https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html#//apple_ref/doc/uid/TP40013225-CH3-SW1

This means that if the Push API is implemented around these systems, vendor
specific registration details must be provided.

How can we best manage the vendor specific details in the
navigator.push.register method?

The best suggestion I have heard is to give the register method a single
optional argument, which is a dictionary. Its attributes are optional and
it can be extended easily.

An example call might look like this:
navigator.push.register({
gcmSenderId: ‘some value’,
apnsPushId: ‘some other value’
});

I think this would be cleaner than e.g. user agent string parsing, and
serving different content based on that.

What do you think?

Regards,

Michael