Skip to content

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

Open

Description

@guest271314

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?

Activity

  1. guest271314 commented on May 19, 2018

    @guest271314
    Author

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

  2. guest271314 commented on May 19, 2018

    @guest271314
    Author

    Is the behaviour of Chromium a bug?

  3. mkruisselbrink commented on May 19, 2018

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

  4. mkruisselbrink commented on May 19, 2018

    @mkruisselbrink
    Collaborator

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

  5. guest271314 commented on May 19, 2018

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

  6. mkruisselbrink commented on May 19, 2018

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

  7. annevk commented on Jan 9, 2020

    @annevk
    Member

    Is this different from #75?

  8. guest271314 commented on Jan 9, 2020

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

  9. added 2 commits that reference this issue on May 21, 2020
    40f442d
    030d980
  10. guest271314 commented on Jul 25, 2020

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions