Re: [whatwg] I have feature requests for and tags.

[Glenn Maynard]

On Wed, Nov 16, 2011 at 11:06 PM, crocket  wrote:

> For 1), most users don't know there is such a thing as user's default
> volume.
> Even I don't know where to find that setting in firefox or chrome.
> It seems to be a hidden configuration.
>
> Plus, some audio files are too loud at 100% which is the default volume for
> most users.
> Since uploaders know the proper initial volume, they should be able to set
> the initial volume even without javascript.
>

Authors don't know how loud users want content to be.  If UI isn't
discoverable enough, the solution isn't to make every single author try to
work around it individually by overriding user settings.

Maybe there are valid use cases for exposing a volume attribute, but I
don't think this is one.

-- 
Glenn Maynard

Re: [whatwg] I have feature requests for and tags.

[crocket]

For 1), most users don't know there is such a thing as user's default
volume.
Even I don't know where to find that setting in firefox or chrome.
It seems to be a hidden configuration.

Plus, some audio files are too loud at 100% which is the default volume for
most users.
Since uploaders know the proper initial volume, they should be able to set
the initial volume even without javascript.

For 2), I'll read about  element.

On Wed, Nov 16, 2011 at 10:51 AM, Tab Atkins Jr. wrote:

> On Tue, Nov 15, 2011 at 5:37 PM, crocket  wrote:
> > 1)  and  tags need volume attribute.
> >
> > I know that it's possible to manipulate the volume attribute with
> > javascript.
> > But many internet forums allow some HTML tags but prohibit javascripts.
> >
> > If I was able to set the initial volume with volume attribute of 
> > and  tags, I would be able to set the initial volume without
> > javascript.
>
> You can currently mute the video or play it at the user's default
> volume.  Why do you need to control it beyond that in the markup?
>
>
> > 2)  tag needs subtitle attribute.
> >
> > Without a subtitle attribute, people need to reencode videos with
> subtitles
> > to present the videos with subtitles on the web.
> > I think charset attribute for manually specifying subtitle's character
> set
> > would come in handy also.
>
> Look at the  element, which does precisely this.
>
> ~TJ
>

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Glenn Maynard]

On Wed, Nov 16, 2011 at 6:55 PM, Daniel Cheng  wrote:

> I see. I personally feel it's a little confusing to have two different
> ways to read files in DataTransfer, and now we're adding a third.
>

I don't think that's a good reason not to support this, but that said, it
may be possible to integrate this with DataTransferItem.  Add a third
DataTransferItem kind, "directory" (in addition to "file" and "string"),
whose "drag data item kind" is DirectoryEntry.  Individual files would
continue to be exposed as File.

The main disadvantage (aside from the inconsistency of not using Entry
subclasses for both) is the writable case, where you really do need
FileEntry rather than File.  I'm not sure how interesting the
writable-single-file case is, since there's no way to perform "safe" writes
(you can't create a file next to it, to perform atomic overwrites), and it
only works for modifying existing files (you can't drag in a nonexistant
file).  So, maybe that's not important.

-- 
Glenn Maynard

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Eric U]

On Wed, Nov 16, 2011 at 3:55 PM, Daniel Cheng  wrote:
> On Wed, Nov 16, 2011 at 15:31, Glenn Maynard  wrote:
>
>> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng  wrote:
>>
>>> I'm trying to better understand the use case for DataTransfer.entries.
>>> Using the example you listed in your first post, if I dragged those folders
>>> into a browser, I'd expect to see File objects with the following names in
>>> DataTransfer.files:
>>>     trip/1.jpg
>>>     trip/2.jpg
>>>     trip/3.jpg
>>>     halloween/a.jpg
>>>     halloween/b.jpg
>>>     tokyo/1.jpg
>>>     tokyo/2.jpg
>>> It seems like with that, a web app could implement a progress meter and
>>> handle subdirectories easily while using workers. What does the FileSystem
>>> API provide on top of that?
>>>
>>
>> The issue isn't when you have seven files; it's when you have seven
>> thousand.  File trees can be very large.  In order to implement the above
>> API, you need to traverse the entire tree in advance to discover what files
>> exist.  The DirectoryEntry API lets you traverse the directory explicitly,
>> without having to read the entire tree into memory first, so you don't
>> waste time reading file metadata that you don't care about.
>>
>> For example, you might drag a SVN working copy into a page, which allows
>> viewing logs and other data about the repository.  It might easily contain
>> tens of thousands of files, but you rarely need to enumerate all of them in
>> advance to do useful things with it.
>>
>> (If the trees are on a slow medium, like a DVD drive or a high-latency
>> network drive, even a much smaller number of files can take a long time.)
>>
>> Even when you do want to traverse it all, there are many other advantages:
>> the traversal can be done asynchronously without blocking the page; the
>> page can have a cancel button to abort the operation; the page can show
>> other information about what it's doing (eg. number of new files, number of
>> unrecognized filenames); the page can allow dragging more directories to be
>> queued up for processing without having to wait for the first set to
>> complete; and so on.
>>
>
> I see. I personally feel it's a little confusing to have two different ways
> to read files in DataTransfer, and now we're adding a third.
>
>
>>
>> Also, if a page caches a DirectoryEntry from entries, does that mean it
>>> can continuously poll the DirectoryEntry to see if the contents have
>>> changed to contain something interesting? That seems undesirable.
>>>
>>
>> Nothing needs to be cached.  The DirectoryEntry just represents the
>> directory that was dragged; you don't have to look inside the directory at
>> all until the page uses it.
>>
>
> Let's say I drag my pictures directory to a web app uploader. If this
> uploader passes the DirectoryEntry to my pictures directory to a worker,
> will it be able to read files I create a long time after the original drag?
> It sounds like the approach being advocated would allow that type of attack.

