Re: [request] "Download" Event for HTMLAnchorElement

[Si Robertson]

Allowing users to save/download a runtime-generated file with the use of
object URLs and the anchor download attribute is the only viable way of
doing things at the moment. Bouncing the file through a server isn't
acceptable for web applications that are supposed to act like native apps.

Ideally, the File API would provide a way for users to save a file, and I'm
surprised this is still an issue. Writing a file to a user selected
location is no less secure than allowing a user to download a file with an
anchor.

// Si

Re: [request] "Download" Event for HTMLAnchorElement

[Glenn Maynard]

(Can you turn off the Outlook-style indentation quoting?  It makes the
archives unreadable:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0738.html,
and doesn't mix well with regular quoting.)

On Mon, Mar 24, 2014 at 5:24 PM, Brian Matthews (brmatthe) <
brmat...@cisco.com> wrote:

>  But I do care about the user clicking more than once. I know I do that
> occasionally, and would be annoyed at a site that wouldn't let me, and I
> don't want to annoy my users in that way. Presumably in that case I want
> the URL and blob to stay around until the page goes away, which I'd guess
> is how it would work?
>

Right, if you want the link to be reusable, then you can't revoke the blob
URL.  Even if the download completes, the user might still click it again.

FileSaver avoids the need for blob URLs entirely, but never got much
momentum.  It might not really solve this problem anyway, since you'd still
need to have a synchronous reference to the Blob for it to work.  If you
had to do an async request in onclick to create the Blob before you could
start the FileSaver, browsers would probably treat it as an unsolicited
popup and disallow it anyway.
http://dev.w3.org/2009/dap/file-system/file-writer.html#the-filesaver-interface

If you're actually generating a large blob of data and allowing the user to
save it to disk (for example, gunzipping a 500 MB file and saving the
uncompressed file to disk), neither of these are very good, since they both
mean writing the big data to a Blob first (probably going to disk), then
copying that to the user file when he saves it.  I haven't been following
the stream API much, but I assume this is something it would help address.

-- 
Glenn Maynard

Re: [request] "Download" Event for HTMLAnchorElement

[Brian Matthews (brmatthe)]

On 3/24/14 1:16 PM, "Glenn Maynard" mailto:gl...@zewt.org>> 
wrote:
On Mon, Mar 24, 2014 at 2:45 PM, Si Robertson 
mailto:retromodu...@gmail.com>> wrote:
The web browser will definitely know when the data has been written to disk, 
the problem is the developer won't know when the data has been written to disk, 
so it's currently impossible to revoke the object URL (release the data from 
memory) at a safe time. When the anchor is clicked you could create a timer and 
revoke the object URL after a certain number of seconds have elapsed but you 
will still be taking a shot in dark.

If you don't care about the user clicking the link more than once, it should 
always be safe to release the object URL immediately after the click event has 
completed.  If the browser has begun downloading (copying to disk) the blob, 
that operation should be unaffected by you releasing the object URL.  You would 
just need to use a zero-second timer, so that you release it after the click 
event has completed and not while it's being dispatched.

(If you do something like this, be sure to hide the download link and at least 
replace it with a "Download in progress", or better a "Click here to restart 
download" to regenerate the blob, so you don't leave a broken anchor on the 
page.)

This may not  work in browsers yet, and this may not be well-defined in the 
spec.  If it's not, I'm guessing it'll be fixed as part of 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338.

But I do care about the user clicking more than once. I know I do that 
occasionally, and would be annoyed at a site that wouldn't let me, and I don't 
want to annoy my users in that way. Presumably in that case I want the URL and 
blob to stay around until the page goes away, which I'd guess is how it would 
work?

Brian

Re: Browser search API

[Mitar]

Hi!

Great! No problem then. I was just unsure. Don't yet know how things
go here. I completely understand that there is a lot of work.

Thanks


Mitar

