Add tests for file snapshot state #34143
Conversation
| <script src="/resources/testharness.js"></script> | ||
| <script src="/resources/testharnessreport.js"></script> | ||
| <label>Select a file first: <input type="file" id="fileInput"></label><br> | ||
| <button id="readyButton">Then modify the content of the selected file and click this</button><br> |
There was a problem hiding this comment.
Be explicit about the required modification (i.e. the size should be smaller)
There was a problem hiding this comment.
No, the size can be random. Larger size is also okay. (This is assuming clipping behavior of WebKit. The question is, should it clip?)
Co-authored-by: Joshua Bell <[email protected]>
|
When I emptied a file, One way this test could be improved I suppose is with explicit instructions around what the file contents should be before and after as that would allow you to assert those as well. |
Huh, I can reproduce this, and it's exactly 3221. Interesting. |
Tried adding a Anyway, I'm pretty confident that we all want the timestamp based approach to detect file change, what I'm not confident is whether to clip or not, since it's WebKit only thing. Any idea? (And if yes, should it be padded? I'd say no, I'm not sure that would be 100% web compatible and I'm okay enough with current no-padding behavior. And it's already very edge case enough.) |
|
What is the benefit of clipping? Being able to reuse an existing byte buffer for the file? I think I'd rather not clip. Even better would be treating a size change the same as a timestamp change. This would reduce the "leak" even more. |
|
Oh yeah, why not do both of checks and just forget about edge cases of clipping? That sounds safer and much easier. |
See w3c/FileAPI#47