I think it's a bit of an exaggeration to call that an "attack", but
yes, we'll have to make sure we set expectations appropriately.

>>
>>
>> --
>> Glenn Maynard
>>
>>
>>
> Daniel
>

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Eric U]

On Wed, Nov 16, 2011 at 2:33 PM, Daniel Cheng  wrote:
> I'm trying to better understand the use case for DataTransfer.entries.
> Using the example you listed in your first post, if I dragged those folders
> into a browser, I'd expect to see File objects with the following names in
> DataTransfer.files:
>    trip/1.jpg
>    trip/2.jpg
>    trip/3.jpg
>    halloween/a.jpg
>    halloween/b.jpg
>    tokyo/1.jpg
>    tokyo/2.jpg

> It seems like with that, a web app could implement a progress meter and
> handle subdirectories easily while using workers. What does the FileSystem
> API provide on top of that?

There's no chance to set up a progress meter--when you ask for
dataTransfer.files, the browser must give you the whole list.  If it's
lazily-implemented, and the list is long [or comes from a slow network
filesystem, etc.], your script will lock up until the browser finishes
its depth-first search.  If it's eagerly-implemented, that pause will
happen between when the user drops the files and when you get the
event.

What you would see in Kinuko's proposal would depend on what you'd
dragged in.  Kinuko, please correct me if I'm wrong here:

Did you just drag in your entire Photos folder [which happened to
contain 3 subdirs and 7 files]?
Then entries would hold a single DirectoryEntry, representing Photos.

Did you individually select and drag in 3 folders [trip, halloween,
tokyo] which all happened to be in Photos?
Then entries would hold 3 DirectoryEntries, one for each selected folder.

Did you select each of the 7 files?
Then entries would hold 7 FileEntries.

So if you dragged in directories, you could put up a progress meter
while iterating down through them to discover subdirectories and
files.

> Also, if a page caches a DirectoryEntry from entries, does that mean it can
> continuously poll the DirectoryEntry to see if the contents have changed to
> contain something interesting? That seems undesirable.

That remains to be decided.

> Daniel
>
> On Wed, Nov 16, 2011 at 10:21, Glenn Maynard  wrote:
>
>> On Wed, Nov 16, 2011 at 3:42 AM, Jonas Sicking  wrote:
>>
>> > > That requires a full directory traversal in advance to find all of the
>> > > files, though; the tree could be very large.
>> >
>> > You need to do that anyway to implement the .files attribute, no?
>> >
>>
>> .files shouldn't recursively include all files inside directories.  (If you
>> actually select tens of thousands of files and drag them, then yes, but in
>> most cases when you have that many files, they're split into directories
>> and you don't normally drag them individually.)
>>
>>
>> On Wed, Nov 16, 2011 at 9:59 AM, Kinuko Yasuda 
>> wrote:
>>
>> >  The unsandboxed storage and actual data doesn't belong to origin, but
>> > the 'origin-specific' concept can be applied to the filesystem
>> > namespace.
>> >
>> > I haven't thought about workers cases deeply yet, but am thinking that
>> > we should prohibit access to the dropped folders from the other pages
>> > than the one that received the drop event.
>>
>>
>> Access to a file should just be limited by whoever has an Entry object
>> pointing at it.  The Entry object is essentially a token granting access to
>> its associated file(s).
>>
>>
>>
>> > As for the entry URLs I'm planning to make the URLs to the dropped
>> entries
>> > and the filesystem
>> > namespace (that only contains the dropped files) expire when the page
>> > goes away, hoping this would largely simplify the lifetime and
>> > security issues.
>> >
>>
>> I don't think it's possible to do this correctly, because URLs created with
>> toURL have no equivalent to revokeObjectURL.  A long-running page has no
>> way to avoid "leaking" these references until the page exits.  Adding a
>> revoke method for toURL would essentially turn it into URL.createObjectURL.
>>
>> Needing to revoke URLs when dealing with worker communication also makes it
>> very hard for users to get it right.  For example, suppose a Window sends a
>> toURL-generated URL to a Worker.  How do you ensure that the URL is revoked
>> after the worker has received it and finished converting it back to an
>> Entry?  The Worker might be killed (eg. due to CPU quotas) at any time,
>> making avoiding resource leaks very hard.
>>
>> These are just the usual problems with manual resource management, which
>> should be avoided if at all possible.  We already have a mechanism that
>> cleanly avoids all of this, with structured clone and File.
>>
>>  > Off-hand, the main issue that directly affects reading is that most
>> > > non-Windows filesystems can store filenames which can't be represented
>> > by a
>> > > DOMString, such as invalid codepoints (most commonly mismatched
>> > encodings).
>> >
>> > How do they appear in File.name in existing .files approach?
>> >
>>
>> I don't have a Linux browser to check.  I'm guessing it won't inform us
>> much here, since that didn't have to worry about general file access.
>>
>> A naive solution in filesystem approach would

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Daniel Cheng]

On Wed, Nov 16, 2011 at 15:31, Glenn Maynard  wrote:

> On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng  wrote:
>
>> I'm trying to better understand the use case for DataTransfer.entries.
>> Using the example you listed in your first post, if I dragged those folders
>> into a browser, I'd expect to see File objects with the following names in
>> DataTransfer.files:
>> trip/1.jpg
>> trip/2.jpg
>> trip/3.jpg
>> halloween/a.jpg
>> halloween/b.jpg
>> tokyo/1.jpg
>> tokyo/2.jpg
>> It seems like with that, a web app could implement a progress meter and
>> handle subdirectories easily while using workers. What does the FileSystem
>> API provide on top of that?
>>
>
> The issue isn't when you have seven files; it's when you have seven
> thousand.  File trees can be very large.  In order to implement the above
> API, you need to traverse the entire tree in advance to discover what files
> exist.  The DirectoryEntry API lets you traverse the directory explicitly,
> without having to read the entire tree into memory first, so you don't
> waste time reading file metadata that you don't care about.
>
> For example, you might drag a SVN working copy into a page, which allows
> viewing logs and other data about the repository.  It might easily contain
> tens of thousands of files, but you rarely need to enumerate all of them in
> advance to do useful things with it.
>
> (If the trees are on a slow medium, like a DVD drive or a high-latency
> network drive, even a much smaller number of files can take a long time.)
>
> Even when you do want to traverse it all, there are many other advantages:
> the traversal can be done asynchronously without blocking the page; the
> page can have a cancel button to abort the operation; the page can show
> other information about what it's doing (eg. number of new files, number of
> unrecognized filenames); the page can allow dragging more directories to be
> queued up for processing without having to wait for the first set to
> complete; and so on.
>

I see. I personally feel it's a little confusing to have two different ways
to read files in DataTransfer, and now we're adding a third.


>
> Also, if a page caches a DirectoryEntry from entries, does that mean it
>> can continuously poll the DirectoryEntry to see if the contents have
>> changed to contain something interesting? That seems undesirable.
>>
>
> Nothing needs to be cached.  The DirectoryEntry just represents the
> directory that was dragged; you don't have to look inside the directory at
> all until the page uses it.
>

Let's say I drag my pictures directory to a web app uploader. If this
uploader passes the DirectoryEntry to my pictures directory to a worker,
will it be able to read files I create a long time after the original drag?
It sounds like the approach being advocated would allow that type of attack.


>
>
> --
> Glenn Maynard
>
>
>
Daniel

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Glenn Maynard]

On Wed, Nov 16, 2011 at 5:33 PM, Daniel Cheng  wrote:

> I'm trying to better understand the use case for DataTransfer.entries.
> Using the example you listed in your first post, if I dragged those folders
> into a browser, I'd expect to see File objects with the following names in
> DataTransfer.files:
> trip/1.jpg
> trip/2.jpg
> trip/3.jpg
> halloween/a.jpg
> halloween/b.jpg
> tokyo/1.jpg
> tokyo/2.jpg
> It seems like with that, a web app could implement a progress meter and
> handle subdirectories easily while using workers. What does the FileSystem
> API provide on top of that?
>

The issue isn't when you have seven files; it's when you have seven
thousand.  File trees can be very large.  In order to implement the above
API, you need to traverse the entire tree in advance to discover what files
exist.  The DirectoryEntry API lets you traverse the directory explicitly,
without having to read the entire tree into memory first, so you don't
waste time reading file metadata that you don't care about.

For example, you might drag a SVN working copy into a page, which allows
viewing logs and other data about the repository.  It might easily contain
tens of thousands of files, but you rarely need to enumerate all of them in
advance to do useful things with it.

(If the trees are on a slow medium, like a DVD drive or a high-latency
network drive, even a much smaller number of files can take a long time.)

Even when you do want to traverse it all, there are many other advantages:
the traversal can be done asynchronously without blocking the page; the
page can have a cancel button to abort the operation; the page can show
other information about what it's doing (eg. number of new files, number of
unrecognized filenames); the page can allow dragging more directories to be
queued up for processing without having to wait for the first set to
complete; and so on.

Also, if a page caches a DirectoryEntry from entries, does that mean it can
> continuously poll the DirectoryEntry to see if the contents have changed to
> contain something interesting? That seems undesirable.
>

Nothing needs to be cached.  The DirectoryEntry just represents the
directory that was dragged; you don't have to look inside the directory at
all until the page uses it.

-- 
Glenn Maynard

Re: [whatwg] Origin of a data: URL for an img

[Ian Hickson]

On Wed, 16 Nov 2011, Gavin Kistner wrote:
> 
> Can you provide an example in script of when the "found specs" would 
> apply, and when the "other specs" would apply?

Hmm, good point. Now that we're using CORS explicitly, all of the stuff 
about image origins for non-CORS cases doesn't really apply any more. I 
should strip those other entries.

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

Re: [whatwg] Origin of a data: URL for an img

[Gavin Kistner]

From: Ian Hickson [mailto:i...@hixie.ch] 
> On Wed, 16 Nov 2011, Gavin Kistner wrote:
> > Section 6.3 "Origin" of the HTML Living Standard has this text (excerpted):
> > 
> > > For images:
> > >
> > > If an image was generated from a data: URL found in another Document 
> > > or in a script The origin is the origin of the Document or script that 
> > > loaded that image.
> > >
> > > If an image was obtained in some other manner (e.g. a data: URL 
> > > typed in by the user) The origin is a globally unique identifier assigned 
> > > when the image is created.
> > 
> > I'm going to refer to the first case above as the "found specs" and 
> > the second case as the "other specs". (Aside: it would be convenient 
> > for discussion if items in this section would have unique identifying 
> > numbers.)
> > 
> > What does "found" mean?
> > What is the difference between these two cases?
> > When do we switch from one case to the other?
[snip]
> > Does a JavaScript String object carry an origin along with it, but any 
> > mutation (and all new strings) switch to "other specs"?
>
> In all three cases here, the image was generated from a URL found in the 
> src="" content attribute of the  element created by the script. The 
> image data is CORS-same-origin, and so the entry that applies in the origin 
> section is:
>
>  If an image is the image of an img element and its image data is  
> CORS-same-origin
>
>  The origin is the origin of the img element's Document.

OK, that does help, though mostly to illustrate that all of my guesses were all 
wrong. :) 