On Thu, Mar 13, 2014 at 10:44 AM, Tab Atkins Jr.  wrote:
> On Thu, Mar 13, 2014 at 8:17 AM, Marcos Caceres  wrote:
>> On March 12, 2014 at 7:16:53 PM, Mitar (mmi...@gmail.com) wrote:
>>> There was no reply. :-(
>>
>> It usually takes a bit of time for Hixie to get around to all the emails 
>> (the volume of email on the WHATWG list + other priorities slow things down 
>> - but I’ve never seen him not respond to a proposal). Give him a few more 
>> weeks. If you don’t hear back by the end of the month you can try to ping 
>> him directly.
>
> Yes, Hixie's delay is usually a few months, unless it happens to be
> swept up as part of something earlier in the queue that he's dealing
> with, or someone asks him to prioritize.  Don't worry, it'll get taken
> care of.
>
> ~TJ



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

Re: [request] "Download" Event for HTMLAnchorElement

[Glenn Maynard]

On Mon, Mar 24, 2014 at 2:45 PM, Si Robertson 
 wrote:

> If a developer creates an object URL, e.g. theFile =
> URL.createObjectURL(theData), then it's the developer's responsibility to
> revoke that object URL. Assigning theFile to an anchor href so the data
> can be downloaded doesn't create a copy of data.
>

Requiring the user to revoke blob URLs is manual resource management, which
is inherently brittle in JS.  The eventual solution should be auto-revoke
URLs, which makes it the browser's job to revoke the URL.  We should make
that work fully, not add more events to allow manual revocation.

Autorevoke URLs are in, but the mechanism for the browser to see "a.href =
myAutoRevokeObjectURL" and keep the URL alive correctly is still being
worked on (https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765).

That said:

On Mon, Mar 24, 2014 at 2:45 PM, Si Robertson wrote:

> The web browser will definitely know when the data has been written to
> disk, the problem is the developer won't know when the data has been
> written to disk, so it's currently impossible to revoke the object URL
> (release the data from memory) at a safe time. When the anchor is clicked
> you could create a timer and revoke the object URL after a certain number
> of seconds have elapsed but you will still be taking a shot in dark.
>

If you don't care about the user clicking the link more than once, it
should always be safe to release the object URL immediately after the click
event has completed.  If the browser has begun downloading (copying to
disk) the blob, that operation should be unaffected by you releasing the
object URL.  You would just need to use a zero-second timer, so that you
release it after the click event has completed and not while it's being
dispatched.

(If you do something like this, be sure to hide the download link and at
least replace it with a "Download in progress", or better a "Click here to
restart download" to regenerate the blob, so you don't leave a broken
anchor on the page.)

This may not  work in browsers yet, and this may not be well-defined in the
spec.  If it's not, I'm guessing it'll be fixed as part of
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338.

-- 
Glenn Maynard

Re: [request] "Download" Event for HTMLAnchorElement

[Si Robertson]

If a developer creates an object URL, e.g. theFile =
URL.createObjectURL(theData), then it's the developer's responsibility to
revoke that object URL. Assigning theFile to an anchor href so the data can
be downloaded doesn't create a copy of data.

The web browser will definitely know when the data has been written to
disk, the problem is the developer won't know when the data has been
written to disk, so it's currently impossible to revoke the object URL
(release the data from memory) at a safe time. When the anchor is clicked
you could create a timer and revoke the object URL after a certain number
of seconds have elapsed but you will still be taking a shot in dark.

Ideally we need to be able to do something like this ...

anchor.ondownload = function(e) {
  URL.revokeObjectURL(theFile);
}

A simplified example of course, but it demonstrates what's needed.

// Si




On 24 March 2014 18:51, Brian Matthews (brmatthe) wrote:

> On 3/23/14 5:30 PM, "Si Robertson"  wrote:
>
>
> >Hi guys,
> >
> >This mailing list was suggested to me by one of the Chromium developers,
> >so I apologize in advance if this mailing list is not appropriate for
> >this request/proposal.
> >
> >In a nutshell, I am asking for a "download" event to be dispatched from
> >anchor elements that support the "download" attribute.
> >
> > >ondownload="release(this)">download
> >
> >The problem that this new event would solve is this - when using a
> >temporary object URL (blob) for the file data, e.g. programmatically
> >generated content, there is currently no way of knowing when that file
> >data has been written to disk, therefore there
> > is no reliable way of knowing when it is safe to revoke the object URL
> >in order to release resources.
> >
> >Thanks for your time.
> >
> >Regards,
> >Si Robertson
>
>
> Is the download generating a temporary copy of the blob to do the
> download? If so, it seems it should be up to the browser to handle
> cleaning it up, not the developer. If referring to the blob referenced by
> the href, won't releasing it after the first download prevent it from
> being downloaded again? Maybe an edge case, but not one I would want to
> preclude. Also, if the browser doesn't know when the file's been
> downloaded, how does it know when to fire the ondownload event?
>
> Probably newby questions, but I'm working on some code that does exactly
> this, programmatically generates anchors referencing programmatically
> generated blobs, so I want to understand how they're handled and what
> requirements are put on me to make sure things are cleaned up as
> necessary.
>
> Thanks,
> Brian
>
>

[Bug 25142] New: [Custom]: Missing created callback should not prevent other callbacks from being enqueued.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25142

Bug ID: 25142
   Summary: [Custom]: Missing created callback should not prevent
other callbacks from being enqueued.
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
   URL: http://w3c.github.io/webcomponents/spec/custom/#types-
of-callbacks
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: wc...@mozilla.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14968

In the description of the created callback the spec currently says:

"All other callbacks must not be enqueued until after the created callback's
invocation had started."

It's not very clear what should happen when there is no created callback
transferred from the prototype. The way it's currently worded, there is no
callback to invoke and no other callbacks would be enqueued. This seems like
the wrong behavior to me.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Push API register - vendor specific details

[Jonas Sicking]

If we can automate and standardize the server-side registration
procedure then potentially we could use have an API which signals
"please do server side registration at this URL". The server side
registration would then return the identifier that could be passed to
push.register(). This way end-to-end registration can be fully
automated.

On one had, if both ends of registration can be fully automated, then
doesn't that defeat the purpose of the registration (which as I
understand it is to enable blocking spammers). On the other hand, I'm
guessing Google already uses a fully automated registration procedure?

