User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

When uploading a file with german umlauts (ü, ä or ö) from a macOS to a cloud-space (nexcloud or onedrive) the characters are wrong

Actual results:

A file named möm uploaded to nextcloud via firefox is displayed as mö m and uploadet via firefox to onedrive it is displayed as mo"m
On nextcloud ther is a space added to the filename and on onedrive the two dots over the o are now on the right side of the o. See also the attached file.

This only happens on Firefox on macOS. Uploading the same file from Windows and Firefox everything works as expected.
Also Safari and Chrome on macOS does the right thing.

Expected results:

A file named "möm" should be displayed als "möm" when it was uploaded to a cloud-space like nextcloud or onedrive.

I've managed to reproduce the issue on macOS 10.14 using the latest Nightly (v68.0a1) and the current Release version (v66.0.5).

There are a couple of issues involved here.

Filenames on macOS (HFS+) use a decomposed (Unicode NFD) representation of accented characters. So the name of the file "möm" is stored in the filesystem as <letter m, letter o, combining dieresis, letter m>.

In contrast, I believe filenames on Windows normally use precomposed characters, so on a Windows computer the name of the file "möm" will be stored as <letter m, letter o-umlaut, letter m>.

So one question that comes to mind is whether, when a file is uploaded to a service like this, the filename should be normalized to a specific representation (if so, which?), or should it be left exactly as it existed on the source system?

If we believe it would be desirable, for better interoperability, to normalize filenames when uploading to a cloud service such as the examples here, whose responsibility would that be? Should the browser do it automatically somewhere during the upload operation, or should the file storage service take care of normalizing what it stores?

(From brief testing, it looks like browsers normalize the filename when downloading the file, so whichever way the name is stored on the cloud service, it gets converted to the native representation of the OS when the file is retrieved.)

But when viewing the list of files online, if a file was uploaded with a macOS-style (decomposed) name, the rendering in Firefox will depend on the font that's used to display the name; many fonts lack support for the combining diacritics, and so fallback comes into play and the umlaut is likely to be poorly placed. Explicitly using a font that has full support for combining marks would make it look correct.

Bug 543200 and/or bug 1309934 would help with the visual glitch here.