Re: Review of the Messaging API

Hi Dom!

All of your fixes seem good to me, thanks for taking care of this. Some notes below.

On Jul 4, 2011, at 15:09 , Dominique Hazael-Massieux wrote:
>> # Supported messaging types
>> 
>>    • "Using a single method to send message across many protocols
>> make it impossible to detect whether a given user agent supports a
>> specific messaging protocol." Should we add a canSendMessage() method
>> which would return unknown/yes/probably?
> 
> Hmm... That has the sour taste of DOM hasFeature(), which never really
> gave useful answers. That remains to me the major weakness of the API as
> it stands.
> 
> Here is a random idea: maybe we make sendMessage() an additional method
> of HTMLAnchorElement that is only available when the user agent knows
> how to send a message for the given URI scheme?

That idea seems *very* sexy to me! But maybe with a twist. It vexes me somewhat that this almost turns sendMessage() into click() + attachments. Either it's not like click() and it's a bit strange to have it on HTMLAnchorElement, or it is in which case it should just be click(). How about putting void addAttachments(Blob[] bigPinkBlobs) on HTMLAnchorElement, it being only available when the scheme is thought to be supported (the UA can rarely be 100% sure, but guessing is possible) and supports attachments?

I like it! I'd also like someone to write a history of the designs of this API :)

>> # DeviceMessaging
>> 
>>    • "The DeviceMessaging object is exposed on the navigator.device"
>> I think we agreed to drop navigator.device and expose everything on
>> navigator (or on whatever else — I don't care).
> 
> Hmm... navigator.sendMessage() seems quite ambitious; I've put it down
> there at this time, but added a note about it being a strawman proposal.

It's a moot point assuming the above.

>>    • I really think that we need a success callback. You may have a
>> UI that depends on the successful transmission of the message (if only
>> to the MUA) and since it's async you can't know what's going on
>> otherwise. Granted, it won't provide much useful information but it's
>> still something.
> 
> I've re-enabled it, but I'm still not sure that most MUA can actually
> report anything useful to the browser; we'll know more about this once
> we see implementations.

Probably also moot assuming the above, I don't know that script can be notified of the traversal of mailto: links (beyond listening to the click event, which won't tell you much).

>>    • One attack vector (which should be documented in the security
>> section) is that you could just keep calling sendMessage to flood the
>> user's device with a zillion message prompts. There should be a
>> TOO_MANY_MESSAGES error for when a UA-dependent rate of messages per
>> minute (I'd put it very low) is reached. Note that we're not
>> introducing a new security issues, just load the following HTML in
>> your browser (at least in Firefox):
>> 
>>    <body onload='while (true) window.location =
>> "mailto:robin@berjon.com"'>
>> 
>> Or, maybe don't do it.
> 
> I haven't added anything on that yet; I wonder if there is something
> already written on pop-up external applications that I could refer to
> instead.

I'm surprised MWBP doesn't have something about that. Most browsers seem to have taken this issue into consideration (but not Firefox) if not interoperably (given the above, WebKits only open the link once, Opera refuses to trigger a mailto onload, I'm too lazy to boot up IE).

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 5 July 2011 12:08:36 UTC