/ Jonas


On Mon, Mar 24, 2014 at 6:57 AM, Michael van Ouwerkerk
 wrote:
> Jonas, your suggestions have a good point. I don't yet see a way around
> having a sender id or push id though. I'll keep looking for a way to reduce
> proprietary pieces in the API. But for the moment, the Push API as it is
> seems hard to implement without proprietary extensions to it.
>
> Thanks for your detailed reply.
>
> /m
>
>
>
> On Thu, Mar 20, 2014 at 7:35 PM, Jonas Sicking  wrote:
>>
>> 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: [request] "Download" Event for HTMLAnchorElement

[Brian Matthews (brmatthe)]

On 3/23/14 5:30 PM, "Si Robertson"  wrote:


>Hi guys,
>
>This mailing list was suggested to me by one of the Chromium developers,
>so I apologize in advance if this mailing list is not appropriate for
>this request/proposal.
>
>In a nutshell, I am asking for a "download" event to be dispatched from
>anchor elements that support the "download" attribute.
>
>ondownload="release(this)">download
>
>The problem that this new event would solve is this - when using a
>temporary object URL (blob) for the file data, e.g. programmatically
>generated content, there is currently no way of knowing when that file
>data has been written to disk, therefore there
> is no reliable way of knowing when it is safe to revoke the object URL
>in order to release resources.
>
>Thanks for your time.
>
>Regards,
>Si Robertson