Can you provide an example in script of when the "found specs" would apply, and 
when the "other specs" would apply?
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---

Re: [whatwg] Origin of a data: URL for an img

[Ian Hickson]

On Wed, 16 Nov 2011, Gavin Kistner wrote:
> Section 6.3 "Origin" of the HTML Living Standard has this text (excerpted):
> 
> > For images:
> >
> > If an image was generated from a data: URL found in another Document or in 
> > a script
> > The origin is the origin of the Document or script that loaded that image.
> >
> > If an image was obtained in some other manner (e.g. a data: URL typed in by 
> > the user)
> > The origin is a globally unique identifier assigned when the image is 
> > created.
> 
> I'm going to refer to the first case above as the "found specs" and the 
> second case as the "other specs". (Aside: it would be convenient for 
> discussion if items in this section would have unique identifying numbers.)
> 
> What does "found" mean?
> What is the difference between these two cases?
> When do we switch from one case to the other?
> 
> Here are some of my guesses:
> 
> var img = new Image;
> var iframe = document.querySelector('iframe#samedomain').contentWindow;
> img.src = iframe.globalStringWithDataURI; // "other specs"?
> img.src = iframe.document.querySelector('img#hasdatauri'); // "found 
> specs"?
> img.src = img.src.replace( '0', '1' ); // "other specs"?
> 
> Does a JavaScript String object carry an origin along with it, but any 
> mutation (and all new strings) switch to "other specs"?

In all three cases here, the image was generated from a URL found in the 
src="" content attribute of the  element created by the script. The 
image data is CORS-same-origin, and so the entry that applies in the 
origin section is:

 If an image is the image of an img element and its image data is 
 CORS-same-origin

 The origin is the origin of the img element's Document.

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

Re: [whatwg] HTML5 video seeking

[Ralph Giles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/11/11 10:32 AM, Aaron Colwell wrote:

> Yeah it looks to me like starting at the requested position is the
> only option. I saw the text about media engine triggered seeks, but
> it seems like users would be very surprised to see the seeking &
> seeked events for the seek they requested immediately followed by a
> pair of events to a location they didn't request. I can envision
> the angry bug reports now. ;)

Yeah, it's definitely bending the rules. If you only intended to
support seeking to the nearest keyframe, setting media.seekable would
be an honest way to advertise that, but also violates least surprise.

> Thanks for the response. Looks like we are interpreting the text
> the same way.

Yes, my recollection of the earlier discussion aligns with your
summary and Chris Double's. It's expensive, but what one naively
expects the API to do.

Video splicing/mixing was a use case we wanted to support, and such
applications aren't really possible without frame-accurate seeking.
Thus, it's better to require it up front and possibly allow
applications to relax it later, as with Frank and Philip's 'strict'
attribute, than to disallow such applications by leaving this to
implementation variance.

 -r

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOxDrhAAoJEEcAD3uxRB3vHT4H/0DfMChkHztMwqO0FEkJql3u
BYU8B0ZFxQ/rllU9qdTdu+ioYRvIriFP9UFbeO+sO85Qy5Jaz9u9soKWE8siIHMP
rWWxOVQbbZMbbLcrtgbNreePwyRX6P1fdTTpxjUUnl0g/mVajE+5BohaVwsc/dSK
mr0S53a49od3675dNQQaycLbSAEI8eaVvG5saOyOfN41GK+ctEtnfro7Z0cUZhzZ
A0C3P+/Jr+fKOZPocpJ4RPPWbkzCeO8BZOblRgrHynTpHYs20OTBbvW3TMZuT6Np
hnwVclFwye1hgqYjAR83PezVAz/9rPKsox96+VQc/in7fne2H5drKIMW0ADd+hM=
=r1zI
-END PGP SIGNATURE-

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Daniel Cheng]

I'm trying to better understand the use case for DataTransfer.entries.
Using the example you listed in your first post, if I dragged those folders
into a browser, I'd expect to see File objects with the following names in
DataTransfer.files:
trip/1.jpg
trip/2.jpg
trip/3.jpg
halloween/a.jpg
halloween/b.jpg
tokyo/1.jpg
tokyo/2.jpg
It seems like with that, a web app could implement a progress meter and
handle subdirectories easily while using workers. What does the FileSystem
API provide on top of that?

Also, if a page caches a DirectoryEntry from entries, does that mean it can
continuously poll the DirectoryEntry to see if the contents have changed to
contain something interesting? That seems undesirable.

Daniel

On Wed, Nov 16, 2011 at 10:21, Glenn Maynard  wrote:

