702949 - <input type="file"> doesn't submit form in case of filling wrong filename

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[karel.sluka]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.120 Safari/535.2

Steps to reproduce:

I clicked on input to upload a file. I selected the file from Open dialog box and confirmed it. After confirming dialog the file I have chosen was removed from the filesystem. As last step I submited the form.


Actual results:

No request was sent to the server.


Expected results:

Send request to the server according resource defined in form action attribute. (This worked in Firefox 3.6 but not later).

Comment 1

[Josh Matthews [:jdm]]

Jonas, Jignesh has narrowed down where this is failing. We're now looking at the correct way to deal with this - my instinct is to create an empty stream instead of the file stream, but Chrome apparently discards the entire input element from the form submission and displays a warning indicating as such. Is this specced at all?

Comment 2

[Josh Matthews [:jdm]]

Nevermind about the Chrome behaviour - that was actually Zimbra's warning, not the browser's.

Comment 3

[Josh Matthews [:jdm]]

Looks like Chrome submits an empty file.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Submitting an empty file sounds like an ok solution to me. Alternatively we could use the form-validation code to focus the file control and let the user choose a new file.

Comment 5

[Mounir Lamouri (:mounir)]

(In reply to Jonas Sicking (:sicking) from comment #4)
> Submitting an empty file sounds like an ok solution to me. Alternatively we
> could use the form-validation code to focus the file control and let the
> user choose a new file.

Using the form validation mechanism to say "The file you are trying to upload has been deleted in the meantime, please select a new one." seems way nicer regarding UX but do we really care for such an edge case?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Hmm.. the problem is that we need to check synchronously, so yeah, probably not worth doing.

Submitting an empty file seems like an improvement though.

Comment 7

[Karl Tomlinson (:karlt)]

I wonder whether we could open the file at the time immediately after it is picked, in order to keep a handle on the file that will be valid after it is unlinked.
At least that is the Unix behavior; I'm not sure of the NT behavior; perhaps on NT the handle would prevent the file from being deleted, which would also be fine.

Comment 8

[[:Aleksej]]

An older report: bug 479429.

Comment 9

[[:Aleksej]]

(In reply to Aleksej [:Aleksej] from comment #8)
Please ignore that, wrong bug, sorry.

Comment 11

[Mounir Lamouri (:mounir)]

Attachment: Patch

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 720475 [details] [diff] [review]
Patch

This will cause sync IO.

Comment 13

[Mounir Lamouri (:mounir)]

Attachment: Patch

Using aBlob->GetSize() as the current code does. Though, it's not clear to me why this wouldn't do IO unless the file is cached somehow. Anyway, keeping the same method is probably better.

Comment 14

[Mounir Lamouri (:mounir)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/aaf32e584c53

Comment 15

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/aaf32e584c53