Is the download generating a temporary copy of the blob to do the
download? If so, it seems it should be up to the browser to handle
cleaning it up, not the developer. If referring to the blob referenced by
the href, won't releasing it after the first download prevent it from
being downloaded again? Maybe an edge case, but not one I would want to
preclude. Also, if the browser doesn't know when the file's been
downloaded, how does it know when to fire the ondownload event?

Probably newby questions, but I'm working on some code that does exactly
this, programmatically generates anchors referencing programmatically
generated blobs, so I want to understand how they're handled and what
requirements are put on me to make sure things are cleaned up as
necessary. 

Thanks,
Brian

Re: [gamepad] Haptic Feedback/Controller Vibration

[Patrick Martin]

I agree that it would be simpler to extend the vibration API but
oftentimes controllers' rumble packs do a lot more than just vibrate
at one frequency or intensity, using the web audio api would allow
people to take advantage of that, you could play the low-end sound
from your game through the rumble pack, so that the user feels the
explosion they are hearing in the game etc. As for how the motor
selection would work in a web audio API implementation, it would
select the motors based on the pitch and amplitude of the signal, and
the speed from just the pitch, but it may not be the best way of doing
this, I simply noticed there was very little on this topic, so I came
up with a few Ideas.

On 3/23/14, Brandon Jones  wrote:
> Mozilla has played around with gamepad vibration a bit already:
> https://bugzilla.mozilla.org/show_bug.cgi?id=680289
> There's been some mixed messages, but so far the basic idea seems to be to
> either extend the existing Vibration
> APIto handle
> multiple motors (and presumably associate it back to a specific
> pad) or to add a very similar looking "vibrate" function to the gamepad
> API. Something like:
>
> vibrate(int motorIndex, float intensity);
>
> Personally I think that there's got to be a little more to it than that.
> For one, you'll want to be able to query not only how many motors a device
> has but have a way of expressing what type of feedback that motor provides
> (is it a heavy motor, etc.) and possibly some description of it's locality
> (The Xbox One controller has motors in each trigger, and the Steam
> controller has motors under each touchpad.) I have no idea how to concisely
> and robustly communicate that information. This also assumes that the
> device has simple X-Input style feedback, not the more complicated joystick
> force feedback that was all the rage in the 90s. (Which is far more
> complicated and fairly dead, so I doubt it's worth addressing at all.)
>
> As for controller speakers, I see the argument that it's a type of
> controller feedback, but I don't think it should be conflated with
> controller vibration. I see them as two very distinct features. It *is* an
> interesting feature to consider on it's own, though.
>
>
>
> On Sun, Mar 23, 2014 at 11:19 AM, Patrick Martin
> > wrote:
>
>> Hello,
>>
>> Is there a reason that haptic feedback support is missing from the
>> gamepad
>> api? I feel that this would prevent developers from fully utilizing
>> modern
>> gamepads which nearly always include some form of a haptic feedback
>> mechanism, (from the speaker on the wiimote to the dual vibrators in an
>> xbox 360 controller). In order for this to work however, we need a
>> mechanism for detecting supported "haptic feedback modes" which could
>> then
>> be used on the gamepad with the WebAudio API.
>>
>> Here is an example of one such mechanism:
>>
>> var ctx = new AudioContext();
>> var rumble_audio = document.getElementById("rumbleAudio");
>> var rumble_audio_source = ctx.createMediaElementSource(rumble_audio)
>> var modes = gamepad.getSupportedFeedbackModes();
>> var feedback_node = null;
>> if (typeof(modes.RUMBLE_STEREO) !== "undefined"){ // like the xbox 360
>> feedback_node = gamepad.getFeedbackNode(ctx,modes.RUMBLE_STEREO);
>> }else if(typeof(modes.RUMBLE_MONO) !=="undefined"){ // like some pc
>> gamepads
>> feedback_node = gamepad.getFeedbackNode(ctx,modes.RUMBLE_MONO);
>> }else if(typeof(modes.GAMEPAD_AUDIO)){ // like the wii remote
>> feedback_node = gamepad.getFeedbackNode(ctx,modes.GAMEPAD_AUDIO);
>> }else{
>> feedback_node = ctx.destination
>> }
>> rumble_audio_source.connect(feedback_node);
>> rumble_audio.play();
>>
>> A system like this would allow both greater access to the controller's
>> functionality and allow feedback to be dynamically generated or modified
>> by
>> the WebAudio API.
>>
>>
>> I hope this suggestion helps,
>> Patrick Martin
>>
>

[Bug 25139] New: [Custom]: Bogus createElement/createElementNS IDL

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25139

Bug ID: 25139
   Summary: [Custom]: Bogus createElement/createElementNS IDL
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: bzbar...@mit.edu
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, mrb...@gmail.com, public-webapps@w3.org,
wc...@mozilla.com
Blocks: 14968

http://w3c.github.io/webcomponents/spec/custom/#extensions-to-document-interface-to-instantiate
says:

  partial interface Document {
Element createElement(DOMString localName, optional DOMString
typeExtension);
Element createElementNS(DOMString? namespace, DOMString qualifiedName,
optional DOMString typeExtension);
  };

This will fail in a conformant WebIDL implementation, because for example it
creates two overloads of createElement:

  [NewObject] Element createElement(DOMString localName);
  Element createElement(DOMString localName, optional DOMString typeExtension);

but WebIDL says:

  If there is more than one entry in an effective overload set that has a given
  type list length, then for those entries there MUST be an index i such that
for
  each pair of entries the types at index i are distinguishable.

and in this case the overload set for type list length == 1 has two entries
which are identical.

In practice, Gecko instead has this IDL:

 partial interface Document {
   [NewObject]
   Element createElement(DOMString localName, DOMString typeExtension);
   [NewObject]
   Element createElementNS(DOMString? namespace, DOMString qualifiedName,
DOMString typeExtension);
 };

(note lack of "optional", which is key); I'm sorry that we didn't provide
feedback on this when we implemented something different from the spec.

That said Blink's IDL here is:

[CustomElementCallbacks, PerWorldBindings,
ActivityLogging=ForIsolatedWorlds, RaisesException] Element
createElement(DOMString localName, [TreatNullAs=NullString] DOMString
typeExtension);

which also has a non-optional typeExtension

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Push API register - vendor specific details

[Anne van Kesteren]

On Thu, Mar 20, 2014 at 3:19 PM, Michael van Ouwerkerk
 wrote:
> This means that if the Push API is implemented around these systems, vendor
> specific registration details must be provided.

It seems terrible if we take the existing constraints of those push
backends. If developers had to register their site with each of them
to get a working solution. And then if you came along with a new piece
of hardware with a different push backend you'd have to convince the
long tail of web sites to upgrade to adapt to your backend. That does
not work.

The proposal the draft has today where browser hands out a URL for you
to ping from your server after the user has consented seems fairly
sane. It would be great to hear what the problems are with that
approach from Google et al.

The web is a distributed platform, we should not tie its APIs around a
couple of vendors that are relevant today.


-- 
http://annevankesteren.nl/

Re: Push API register - vendor specific details

[Michael van Ouwerkerk]

Jonas, your suggestions have a good point. I don't yet see a way around
having a sender id or push id though. I'll keep looking for a way to reduce
proprietary pieces in the API. But for the moment, the Push API as it is
seems hard to implement without proprietary extensions to it.

Thanks for your detailed reply.

/m



On Thu, Mar 20, 2014 at 7:35 PM, Jonas Sicking  wrote:

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

[Bug 21066] Provide an event path API

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21066

Anne  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM |Component Model
   Assignee|ann...@annevk.nl|dglaz...@chromium.org

--- Comment #43 from Anne  ---
Let's get the patch in the Shadow DOM specification fixed first before
considering how to integrate this into DOM.

-- 
You are receiving this mail because:
You are on the CC list for the bug.