w3c / fileapi Goto Github PK

The origin of a Blob URL
must be the same as the origin specified by the incumbent settings object at the time the method that created it was called.

This is stated as a normative statement, implying to me that blob URL's have some special origin that must be set at creation time.

However, the origin of a blob URL is instead normatively determined via the URL Standard. So this is just a statement of fact about what happens to be true according to the below algorithm, which is what creates blob URLs.

So it should be changed to a statement of fact, instead of a "must":

The origin of a Blob URL will be the same as the origin specified by the incumbent settings object at the time the method that created it was called.

Furthermore, this would be much clearer if instead of defining the new term "origin of a Blob URL", it just linked the first "origin" in this sentence to https://url.spec.whatwg.org/#concept-url-origin

This is not an issue, but would be nice to have it defined in the spec.
It seems to me that the 2 blobs (the original one and the cloned one) have 2 independent states.

The following code:

a = new Blob([1,2,3], {type: "text/(plain"});
console.log(a.type) // prints text/(plain

works in Chrome and Firefox. It also works if you replace ( with \x02 or something

The spec, however, asks user agents to restrict values in the range U+0020 to U+007E in the constructor, and in the getter it only allows a nonempty value to be returned if it is a parseable MIME type.

Perhaps we should relax these restrictions in the spec?

Stats in Chrome: https://www.chromestatus.com/metrics/feature/timeline/popularity/814

Hovering around 0.0008% which is low. But an HTTPArchive search turned up thousands of uses; spot-checking, it's not just one library but several different uses. The method is implemented in Edge, FF, Chrome and Safari.

So... is it worth continuing to try and drop it from implementations, or should we just accept it as a wart on FileReader, document, and move on?

(As an aside, cribbing text() and arrayBuffer() from Body to Blob would be awesome...)

Split out from https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 :

The

<input type="file" name="something" />

element has always been readonly (you can't change value) for security purposes.
That makes sense as a string could always be manipulated by JS.

The File object on the other hand should be "safe", as in

• Only the browser can create one on user request (ie. by file input or drag and drop)
• JS cannot change it in any way

So it should not be a security issue to allow assignment to a file input.
For example:

<input type="file" name="something[]" onchange="splitFiles();" id="in1" multiple="multiple" />

function splitFiles() {
  var in = document.getElementById('in1');
  //create single inputs
  for(var i=0;i<in.files.length;i++) {
        var newEl = document.createElement('input');
        newEl.name = "something[]";
        newEl.id = '...';
        newEl.type = "file";
        newEl.value = in.files[i]; // <-- assignment of file object
        document.appendChild(newEl); //add for upload
        //create some UI to remove this input
        //...
    }
    //remove the multi-input
    in.parent.removeChild(in);
}

This code would split a multi-file-input back to multiple single-file inputs (that way applications with a legacy backend that only supports the classical way could also support multi-file-inputs).

Another use would be with File objects obtained by drag and drop.
Right now those require XHR to upload. Allowing to make them a selection of a file input could simplify some situations as well as provide richer UI (when showing a traditional file input together with a drop area those would stay in sync).

This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24586 which I'm migrating over. Currently, FileList is an interface in WebIDL; this bug is to make it a FrozenArray. Some other discussions (including the Directory Upload discussion) will affect this bug.

The example in the introduction attaches event handlers after calling readAsText which might lead to anything from missed progress events to missing all events.

See JakeChampion/fetch#353

This issue is to fix Blob URL's origin, based largely on bugs filed on HTML.

Currently, File API has this:

"The origin of a Blob URL must be the same as the effective script origin specified by the incumbent settings object at the time the method that created it -- either URL.createObjectURL or URL.createFor -- was called."

This should be much better.

A common practice when the gh-pages (branch) is used, is to name the main file "index.html". Unless there's a good reason to keep with "Overview.html", please use "index.html" instead.

Currently, the spec has (boring parts omitted):

[Constructor, Constructor(sequence<...> blobParts, optional BlobPropertyBag options)] 
interface Blob {

It would probably be better to use

[Constructor(optional sequence<...> blobParts, optional BlobPropertyBag options)] 
interface Blob {

Note that this handles

new Blob(undefined)

differently: the current spec throws a TypeError; after the change, it would be equivalent to new Blob().

CC @bzbarsky

It appears that in certain instances the FileAPI is not recognizing the MIME type for .msg (Microsoft Outlook) files. This is a worldwide standard no different from a .jpg or .png file so why would it not be recognized. Specifically we are using the RadAsyncUpload control from Telerik which I understand is built upon the File API but the content type (Mime Type) for those files is not being passed back via the control presumably because the FileAPI is not recognizing it. Added the Mime type to local registry or IIS server has no effect. Please provide guidance and/or fix.

We should do this in the Blob constructor. Per Jonas Sicking, something like this:

"new Blob([myArrayBuffer], { transfer: [myArrayBuffer] });
and
new File([otherBuffer], "myFile", { transfer: [otherBuffer] });"

would work quite well I think.

This might syntactically resemble transferList from postMessage.

Is the length computable, is there a total and a current length, or are the values all supposed to be false and zero?

This would make it easier to hop from the repository to the rendered spec.

Update: See https://gist.github.com/petkaantonov/37a9c64ea2bbd1aa3ca5

Currently blob urls don't persist between browser restarts / page refreshes etc so the user has to add same files to the app over and over again everytime the app is started.

For certain kinds of apps it is necessary to be able to create a persistent blob url. For instance a media player app that has access to the media files the user has added to the app so they don't have to keep readding the files (possibly thousands) every time the app is started. Duplicating copies of the files in FileSystem or IndexedDB is out of the question as this duplicates possibly gigabytes of data which takes a long time, wastes a lot of storage and hits limits quickly.

Reading

I suggest a method like URL.createPersistentObjectUrl is added. The url is valid as long as the original file exists in exactly same location with exactly same attributes and contents as they were when the URL was created. When the file is modified, moved or altered in any way, the url should become invalid (perhaps URL.isPersistentUrlValid can be used to check it?). This can be probably done just by checking the last modified attribute.

Writing

One could also be allowed to write to a valid persistent object urls by sending binary data as a POST request to the url. However, every time such a POST request is made, the browser should prompt the user for confirmation that "the app wants to modify the flie at [path], is this ok?". Also such requests should probably only be allowed to made in response to user event like click. After successful write, the browser should update the persistent object url to match the new file attributes and contents that were updated.

Security considerations

As far as I can see, this should not give the app access to any more information than existing APIs already give.

See whatwg/html#929 for details.

Hi. I have several HTML5 apps I work on, all of which allow users to save files locally. I can't seem to figure out how to control the URL so the users aren't downloading files with gibberish names, or how to force the browser to open a Save As dialog.

Anyway, any help would be greatly appreciated.

It is intended to create a new Blob URL, and then says

Let O be the Blob URL’s origin.

before there even is a Blob URL.

Would it make sense to clarify the relationship with https://tools.ietf.org/html/draft-kerwin-file-scheme? it seems that there is some overlap in scope. But even if there isn't, making that explicit might help people to better understand the relationship of those two documents.

In the definition for the type attribute, the spec has:

The ASCII-encoded string in lower case representing the media type of the Blob. On getting, user agents must return the type of a Blob as an ASCII-encoded string in lower case, such that when it is converted to a byte sequence, it is a parsable MIME type [MIMESNIFF], or the empty string -- 0 bytes -- if the type cannot be determined.

There's a fair bit weird about that paragraph (e.g. 'ASCII-encoded' when the entry points which set the type already reject non-ASCII input, referring to the length of the string in bytes...). But neither Chrome nor Firefox appear to do the filtering of non-parsable MIME types:

new Blob(['yo'], {type: "te?xt/plain"}).type; // "te?xt/plain"

Even if we decide to keep the spec and file/fix implementation bugs, can we rejigger the spec so that the entry points that set type (constructors, slice()) do all of the filtering work, rather than spreading it across two parts of the spec? (Unless there's subtlety I'm missing...)

cc: @annevk @Ms2ger

In my fork, I'm converting the spec to the Bikeshed processor. The current generated file is pretty inaccurate in several places - it's clear that the ToC has drifted from the actual sections over time, for example.

• Initial conversion pass
• Fix link failures (properly linking to out-of-document things)
• Fix relevant Bikeshed bugs (uncovered during conversion of DOM)

Just letting y'all know, so you don't spend too much time working directly on the index.html file, or putting the effort into ReSpeccing it. I expect this to be finished in a week, as some of the bugs the DOM conversion uncovered (which this spec is also hitting) require some decent refactoring work I'll be doing over the next several days.

Right now, the File includes a long long lastModified. Is there any possibility of adding creation and last access times as well?

Migrating my own request https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 :

Currently a FileList provided by a file input element is readonly.

This is problematic if the user added multiple files to a file list and then sees that he included one file too much and want's to remove it before uploading the files. Right now he has to start his selection from scratch.

If there was a way to drop items from a FileList some JavaScript could display a list of selected files and allow to remove items one-by-one.

Duplicate https://www.w3.org/Bugs/Public/show_bug.cgi?id=16834 adds another use case:

• Checking the file.size for some limit before uploading, if limit is exceeded exclude the particular file from uploading.

#24 discusses an alternative approach, fitting a wider range of use cases.

https://encoding.spec.whatwg.org/#utf-8-encode. Referencing the UTF-8 encoding directly is not great.

This was added in 5cd3dda, allegedly in response to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23147. Neither Chrome nor Gecko seems to implement it.

Not defined what happens with b in

a = new Blob(...)
b = new Blob([a])
a.close()

Probably it should not be closed.

We need to define how this affects other specifications such as FormData, XMLHttpRequest, etc.

If blob.close() revokes URLs it needs to be defined how that happens. Are the URLs stored on the instance?

https://jsfiddle.net/422r7n3z/ - exercises new Blob([s], {endings:e}).size

On Windows, in Chrome/Firefox:
transparent + "abc\r\n" = 5
transparent + "abc\n" = 4
transparent + "abc\r" = 4
native + "abc\r\n" = 5
native + "abc\n" = 5
native + "abc\r" = 5

On Windows, in IE11:
transparent + "abc\r\n" = 5
transparent + "abc\n" = 4
transparent + "abc\r" = 4
native + "abc\r\n" = 5
native + "abc\n" = 4
native + "abc\r" = 4

On OSX and Linux, in Chrome/Firefox/Safari:
transparent + "abc\r\n" = 5
transparent + "abc\n" = 4
transparent + "abc\r" = 4
native + "abc\r\n" = 4
native + "abc\n" = 4
native + "abc\r" = 4

(I have not tested Opera or Edge; I assume those match Chrome and IE11)

Note that all 4 browsers - including IE which does not appear to respect the option otherwise - throw if an invalid option is passed as endings.

I gathered usage stats in Chrome stable: https://www.chromestatus.com/metrics/feature/timeline/popularity/1320 - it's 0% to several significant figures (people running web-platform-tests would account for the absolute #s).

Should we proceed with removing, or does anyone want to advocate for keeping it? @smaug----, @foolip, @aliams, .... ?

From simonp:

FilePropertyBag can inherit from BlobPropertyBag (and remove type from FilePropertyBag).

Minor IDL tweak that should have no effect on observable behavior I think.

Now that Jonas has left Mozilla the editors info needs updating.

Per w3c/mediacapture-main#404 it's not implemented everywhere and the blob URL concept is not great anyway so we should get rid of this. Let's improve what we have, but not add more baggage.

URLs are typically ASCII in final form. Creating URLs that are not ASCII in final form is bad news and would require ugly decoding and such.

Service worker by its nature doesn't want to initiate any sync requests within its context. It'll be nice if it's explicitly defined in FileReaderSync interface: [Exposed=DedicatedWorker,SharedWorker].

The corresponding service worker issue: w3c/ServiceWorker#735.

As this standard creates a new URL scheme (blob:), it ought to include an "IANA Considerations" section for registering the scheme with IANA.
RFC 7595 explains the registration form and process. See also https://tools.ietf.org/html/rfc5226#section-5

Replace Exposed=Window,Worker with Exposed=(Window,Worker)

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

It is used in https://w3c.github.io/FileAPI/#file for the fileName argument in the constructor. It has however been removed from the Web IDL spec:
whatwg/webidl@e2cf800

Perhaps USVString would work, that's what it already is in Gecko:
https://github.com/mozilla/gecko-dev/blob/9d30f59efd1f82cfa80633c43834b7f08a9c77e1/dom/webidl/File.webidl

The link checker complained that the link to RFC2119 "http://www.ietf.org/rfc/rfc2119" results in a redirect loop, that can be fixed by a HTTP Secure URI "https://www.ietf.org/rfc/rfc2119".

This would do the WTF-16 -> Unicode conversion automatically.

Once whatwg/html#727 lands the HTML Standard will contain a monkey patch that should move here.

See https://bugzilla.mozilla.org/show_bug.cgi?id=660148 for details.

It seems, that file select dialog called by INPUT tag with type "file" is not working, because in current browser solutions this functionality cannot be invoked by code properly. The current default behaviour of this tag type is secured by explicit user clicking.

I would appreciate to get file select functions in this api, maybe a fileselect object to set all properties of fileselect dialog (type open/save, filename, mimes, flags (multiselect/single select) and so on and a show function.

DOMError is gone from https://dom.spec.whatwg.org/ and we're looking to get rid of it in Blink:
https://code.google.com/p/chromium/issues/detail?id=460725

CC @annevk (DOM) and @inexorabletash (IndexedDB has a similar situation)

The spec points to [email protected] as the place to provide feedback. This should now point to Github issues instead.

https://html.spec.whatwg.org/multipage/browsers.html#unicode-serialisation-of-an-origin

In particular the way the description of the result attribute sort of defines how the result of a read operation is represented is sub-optimal. Some more explicit steps to transform the body returned by the read operation to the various types might make sense.

For example, what should this do:

var b = new Blob(undefined, { type: "foo" });

? Should b.type be empty string or "foo"? In any case, there is no concept of "number of parameters" for IDL implementation algorithms, so please define the behavior in terms of concepts that do exist.

(This discussion could go here or HTML — which notes "Extensions tend to be ambiguous..." — but I'm guessing the right eyeballs will be here.)

When a File is minted via a drop operation or HTMLInputElement in Chrome, the content type is determined using platform-specific logic. e.g. on Windows the registry is used as is normal for the platform. There's also a small fallback list built into the browser. This causes behavior to differ for the same version of Chrome on the same OS depending on what applications are installed (e.g. .DOCX may be unknown if Office is not installed). Presumably this is also an interop issue across browsers on the same machine if different logic/lists are used is used.

Web applications should trust neither extensions nor content types. But should we attempt to standardize the behavior here in any way, e.g. an expected list of extension → type mappings, to avoid developer surprise?

I'm not strongly advocating for this, just wanted to kick off the discussion.

Large Blob/Files becomes an issue if you don't slice it into chunks...

Streams brings other cool feature like pipe-ing, back pressure & transforming
Currently I'm using Response (part of Fetch) to transform a blob to a stream that i can "read into" step by step

var stream = new Response(blob).body
var reader = stream.getReader()

This works okey. but it feels hacky.
Could we get new method to get a stream from File & Blob's please?

See whatwg/html#1430 for background.

Currently it seems that the spec allows to create a new blob starting from a closed one:

var a = new Blob([42]);
a.close();
var b = new Blob([a]);

This seems wrong to me because a.size is 0 and that blob cannot be read in any way.
I would suggest to throw an exception.