You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Does the specification define input[type=file] .files expected behaviour to relevant to reflecting real-time changes to user selected file? #99
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.
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?
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.
@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.
Activity
guest271314 commentedon May 19, 2018
plnkr to demonstrate the behaviour. Have not tried the code at MacOS or Windows.
guest271314 commentedon May 19, 2018
Is the behaviour of Chromium a bug?
mkruisselbrink commentedon May 19, 2018
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 commentedon May 19, 2018
(https://crbug.com/818327 and https://crbug.com/710190 are the bugs tracking this issue)
guest271314 commentedon May 19, 2018
Filed https://bugs.chromium.org/p/chromium/issues/detail?id=844874 before notification of above links which state
when visited.
mkruisselbrink commentedon May 19, 2018
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 commentedon Jan 9, 2020
Is this different from #75?
guest271314 commentedon Jan 9, 2020
@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.
Rewrite a lot of the internals of Blobs to make reading more explicit.
Rewrite a lot of the internals of Blobs to make reading more explicit.
guest271314 commentedon Jul 25, 2020
@mkruisselbrink
Could this bug, ironically, be used in Native File System to fix WICG/file-system-access#157?