Open Bug 1823421 Opened 3 years ago Updated 1 year ago

`NotFoundError: Node was not found` when trying to access a non-readable file with the FileReader API

Categories

(Core :: DOM: File, enhancement, P5)

x86_64
Linux
enhancement

Tracking

()

People

(Reporter: julienw, Unassigned)

References

Details

(Keywords: good-first-bug, Whiteboard: dom-lws-bugdash-triage)

STR:

  1. Have a file that's not readable by your user (chmod +r <file> works)
  2. Open https://profiler.firefox.com
  3. Drag and drop the file from step 1 to the profiler UI (the bug doesn't happen with the File Picker because Firefox forbids to select a non readable file).

=> we get an error NotFoundError: Node was not found

The profiler uses the FileReader API, and call readAsArrayBuffer to read it.

I believe there are multiple issues here:

  1. The error message itself is left as the default Node was not found which isn't accurate in this case, because a file can't be found, not a Node.
  2. Ideally in this case we should get a NonReadableError (see https://searchfox.org/mozilla-central/rev/3c3ad00ab7f587e2c75e8cebb89badc4e946b10e/dom/file/FileReader.cpp#580). But I guess this also depends on the underlying error.

ad1.) The message "Node was not found" comes from NS_ERROR_DOM_NOT_FOUND_ERR which comes from this mapping, so apparently we know that we actually have NS_ERROR_FILE_NOT_FOUND and we map it to NS_ERROR_DOM_NOT_FOUND_ERR as the spec asks us to do.

We may want to consider changing the text message to use the more general wording from the IDL spec. I do not think we can have a more specific wording just for this case (and if we tackle 2. we do not need it).

ad2.) It seems indeed that already the spec suggests to use NotReadableError in this case. I did not check how many layers down the road we would need to arrive in order to distinguish this.

Probably this deserves two bugs. If anybody wants to take this, please file a bug for the part you want to solve, thank you. For the time being I am marking this as "good-first-bug", though 2. might be more a "good-second-bug".

Severity: -- → S4
Keywords: good-first-bug
Priority: -- → P5

About 1: You wrote that "I do not think we can have a more specific wording just for this case.", but I think we could benefit from one for the Not Found Error anyway, to better say that this File is not found. What do you think of specifying a specific error message in this case, using this constructor?

I could argue that we could do the same for the 2 other errors in FreeDataAndDispatchError. For example FILE_ACCESS_DENIED leading to a Security Error gives a weird error message The operation is insecure.

Since we're already conforming to the spec but there is more we could at least surface through devtools or move to change the spec (which might be hard), setting to enhancement.

Type: defect → enhancement
Whiteboard: dom-lws-bugdash-triage
You need to log in before you can comment on or make changes to this bug.