> On Wed, Nov 16, 2011 at 3:42 AM, Jonas Sicking  wrote:
>
> > > That requires a full directory traversal in advance to find all of the
> > > files, though; the tree could be very large.
> >
> > You need to do that anyway to implement the .files attribute, no?
> >
>
> .files shouldn't recursively include all files inside directories.  (If you
> actually select tens of thousands of files and drag them, then yes, but in
> most cases when you have that many files, they're split into directories
> and you don't normally drag them individually.)
>
>
> On Wed, Nov 16, 2011 at 9:59 AM, Kinuko Yasuda 
> wrote:
>
> >  The unsandboxed storage and actual data doesn't belong to origin, but
> > the 'origin-specific' concept can be applied to the filesystem
> > namespace.
> >
> > I haven't thought about workers cases deeply yet, but am thinking that
> > we should prohibit access to the dropped folders from the other pages
> > than the one that received the drop event.
>
>
> Access to a file should just be limited by whoever has an Entry object
> pointing at it.  The Entry object is essentially a token granting access to
> its associated file(s).
>
>
>
> > As for the entry URLs I'm planning to make the URLs to the dropped
> entries
> > and the filesystem
> > namespace (that only contains the dropped files) expire when the page
> > goes away, hoping this would largely simplify the lifetime and
> > security issues.
> >
>
> I don't think it's possible to do this correctly, because URLs created with
> toURL have no equivalent to revokeObjectURL.  A long-running page has no
> way to avoid "leaking" these references until the page exits.  Adding a
> revoke method for toURL would essentially turn it into URL.createObjectURL.
>
> Needing to revoke URLs when dealing with worker communication also makes it
> very hard for users to get it right.  For example, suppose a Window sends a
> toURL-generated URL to a Worker.  How do you ensure that the URL is revoked
> after the worker has received it and finished converting it back to an
> Entry?  The Worker might be killed (eg. due to CPU quotas) at any time,
> making avoiding resource leaks very hard.
>
> These are just the usual problems with manual resource management, which
> should be avoided if at all possible.  We already have a mechanism that
> cleanly avoids all of this, with structured clone and File.
>
>  > Off-hand, the main issue that directly affects reading is that most
> > > non-Windows filesystems can store filenames which can't be represented
> > by a
> > > DOMString, such as invalid codepoints (most commonly mismatched
> > encodings).
> >
> > How do they appear in File.name in existing .files approach?
> >
>
> I don't have a Linux browser to check.  I'm guessing it won't inform us
> much here, since that didn't have to worry about general file access.
>
> A naive solution in filesystem approach would be silently ignoring
> > such files (probably bad) or having in-memory path mapping (would be
> > slightly better).  For limited read-only drag-and-drop cases we
> > wouldn't need to think about remapping and the mapping could just go
> > away when the page goes away, so hopefully implementing such mapping
> > wouldn't be that hard.
> >
>
> There are probably some cases that we'll just have to accept will never
> work perfectly, and design with that in mind.
>
> To take a common case, suppose a script does the following, a commonplace
> method for safe file overwriting (relatively; the needed flush operations
> don't exist here):
>
> 1. Create a file with the name filename + ".new".
> 2. Write the new file contents to the file.
> 3. Rename filename + ".new" to filename, overwriting the original file.
>
> This is a useful case: it's real-world--I've done this countless times--and
> it's a case where unrepresentable filenames affects both reading and
> writing, plus the auxiliary operation of renaming.
>
> I suppose the mapping approach could work here.  Associate the mapping with
> the DirectoryEntry containing it, from invalid filenames to generated
> filenames.  Then, if the invalid filename is "X", and the DOMString mapping
> is "MAPPING1", then this would first create the literal

[whatwg] Origin of a data: URL for an img

[Gavin Kistner]

Section 6.3 "Origin" of the HTML Living Standard has this text (excerpted):

> For images:
>
> If an image was generated from a data: URL found in another Document or in a 
> script
> The origin is the origin of the Document or script that loaded that image.
>
> If an image was obtained in some other manner (e.g. a data: URL typed in by 
> the user)
> The origin is a globally unique identifier assigned when the image is created.

I'm going to refer to the first case above as the "found specs" and the second 
case as the "other specs". (Aside: it would be convenient for discussion if 
items in this section would have unique identifying numbers.)

What does "found" mean?
What is the difference between these two cases?
When do we switch from one case to the other?

Here are some of my guesses:

var img = new Image;
var iframe = document.querySelector('iframe#samedomain').contentWindow;
img.src = iframe.globalStringWithDataURI; // "other specs"?
img.src = iframe.document.querySelector('img#hasdatauri'); // "found specs"?
img.src = img.src.replace( '0', '1' ); // "other specs"?

Does a JavaScript String object carry an origin along with it, but any mutation 
(and all new strings) switch to "other specs"?


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---

Re: [whatwg] Stacked Fullscreen

[Robert O'Callahan]

On Thu, Nov 17, 2011 at 3:41 AM, Anne van Kesteren  wrote:

> On Wed, 26 Oct 2011 04:06:28 +0200, Robert O'Callahan <
> rob...@ocallahan.org> wrote:
>
>> I'm not comfortable with punting the nested-fullscreen cases. It means
>> that if you have a document with an embedded video with fullscreen controls,
>> fullscreening the video works fine when the document is not fullscreen,
>> but if you make the document fullscreen, fullscreening the video just
>> doesn't
>> work anymore. That seems broken (especially if native media fullscreen
>> controls are implemented this way). Authors can work around it, when
>> everything's same-origin, but the workarounds are tricky and require all
>> scripts to cooperate.
>>
>
> I implemented your suggestion.
>
> http://dvcs.w3.org/hg/**fullscreen/raw-file/tip/**Overview.html
>
> I have limited it for now to descendants only (either elements (for
> consistency) or browsing contexts (for simplicity)).
>
> Events are also dispatched only on Document now since Document is what you
> need to observe anyway for changes.
>

Thanks!

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]

Re: [whatwg] Fullscreen CSS

[Robert O'Callahan]

On Thu, Nov 17, 2011 at 8:20 AM, Edward O'Connor  wrote:

> It seems like we shouldn't assume that these are the only two features
> that will ever need this sort of rendering support. I'll get a www-style
> thread going.
>

Thanks. If multiple specs (or even multiple running instances of the same
spec) try to define "a stacking context that is above all other stacking
contexts", we'll have a problem :-).

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]

Re: [whatwg] Fullscreen CSS

[Edward O'Connor]

>>> Hm, why would it require stacking-level changes?  One obvious way to
>>> get it to act "correctly" is to make it wrap around the element, like
>>> the old ::outside pseudo-element proposal.  Then it's trivial.
>> 
>> The CP says "The dialog and its cover, taken together, are siblings within a
>> new stacking context which is placed above all other stacking contexts."
>> This seems like something new in CSS.
> 
> Oh, whoops, indeed.  Sorry about that, I forgot the CP worked like
> that.  Yeah, I guess we *would* need some changes to the stacking
> algorithm. :/  Some thought needs to go into how much of this should
> be expressed in author-usable CSS and how much should be "magic".

It seems like we shouldn't assume that these are the only two features that 
will ever need this sort of rendering support. I'll get a www-style thread 
going.


Ted

Re: [whatwg] HTML5 video seeking

[Frank Galligan]

Here is another link where Ian mentions that the seek should be the exact
frame.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017225.html
 This came up from 2 years ago, where I wanted to add an optional "strict"
parameter to the seek call, which would default to false. Exactly the same
as what Philip suggested. I'm all for it.

I think Chrome added frame accurate seeking in version 7.

Frank


On Tue, Nov 15, 2011 at 10:37 PM, Chris Double wrote:

> On Wed, Nov 16, 2011 at 7:19 AM, Aaron Colwell 
> wrote:
> > I'm just trying to
> > determine if we are intentionally requiring frame accurate seeking at
> this
> > point or am I just misinterpreting some part of the spec.
>
> My understanding from the discussion at the time was that it was
> intentionally requiring frame accurate seeking and this is what
> Mozilla ended up implementing in Firefox as a result.
>
> Chris.
> --
> http://www.bluishcoder.co.nz
>

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Glenn Maynard]

On Wed, Nov 16, 2011 at 3:42 AM, Jonas Sicking  wrote:

> > That requires a full directory traversal in advance to find all of the
> > files, though; the tree could be very large.
>
> You need to do that anyway to implement the .files attribute, no?
>

.files shouldn't recursively include all files inside directories.  (If you
actually select tens of thousands of files and drag them, then yes, but in
most cases when you have that many files, they're split into directories
and you don't normally drag them individually.)


On Wed, Nov 16, 2011 at 9:59 AM, Kinuko Yasuda  wrote:

>  The unsandboxed storage and actual data doesn't belong to origin, but
> the 'origin-specific' concept can be applied to the filesystem
> namespace.
>
> I haven't thought about workers cases deeply yet, but am thinking that
> we should prohibit access to the dropped folders from the other pages
> than the one that received the drop event.


Access to a file should just be limited by whoever has an Entry object
pointing at it.  The Entry object is essentially a token granting access to
its associated file(s).



> As for the entry URLs I'm planning to make the URLs to the dropped entries
> and the filesystem
> namespace (that only contains the dropped files) expire when the page
> goes away, hoping this would largely simplify the lifetime and
> security issues.
>

I don't think it's possible to do this correctly, because URLs created with
toURL have no equivalent to revokeObjectURL.  A long-running page has no
way to avoid "leaking" these references until the page exits.  Adding a
revoke method for toURL would essentially turn it into URL.createObjectURL.

Needing to revoke URLs when dealing with worker communication also makes it
very hard for users to get it right.  For example, suppose a Window sends a
toURL-generated URL to a Worker.  How do you ensure that the URL is revoked
after the worker has received it and finished converting it back to an
Entry?  The Worker might be killed (eg. due to CPU quotas) at any time,
making avoiding resource leaks very hard.

These are just the usual problems with manual resource management, which
should be avoided if at all possible.  We already have a mechanism that
cleanly avoids all of this, with structured clone and File.

 > Off-hand, the main issue that directly affects reading is that most
> > non-Windows filesystems can store filenames which can't be represented
> by a
> > DOMString, such as invalid codepoints (most commonly mismatched
> encodings).
>
> How do they appear in File.name in existing .files approach?
>

I don't have a Linux browser to check.  I'm guessing it won't inform us
much here, since that didn't have to worry about general file access.

A naive solution in filesystem approach would be silently ignoring
> such files (probably bad) or having in-memory path mapping (would be
> slightly better).  For limited read-only drag-and-drop cases we
> wouldn't need to think about remapping and the mapping could just go
> away when the page goes away, so hopefully implementing such mapping
> wouldn't be that hard.
>

There are probably some cases that we'll just have to accept will never
work perfectly, and design with that in mind.

To take a common case, suppose a script does the following, a commonplace
method for safe file overwriting (relatively; the needed flush operations
don't exist here):

1. Create a file with the name filename + ".new".
2. Write the new file contents to the file.
3. Rename filename + ".new" to filename, overwriting the original file.

This is a useful case: it's real-world--I've done this countless times--and
it's a case where unrepresentable filenames affects both reading and
writing, plus the auxiliary operation of renaming.

I suppose the mapping approach could work here.  Associate the mapping with
the DirectoryEntry containing it, from invalid filenames to generated
filenames.  Then, if the invalid filename is "X", and the DOMString mapping
is "MAPPING1", then this would first create the literal filename
"MAPPING1.new", followed by renaming it to the original "invalid" filename
"X".

(In particular, though, I think it should not be possible to create *new*
garbage filenames on people's systems, that didn't exist to begin with.
That is, it should map to the filenames that really exist, not just string
escaping.)

This is complex, though, and leads to new questions, like how long the
mappings last if the underlying file is deleted.  As a data point, note
that most Windows applications are unable to access files whose filenames
can't be represented in the current ANSI codepage.  That is, if you're on a
US English system, you can't access filenames with Japanese in them.
(Unicode applications can, but tons of applications in Windows aren't
Unicode; Windows has never made it simple to support Unicode.)  If users
find that reasonable, it might not be worth all this for the even rarer
case of illegal codepoints in Linux.

Yup, writing side would have toughe

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Eric U]

On Tue, Nov 15, 2011 at 9:16 PM, Glenn Maynard  wrote:
> On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda  wrote:
>>
>> Good point, we could do this synchronously in workers!
>> I think we already have one way to convert Entry to EntrySync:
>> we can get a URL from Entry (Entry.toURL()), send the URL to
>> the worker and get the EntrySync via resolveLocalFileSystemSyncURL.
>>
>> http://www.w3.org/TR/file-system-api/#widl-Entry-toURL
>
> That might be tricky, since toURL looks designed with origin-specific
> sandboxed storage in mind.  Files and directories supplied in this way is
> outside of the sandbox; that makes securely creating persistent, un-expiring
> URLs for arbitrary files a lot harder.
>
> Note that there's another (unrelated) issue: there are unsolved issues with
> filenames when giving access to unsandboxed storage.  They're not
> unsolvable, they've just been punted on so far.  It's been worked around so
> far by splitting apart the rules for sandboxed filesystems from those for
> unsandboxed filesystems, so sandboxed filesystems (those that don't actually
> store filenames on real files) can use simple, interoperable rules that
> wouldn't work for unsandboxed access to real files.
>
> Off-hand, the main issue that directly affects reading is that most
> non-Windows filesystems can store filenames which can't be represented by a
> DOMString, such as invalid codepoints (most commonly mismatched encodings).
> There are more issues with writing: each platform has its own length
> limitations on both filenames and full path lengths; they're not always even
> in the same units, with Linux in bytes and Windows in UTF-16 codepoints; and
> Windows filenames are case-folding (in practice).
>
> The writing issues might be ignorable to implement reading, but they're all
> related issues so it's probably good to try to look at them as a whole.
> (+CC Eric)

Yup; I'm paying attention to those issues.  In previous drafts of the
spec, we handled reading of awkward paths [barring some handling of
invalid code points, where one could enumerate/read files, but perhaps
not really read their exact names], but restricted writing.  I expect
we'll do something similar when we get around to the write cases.  We
can either restrict path creation to what's valid UTF-8, or we could
allow users to try to create arbitrary paths using ArrayBuffers of
bytes.  At any rate, I don't think we're doing anything here that
would limit our options in the future.

> --
> Glenn Maynard
>
>

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Eric U]

