1319053 - Upload of folder with non-ASCII files fails with error NS_ERROR_FILE_NOT_FOUND

Status: RESOLVED DUPLICATE of bug 1323935

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

Description

[santiago.garcia]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161104212021

Steps to reproduce:

I tried to upload a folder containing a file with a non-ASCII filename (äöüß.html, the actual file was empty). 


Actual results:

Nothing is uploaded. The console logs an NS_ERROR_FILE_NOT_FOUND error.

If I break on exceptions in the Firefox DevTools, I can see that the filename has been mangled to "äöüß.html". 

I can upload the file by itself just fine, it is only when I upload a folder containing the file that the error occurs.


Expected results:

File should be uploaded without a problem

Comment 1

[santiago.garcia]

I have a self-contained example I used for another bug report (https://bugzilla.mozilla.org/show_bug.cgi?id=1303999) that can also be used to reproduce this bug.

1. Clone the repo at https://github.com/sgarcialaguna-mms/FirefoxUploadCrash
2. Install Python 2.7
3. Run python webserver.py
4. Open the browser console with F12
5. Create an empty file named äöüß.html
6. Drop the folder containing the file into the dropzone

=> An NS_ERROR_FILE_NOT_FOUND exception is logged, no files are uploaded.

Note that I use https://github.com/blueimp/jQuery-File-Upload to handle file uploads, I haven't yet checked if the error occurs without using any libraries.

A colleague using Ubuntu 14.04 reports that the bug does not occur on her machine

Comment 2

[Loic]

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=974cfc
29c1e30561d40882c051f07724eff99491&tochange=5785e6e80c6696b6e941edcbc06583864d95
ae95

The issue appears after webkitdirectory enabled in bug 1288683.

I think there is an issue with this simple testcase too: https://codepen.io/anon/pen/yVMKPp
I you upload a folder with the file äöüß.html, it's bad displayed: http://i.imgur.com/NfDfqPl.png

Andrea, as Olli is on vacation during this week, could you check this issue, please.

Comment 3

[Andrea Marchesini [:baku]]

I cannot reproduce it. I suspect it's a charset issue. Can you reproduce this error if you force UTF-8 in the test?

Comment 4

[Loic]

testupload.html (with the file dropzone) has already <meta charset="UTF-8">.

Comment 5

[santiago.garcia]

Like I said, it fails on Windows, but works on Ubuntu, so maybe it depends on the filesystem's encoding?

Comment 6

[Loic]

On NTFS partitions, filenames are encoded in Unicode:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd317748(v=vs.85).aspx

Comment 7

[santiago.garcia]

Yeah, you're right.

Still, I asked a colleague using Mac and he can't reproduce the issue either, so the OS definitely is playing some role here.

Comment 8

[Andrea Marchesini [:baku]]

Santiago, you are right. On linux the encoding of the file names, when written on disk, is taken from LC_ALL and/or LANG environment (plus Gtk/Glib always uses UTF-8).

Comment 9

[Andrew Overholt [:overholt]]

baku, can you take a look?

Comment 10

[Andrew Overholt [:overholt]]

(I mean more than take a look; I mean take this :)

Comment 11

[Andrea Marchesini [:baku]]

> Nothing is uploaded. The console logs an NS_ERROR_FILE_NOT_FOUND error.

Can you tell me exactly what throws this error? I don't have winNT.
Loic, do you see this error message as well? Can you maybe answer this question too. Thanks!

Which version of windows do I need to use to reproduce this bug?

Comment 12

[santiago.garcia]

> Can you tell me exactly what throws this error? I don't have winNT.

That happens inside the jquery fileupload library when trying to access file.size.

I get the same error with the Codepen Loic linked when accessing the size property of the äöüß.html file. The  file name is already mangled at that point, so that just looks like a follow-up error. (of course it cannot find äöüß.html) 

Update codepen to access the size property:
https://codepen.io/anon/pen/MbmBGE

> Which version of windows do I need to use to reproduce this bug?

I have Windows 10 x64 myself, I know the problem also occurs on Windows 7 x64 at the very least.

Comment 13

[Loic]

Attachment: NS_ERROR_FILE_NOT_FOUND.txt

(In reply to Andrea Marchesini [:baku] from comment #11)
> > Nothing is uploaded. The console logs an NS_ERROR_FILE_NOT_FOUND error.
> 
> Can you tell me exactly what throws this error? I don't have winNT.
> Loic, do you see this error message as well? Can you maybe answer this
> question too. Thanks!
> 
> Which version of windows do I need to use to reproduce this bug?

The testcase provided by the reporter throws this error, it's in some JS libs. I joined a log of the error with the dependencies to the JS libs. But you can test with the codepen too, in Windows VM eg.

Comment 15

[Petrus Jonsson]

What is the status on this issue? Is anyone actively working with this? I am experiencing the same problems in windows 7 and 10. I have no problems in my Linux Mint environment. This is quite a problem, since all of my clients run Firefox in windows.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

This is a bad problem.
baku, do you have time to look at this or find someone who does work on Windows?