search

w3c / FileAPI

File API
https://w3c.github.io/FileAPI/
Other
104 stars 44 forks source link

Does the specification define input[type=file] .files expected behaviour to relevant to reflecting real-time changes to user selected file? #99

Open guest271314 opened 6 years ago

guest271314 commented 6 years ago

Consider the HTML and JavaScript posted at this Stack Overflow question Input file size and content do not update on macOS

HTML 

<!DOCTYPE html>
<input type="file" id="file" />
<p id="info"></p>

JavaScript

window.addEventListener('load', function() {
  window.setInterval(function() {
    var logFile = document.querySelector('#file').files[0];
    if (logFile) {
      document.querySelector('#info').innerHTML = '<br/>' +
        (new Date()).toString() + '<br/>Last modified: ' +
        logFile.lastModified +
        '<br/>Size: ' +
        logFile.size;
    }
  }, 1000);
});

Reproduce steps as described by OP of the question

Please test with following snippet. Select a file (for example a text file), see last modified timestamp and file size, then change file and look again, if size has changed. On macOS the file size doesn't change.

Using a sample file, for example, https://gist.github.com/guest271314/11edc4566ba94f204dd46e6ae26edaad#file-d134213ba9465cb74dfd36cde47bf102638c4a9f3aca357f79ee747dd5f49f1e0f0de , which contains the text

123

Behaviour

Chromium 65

Once the local file is selected by user action and the local file is changed at a text editor, for example, by typing 4 following the existing 123 at the file (for example, the above linked gist) both lastModified and size properties are reflected as being changed client side, indicating changes to local file are being updated in real time though the user has not performed the affirmative action of re-selecting the file.

Firefox Trunk (60)

Once the local file is selected by user action and the local file is changed at a text editor, for example, by typing 4 following the existing 123 at the file (for example, the above linked gist) both lastModified and size properties are not reflected as being changed client side, indicating changes to local file are being not updated in real time where the user has not performed the affirmative action of re-selecting the file.

What does the specification define as the expected behaviour of size and lastModified properties of a File object within a FileList object where changes to an underlying local file are made after user selection of a local file?

guest271314 commented 6 years ago

plnkr to demonstrate the behaviour. Have not tried the code at MacOS or Windows.

guest271314 commented 6 years ago

Is the behaviour of Chromium a bug?

mkruisselbrink commented 6 years ago

I consider the chromium behavior a bug, yes. File/Blob objects are supposed to be immutable (the whole snapshot state concept in the spec), although it isn't specified very well. I've been trying to fix the chromium behavior, but there's a lot of technical debt in that area so I haven't made much progress yet (but some semi-related refactorings we've been doing will make it easier to fix this properly).

I'm also planning on cleaning up this part of the spec to make it more obvious what the expected behavior is.

mkruisselbrink commented 6 years ago

(https://crbug.com/818327 and https://crbug.com/710190 are the bugs tracking this issue)

guest271314 commented 6 years ago

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=844874 before notification of above links which state

You do not have permission to view the requested page.

Reason: User is not allowed to view this issue

when visited.

mkruisselbrink commented 6 years ago

Yeah, the other two bugs are marked as security issue since arguably being able to read file changes could be considered a security issue...

annevk commented 4 years ago

Is this different from #75?

guest271314 commented 4 years ago

@annevk #75 appears to be a general concern about mutating state of Blob/File objects.

Further, this issue does not go as far as it could by testing shell code that mutates the the contents of the file on disk (where applicable https://stackoverflow.com/a/56419176). A barage of tests would probably be necessary to verify if the conceivable ways (e.g., following read $ cd ~/.config/[chrome, chromium]/Default/File\ System/[three digits]/[lowercase letter]/[two digits] (https://stackoverflow.com/a/36098618)) a Blob/File object can be mutated are (no longer) possible, which have not yet sketched a draft for the prospective tests yet, or performed.

Am not sure if this is a duplicate. This issue presents a concrete case with details where that mutation was/is possible.

guest271314 commented 4 years ago

@mkruisselbrink

I consider the chromium behavior a bug, yes.

Could this bug, ironically, be used in Native File System to fix https://github.com/WICG/native-file-system/issues/157?