On Tue, Nov 15, 2011 at 6:06 PM, Glenn Maynard  wrote:
> On Tue, Nov 15, 2011 at 8:38 PM, Kinuko Yasuda  wrote:
>
>> The async nature of DirectoryEntry makes the code longer,
>> but webapps can work on the files incrementally and can show
>> progress UI while enumerating.  For the apps that may deal with
>> potentially huge folders providing such a scalable (but slightly
>> more cumbersome) way sounds reasonable to me.
>>
>
> Entry (and subclasses) should also be supported by structured clone.  That
> would allow passing a DirectoryEntry received from file inputs to be passed
> to a worker.  This is something for later, of course, but combined with an
> API to convert between Entry and EntrySync (and DE/DESync), this would
> allow using the much more convenient sync API in a worker, even if the only
> way to retrieve the Entry in the first place is in the UI thread.

As Kinuko mentions, toURL obviates the need for structured clone for Entry.
I'd rather not add support for that if we can avoid it, and this seems
like an acceptable workaround.

While the URL format for non-sandboxed files has yet to be worked out,
I think we need toURL to work no matter where the file comes from.
It's already the case that an Entry can expire if the underlying file
is deleted or moved; I think it's OK for the URL to expire under
similar circumstances.  In the case of a drag, we can just say that it
expires when either the page goes away or the underlying file does
[analogous to the expiry of the data in a normal drag event, I think,
which should last as long as the page does].

