Define WebKit's underlying file changes behavior

[annevk]

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

[bakulf]

If the underlying file size changes, we must be sure that we maintain the run-to-completion semantics.
This means that file.size == file.size must always be true.

Plus, if the underlying file changes, maybe also the type changes. Should file.type changes too? The same is for its name.

If we really want to support this feature, I suggest to introduce a 'changed' event and, only when triggered, the DOM File attributes should be updated.

[mkruisselbrink]

If I understand this issue it is more about better defining what happens if the snapshot state of a blob/file no longer matches the file on disk, rather than trying to actually support files that change. I.e. the spec currently sort of hand-wavily describes that attempting to read such a blob should throw a NotReadableError, but that isn't actually reflected in the reading algorithms.

Not sure if changing attributes of the File/Blob objects themselves makes sense... Unfortunately there are cases in blink were currently we don't really deal with snapshot states correctly, and can have file.size change from under you, but I would consider all of those things bugs.

Not sure if I'm a fan of introducing "changed" events either... I like the conceptual simplicity of a Blob/File object being immutable. Sure, reading might fail because the snapshot state became invalid, but otherwise a blob/file always represents the same data as it did when it was first created.

[saschanaz]

Just started looking at this. Per my latest observation:

1. file.text() on all of Gecko, Blink, and WebKit clips the returned string by the initial file size when the file size changes.
2. file.text() on Blink and WebKit rejects when the timestamp changes. It does not on Gecko.
3. fileReader.readAsBinaryString() on Gecko fires an error event when the file size changes. It does not care about the timestamp.
4. fileReader.readAsBinaryString() on Blink and WebKit fires an error when the timestamp changes. If the size changes, it clips the returned string.
5. file.size never changes in all browsers.
6. file.lastModified never changes in Gecko and Blink. WebKit seemingly just reports the current time, ignoring the actual data?

[inexorabletash]

Thanks for the analysis!

What are your thoughts on aligning with the most common behavior, where there's divergence? (Which I think happens to be Blink's behavior, but I swear that's coincidence not bias!)

[saschanaz]

Yeah, the Blink behavior makes the most sense to me too. The Gecko way doesn't work when the content changes while keeping the size. The Blink/WebKit way still allows modification when the timestamp doesn't change, but I guess we can safely assume that such files are actively pretending as if no change happened.

(When the timestamp changes and then rolls back to the initial timestamp, Blink/WebKit reject and then allow reading it again. Same for Gecko in terms of file size. An error never means it'll fail forever in all browsers.)

[annevk]

Thanks @saschanaz for looking at this!

What does "clips" end up meaning? What if the new size is smaller? (And also, is the string clipped or are the bytes clipped before decoding?)

Also, this means that as long as an application has a reference to a file, they get to observe changes to it, right? But coupled with the fact that the timestamp has to remain the same I guess the tracking potential for that is rather limited in practice. If normally the timestamp would change I'd actually prefer that we irrevocably lose access on changes, but perhaps that's hard to implement?

[saschanaz]

Ah sorry, clipping does not happen on non-WebKit engines, one of my manual testcase was using file.slice() and that was causing it. That said, not sure how to write WPT for this 🤔 (or even mochitest)