FileReader should throw an exception if the underlying file changes

NEW
Assigned to

Status

()

Core
DOM
P2
normal
2 years ago
22 days ago

People

(Reporter: baku, Assigned: baku)

Tracking

(Depends on: 3 bugs, Blocks: 1 bug)

47 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: btpp-fixlater)

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
We do something but it's only based on the changing of the size.
We should use File::LastModified and have a version (not exposed) of this method that returns always the up-to-date value.
Whiteboard: btpp-fixlater
(Assignee)

Updated

2 years ago
Assignee: nobody → amarchesini
(Assignee)

Comment 1

2 years ago
Created attachment 8741811 [details] [diff] [review]
aaa.patch
Attachment #8741811 - Flags: review?(khuey)
(Assignee)

Updated

2 years ago
Depends on: 1264977
(Assignee)

Updated

2 years ago
Depends on: 1264978
(Assignee)

Updated

2 years ago
Depends on: 1264979

Updated

2 years ago
See Also: → bug 1265602

Updated

2 years ago
See Also: → bug 1265603
Comment on attachment 8741811 [details] [diff] [review]
aaa.patch

Review of attachment 8741811 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/base/File.cpp
@@ +714,5 @@
>  
> +  if (WorkerPrivate* workerPrivate = GetCurrentThreadWorkerPrivate()) {
> +    if (workerPrivate->UsesSystemPrincipal()) {
> +      GetMozFullPathInternal(aFileName, aRv);
> +    }

if (!UsesSystemPrincipal())
  return;

And then only one call to GetMozFullPathInternal.

What's the logic behind this anyways?

::: dom/base/FileWatcher.cpp
@@ +27,5 @@
> +    nsCOMPtr<nsIRunnable> runnable =
> +      NS_NewRunnableMethod(this, &FileWatcherCallback::InitializeInternal);
> +    if (NS_WARN_IF(NS_FAILED(NS_DispatchToMainThread(runnable)))) {
> +      return false;
> +    }

Just MOZ_ALWAYS_SUCCEEDS this. NS_DispatchToMainThread can't really fail.

::: dom/ipc/DOMTypes.ipdlh
@@ +74,5 @@
>    uint64_t length;
>    int64_t modDate;
>  
> +  // The full path of this file, if it points to a real file.
> +  nsString filePath;

Does this only ever go from the chrome process to the content process?  Because we can't trust what the content process gives us, right? (It could give us /etc/passwd/ or something if it's been compromised).
Attachment #8741811 - Flags: review?(khuey)
(Assignee)

Updated

2 years ago
Blocks: 660148

Updated

22 days ago
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.