Tested this issue on Ubuntu 14.04 using chrome latest stable #62.0.3202.94 by following steps mentioned in the original comment. After step-2 uploaded the inaccessible file to paste.debian.net, observed the file got uploaded and no error is displayed.

Reporter@ Could you please recheck this issue by upgrading your chrome to latest stable #62.0.3202.94, if issue still persists please provide a screen cast or screen shot for better understanding.

Thanks!

Deleted: Test.png 22.9 KB

	Test.png 22.9 KB View Download

you must post the form for the error to appear

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this issue on Ubuntu 14.04 using chrome latest stable #62.0.3202.94 by following steps mentioned in the original comment. After clicking on send button observed the file is not uploaded and displays error saying 'This site can’t be reached'.

No error is seen while submitting the files is Windows and Mac, This issue is seen on older version of chrome M50-50.0.2624.0 as well, hence marking it as untriaged.

Thanks!

Looking at the code and consulting eroman@, it seems a bit of a known issue, whose generic solution was discussed in https://bugs.chromium.org/p/chromium/issues/detail?id=473690.

UploadDataStream is returning a single int, which does not distinguish whether the error happened on the file reading side or the socket writing side of a POST.

As eroman@ pointed out to me, there is precedent for upload specific error codes, such as UPLOAD_FILE_CHANGED.  So perhaps UploadDataStream should be modified to map ERR_ACCESS_DENIED into a new UPLOAD_FILE_ACCESS_DENIED (?) for this case, and then have upper layer surface a more sensible error to the user.

[+edwardjung]:  Any thoughts on whether it's worth making a new error code for this case?  It looks like a pretty obscure case to me.  Only about 0.0003% of main frame loads result in ERR_ACCESS_DENIED (and its even less frequent in subresource loads), and it's unclear how many of them are this case.

Could also imagine a separate error for ERR_FILE_NOT_FOUND when reading an upload, and there may be others as well (We return ERR_INVALID_ARGUMENT when we get ERROR_BAD_DEVICE, for instance, which might happen with removed devices?).

Even ERR_ACCESS_DENIED itself is about 9 errors in one (On windows, for instance, we map the following errors to it:  ERROR_ACCESS_DENIED, ERROR_WRITE_PROTECT, ERROR_SHARING_VIOLATION, ERROR_LOCK_VIOLATION, ERROR_BUSY, ERROR_IO_DEVICE, ERROR_POSSIBLE_DEADLOCK, WSAEACCESS).

Could also imagine just one catch all for upload read errors, that we return regardless of the underlying net or platform error code, though that may actually provide less information.

My feeling is that we shouldn't create a new error just for this specific error since the number of occurrences seem very low.

The suggestion for a single error for all file upload errors feels better to me and would be better than the current state described. The description could ask the user to check the file selected for uploading is available. 

The UI should clearly differentiate local and remote errors. Also the error being very rare is exactly the reason it needs a distinct error code. How are you supposed to diagnose the issue otherwise?

If only 1 person throughout the existence of the universe will ever see an error page, creating, testing, and maintaining it is a waste of developer time.  It only serves to bloat up the binary and add to the complexity of the code, without really paying for itself, in terms of providing a benefit to users.  It may make life hard for that one user, but unfortunately, it wouldn't be worth the effort.

So you think that few people having problems with accessing local files makes it fine to lie to them and misleading them into thinking that the remote site is at fault.

I was wondering how such bogus interface could even get into the code but this attitude makes it clear.

I suppose it is time to find another web browser.