Update FileSystemObserver explainer #163
Conversation
- Rename some of FileSystemChangeType - Add Gecko position
Update the explanation for unknown change type
Remove trailing dot
proposals/FileSystemObserver.md
Outdated
| @@ -374,7 +374,7 @@ await observer.observe(directoryHandle, { recursive: true }); | |||
| // corresponding to `directoryHandle`, then `touch file.txt`) | |||
| ``` | |||
|
|
|||
| User agents may also use the `"unsupported"` `FileSystemChangeType` to explicitly indicate that change types are not supported. | |||
| User agents may also use the `"unknown"` `FileSystemChangeType` to indicate that a change has occurred but the type of change is unknown or is not to be specified to the site. This could mean that the change type does not belong to any other values defined in `FileSystemChangeType` due to cross-platform differences, or a change has occurred while the site was not fully active (i.e. site in back/forward cache becomes fully active again). | |||
There was a problem hiding this comment.
I really don't think you should say it could be a change type that doesn't belong to any other values. Currently unknown is being used to say it is "unknown" if zero or more events have occurred, so that the developer will trigger a poll.
Sending out "unknown" for OS events that are specific to some platform would be a confusing signal to developers.
There was a problem hiding this comment.
Rephrased this section into a new section about interactions with BFCache, as it is not related to cross-platform differences.
Explain the interactions with Back/forward Cache
proposals/FileSystemObserver.md
Outdated
| case 'unsupported': | ||
| // Change types may not be supported on all platforms. | ||
| case 'unknown': | ||
| // Change type is not known. |
There was a problem hiding this comment.
Could this be updated to zero or more changes may have been missed?
There was a problem hiding this comment.
It can't be zero, can it? In any case, updated this comment to indicate the possibility of multiple events
There was a problem hiding this comment.
Yeah it can. On Windows, if the scope of the OS watch is larger than the observation's scope, then it can buffer overflow for file events outside the observation's scope. But we can't know that, and have to assume that there could have been events in the observation's scope, so we'll have to send an unknown. There could be a similar scenarios on Mac.
There was a problem hiding this comment.
FWIW this is just an explainer (not a spec) so I don't think it's necessary to enumerate all the possible scenarios the implementation may choose to use this change type. This document already has several hedges about how changes are "best-effort" etc., so this seems fine to me ¯\(ツ)/¯
Update the comment for unknown change type
|
Please ensure to follow the guidelines at https://github.com/whatwg/meta/blob/main/COMMITTING.md when you submit this PR. Thanks! |
|
It seems the guidelines were not followed. :-( This should have been a "Meta: " change as it doesn't change the standard. The commit body also repeats the commit title and the commit title contains a redundant reference to the PR... |
|
Apologies! I misunderstood what "Meta: " prefix is for. |
FileSystemChangeTypenames from created/deleted/unsupported to appeared/disappeared/unknown:FileSystemChangeRecord.relativePathMovedFromFileSystemHandleto a non-existing file would not make much sense, but it would be still useful for sites to know where a file/dir has been moved from. It should return an array of path components instead (similar torelativePathComponents).