Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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 this issue May 19, 2018 · 9 comments · May be fixed by #154
Open

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

guest271314 opened this issue May 19, 2018 · 9 comments · May be fixed by #154

Comments

@guest271314
Copy link

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
Copy link
Author

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

@guest271314
Copy link
Author

Is the behaviour of Chromium a bug?

@mkruisselbrink
Copy link
Collaborator

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
Copy link
Collaborator

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

@guest271314
Copy link
Author

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
Copy link
Collaborator

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 annevk mentioned this issue May 29, 2018
Open
@annevk
Copy link
Member

annevk commented Jan 9, 2020

Is this different from #75?

@guest271314
Copy link
Author

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

mkruisselbrink added a commit that referenced this issue May 21, 2020
@mkruisselbrink
Rewrite a lot of the internals of Blobs to make reading more explicit.
40f442d 
This redefines how blobs work by adding internal slots and hooks to
support Blob objects backed by various sources of data. By doing so this
tries to make more explicit how various edge cases behave, as well as
making it clear that blobs are immutable.

This fixes #75, fixes #99, and fixes #47.
It also lays the ground work to address w3c/webappsec-clear-site-date#49.

This also fixes #71.
@mkruisselbrink mkruisselbrink linked a pull request May 21, 2020 that will close this issue
Open
4 tasks
mkruisselbrink added a commit that referenced this issue May 21, 2020
@mkruisselbrink
Rewrite a lot of the internals of Blobs to make reading more explicit.
030d980 
This redefines how blobs work by adding internal slots and hooks to
support Blob objects backed by various sources of data. By doing so this
tries to make more explicit how various edge cases behave, as well as
making it clear that blobs are immutable.

This fixes #75, fixes #99, and fixes #47.
It also lays the ground work to address w3c/webappsec-clear-site-date#49.

This also fixes #71.
@guest271314
Copy link
Author

@mkruisselbrink

I consider the chromium behavior a bug, yes.

Could this bug, ironically, be used in Native File System to fix WICG/file-system-access#157?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Rewrite a lot of the internals of Blobs to make reading more explicit. w3c/FileAPI
3 participants
@mkruisselbrink @annevk @guest271314