> I think this is a better solution to the inconvenience of async APIs than
> falling back to exposing unscalable sync interfaces in the main thread.
> This is one of the reasons we have workers.
>
> --
> Glenn Maynard
>

Re: [whatwg] createContextualFragment in detached contexts

[Henri Sivonen]

On Fri, Sep 30, 2011 at 7:56 PM, Erik Arvidsson  wrote:
> On Fri, Sep 30, 2011 at 07:35, Henri Sivonen  wrote:
>> On Fri, Sep 30, 2011 at 1:37 AM, Erik Arvidsson  wrote:
>>> If the context object is in a detached state, then relax the parsing
>>> rules so that all elements are allowed at that level. The hand wavy
>>> explanation is that for every tag at the top level create a new
>>> element in the same way that ownerDocument.createElement would do it.
>>
>> I would prefer not to add a new magic mode to the parsing algorithm
>> that'd differ from what innerHTML requires.
>
> So you want every js library to have to do this kind of work around
> instead?

This topic has migrated to public-webapps. My current thinking is
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0818.html

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Kinuko Yasuda]

On Wed, Nov 16, 2011 at 5:42 PM, Jonas Sicking  wrote:
> On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard  wrote:
>> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking  wrote:
>>>
>>> Adding FileEntry/DirectoryEntry seems confusing since those are
>>> generally writable in the FileSystem API spec, right? Additionally,
>>> DirectoryEntry is asynchronous, which makes enumerating the tree more
>>> painful.
>>>
>>> The way we were planning on exposing this in Gecko is to simply set
>>> File.name to the full relative path to the folder dropped. So in the
>>> example above, if the user dropped the "Photos" folder from the
>>> example above on a page, we'd make .files return a list of 7 Files,
>>> with names like "Photos/trip/1.jpg", "Photos/trip/2.jpg",
>>> "Photos/trip/3.jpg", "Photos/halloween/a.jpg", etc.
>>
>> That requires a full directory traversal in advance to find all of the
>> files, though; the tree could be very large.  For example, a sharded
>> directory tree containing hundreds of thousands of files with individual
>> frames of a video isn't unheard of, and there's no need to read it all in
>> advance.  Directory trees with tens of thousands of photos, audio clips,
>> emails (Maildir), etc. aren't uncommon, either.
>>
>> DirectoryEntry's asynchronous API seems to have the same advantages here as
>> they do for regular filesystem access.  It would also set the stage for
>> exposing writable directories down the line (eg. drag an input and output
>> directory for file processing), after the security issues are figured out.
>
> You need to do that anyway to implement the .files attribute, no?

Yes, but even we provide the attribute today it wouldn't give the best
user experience or could be broken with some likely scenarios.

If we could think of better option I think we should make it available.

> / Jonas
>

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Kinuko Yasuda]

On Wed, Nov 16, 2011 at 2:16 PM, Glenn Maynard  wrote:
> On Tue, Nov 15, 2011 at 10:58 PM, Kinuko Yasuda  wrote:
>> Good point, we could do this synchronously in workers!
>> I think we already have one way to convert Entry to EntrySync:
>> we can get a URL from Entry (Entry.toURL()), send the URL to
>> the worker and get the EntrySync via resolveLocalFileSystemSyncURL.
>>
>> http://www.w3.org/TR/file-system-api/#widl-Entry-toURL
>
> That might be tricky, since toURL looks designed with origin-specific
> sandboxed storage in mind.  Files and directories supplied in this way is
> outside of the sandbox; that makes securely creating persistent, un-expiring
> URLs for arbitrary files a lot harder.

The unsandboxed storage and actual data doesn't belong to origin, but
the 'origin-specific' concept can be applied to the filesystem
namespace.

I haven't thought about workers cases deeply yet, but am thinking that
we should prohibit access to the dropped folders from the other pages
than the one that received the drop event.  As for the entry URLs I'm
planning to make the URLs to the dropped entries and the filesystem
namespace (that only contains the dropped files) expire when the page
goes away, hoping this would largely simplify the lifetime and
security issues.

> Note that there's another (unrelated) issue: there are unsolved issues with
> filenames when giving access to unsandboxed storage.  They're not
> unsolvable, they've just been punted on so far.  It's been worked around so
> far by splitting apart the rules for sandboxed filesystems from those for
> unsandboxed filesystems, so sandboxed filesystems (those that don't actually
> store filenames on real files) can use simple, interoperable rules that
> wouldn't work for unsandboxed access to real files.
>
> Off-hand, the main issue that directly affects reading is that most
> non-Windows filesystems can store filenames which can't be represented by a
> DOMString, such as invalid codepoints (most commonly mismatched encodings).

How do they appear in File.name in existing .files approach?

A naive solution in filesystem approach would be silently ignoring
such files (probably bad) or having in-memory path mapping (would be
slightly better).  For limited read-only drag-and-drop cases we
wouldn't need to think about remapping and the mapping could just go
away when the page goes away, so hopefully implementing such mapping
wouldn't be that hard.

> There are more issues with writing: each platform has its own length
> limitations on both filenames and full path lengths; they're not always even
> in the same units, with Linux in bytes and Windows in UTF-16 codepoints; and
> Windows filenames are case-folding (in practice).
>
> The writing issues might be ignorable to implement reading, but they're all
> related issues so it's probably good to try to look at them as a whole.
> (+CC Eric)

Yup, writing side would have tougher issues, and that's why I started
this proposal only with read-only scenarios.  (I agree that it'd be
good to give another thought about unsandboxed writing cases though)

> --
> Glenn Maynard
>
>

[whatwg] Stacked Fullscreen

[Anne van Kesteren]

On Wed, 26 Oct 2011 04:06:28 +0200, Robert O'Callahan  
 wrote:
I'm not comfortable with punting the nested-fullscreen cases. It means  
that if you have a document with an embedded video with fullscreen  
controls,
fullscreening the video works fine when the document is not fullscreen,  
but if you make the document fullscreen, fullscreening the video just  
doesn't

work anymore. That seems broken (especially if native media fullscreen
controls are implemented this way). Authors can work around it, when
everything's same-origin, but the workarounds are tricky and require all
scripts to cooperate.


I implemented your suggestion.

http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html

I have limited it for now to descendants only (either elements (for  
consistency) or browsing contexts (for simplicity)).


Events are also dispatched only on Document now since Document is what you  
need to observe anyway for changes.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Jonas Sicking]

On Tue, Nov 15, 2011 at 3:02 PM, Glenn Maynard  wrote:
> On Tue, Nov 15, 2011 at 5:21 PM, Jonas Sicking  wrote:
>>
>> Adding FileEntry/DirectoryEntry seems confusing since those are
>> generally writable in the FileSystem API spec, right? Additionally,
>> DirectoryEntry is asynchronous, which makes enumerating the tree more
>> painful.
>>
>> The way we were planning on exposing this in Gecko is to simply set
>> File.name to the full relative path to the folder dropped. So in the
>> example above, if the user dropped the "Photos" folder from the
>> example above on a page, we'd make .files return a list of 7 Files,
>> with names like "Photos/trip/1.jpg", "Photos/trip/2.jpg",
>> "Photos/trip/3.jpg", "Photos/halloween/a.jpg", etc.
>
> That requires a full directory traversal in advance to find all of the
> files, though; the tree could be very large.  For example, a sharded
> directory tree containing hundreds of thousands of files with individual
> frames of a video isn't unheard of, and there's no need to read it all in
> advance.  Directory trees with tens of thousands of photos, audio clips,
> emails (Maildir), etc. aren't uncommon, either.
>
> DirectoryEntry's asynchronous API seems to have the same advantages here as
> they do for regular filesystem access.  It would also set the stage for
> exposing writable directories down the line (eg. drag an input and output
> directory for file processing), after the security issues are figured out.

You need to do that anyway to implement the .files attribute, no?

/ Jonas