additional Info:
I figured out that maybe it has something to do with the file-extensions.

On the share create 3 files with editor and name them:
1.doc
2.docx
3.docx

My files had only little random content.

Then try to attach them from the WebDAV.

Thanks for a bug report. Could you run evolution from a terminal, eventually under gdb and get the backtrace of the crash, please? That will show where it crashed. ABRT might catch the crash for you, I guess, but if not, then, please, install debuginfo packages for evolution-data-server, evolution, glib2 and gtk3, make sure the versions match the binary package versions precisely, then run from a terminal:

   $ gdb evolution --ex r --ex bt --ex q

which will run evolution and when it stops, possibly during the crash, then it'll print the backtrace of the crashing thread, then it'll try to quit gdb, which should be confirmed by the user.

Being it about file content, you might be able to reproduce it with the same files stored in /tmp or anywhere in the local file system.

here is the moment when I add the files:

Detaching after fork from child process 5235.
Detaching after fork from child process 5238.
Detaching after fork from child process 5241.
[New Thread 0x7fff9ffff700 (LWP 5244)]
[New Thread 0x7fff9f7fe700 (LWP 5245)]
[New Thread 0x7fff9ddf7700 (LWP 5246)]
Detaching after fork from child process 5249.
[Thread 0x7fff9ddf7700 (LWP 5246) exited]
[Thread 0x7fff9f7fe700 (LWP 5245) exited]
Detaching after fork from child process 5252.
Detaching after fork from child process 5256.
[Thread 0x7fff9ffff700 (LWP 5244) exited]

Adding the same files from my local storage (Documents folder) is working.

Thanks for the update, The snippet of the gdb output is not a backtrace, from which I suppose it didn't crash. I tried it here as well, and it doesn't crash here either, though the drop makes things awfully slow, because evolution asked gome-desktop3 to provide a thumbnail of the document on the WebDAV side, with this file name: 
>   /run/user/1000/gvfs/dav:host=cloud.example.com,ssl=true,user=mcrha,prefix=%2Fremote.php%2Fwebdav/1.doc

It can be that the server I used is just slow, I do not know. In any case it didn't crash here, it "only" made Evolution unusable for several seconds (maybe for half a minute).

I do not know what to do with it on the Evolution side, because the file name looks like a local file, thus the call to get its thumbnail is expected to be quick.

did you try 3 files or only 1?

Using one file, evolution locked up for something like 8 seconds for each file. When using three files, evolution locked, though didn't crash. Interestingly, I didn't want to wait for it to wake up, but I could not even kill it with -9, nor attach gdb to it, which is something I didn't see yet.

I can make evolution alive again when I unmount the WebDAV volume in Nautilus. It stops adding the files immediately, which is also something one does not want.

I also ran evolution under gdb and it was unable to break it (when pressed Ctrl+C), but once I unmounted the WebDAV volume gdb woke up and it showed me that it was in the call of creating the thumbnail, which corresponds to my findings mentioned in comment #4.

I extracted the related code out of evolution and added some debugging output around its calls and it showed me that each call to create the thumbnail takes approximately 8.5 seconds in average, though I wasn't able to reproduce the same lock up in the test application.

I can think of couple workarounds, like mark somewhere that the provided filename had been asked for a thumbnail and it was not provided, thus the call for it will be done only once; or to run the thumbnailer from a dedicated thread, but I'm unsure whether it can be done at all. Any such thing would be just a workaround, which may hide a real issue somewhere in the code stack.

I forgot to add, this is not related to drag&drop, I can see it also when attaching the three files from the WebDAV location with the "Add Attachment" dialog.

I'm moving this to gvfs for an investigation and eventual guide what to do on the Evolution side to not have the GUI locked up, because it's clearly related to the gvfs' WebDAV mount (when the lockup happens, I can unmount the WebDAV location in Nautilus, after which everything returns back to normal).

Can you point me on the relevant code in evolution, or show me the extracted code at the best? Does evolution ask for thumbnail synchronously? The file looks like as local, but it is remote. Thumbnail creation for remote files usualy means downloading the whole file, so you can't expect that it will be quick...

The local file path is automatically translated into URI in GIO API, see: 
https://wiki.gnome.org/Projects/gvfs/doc#Local_path_mapping.

You can check G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE and skip thumbnail creation for remote files. I suppoe that this is what Nautilus does by default.

Created attachment 1470286 [details]
thumbs.c

Here's the extracted code, though I wasn't able to really reproduce the complete lockup like in evolution, only the slowness. The code corresponds to Evolution's:
https://gitlab.gnome.org/GNOME/evolution/blob/master/src/e-util/e-icon-factory.c#L157
which is called from the main thread, in and idle callback, sadly multiple times.

Mine files were 7 and 8 bytes long, nothing larger, still the call to e_icon_factory_create_thumbnail() took from 7 to 20 seconds, probably depending on current network usage.

I wasn't aware of that file attribute, I can use it to make things better. Thanks for the pointer.

(In reply to Ondrej Holy from comment #8)
> You can check G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE and skip thumbnail creation
> for remote files.

Weird, I tried that and the file info has that attribute set to FALSE. Maybe I do something wrong, it's also possible.

It is working nicely for me using gio tool:

$ gio mount dav://www.ajaxbrowser.com/Userf1b6f53/
$ gio info --filesystem --attributes "filesystem::remote" dav://www.ajaxbrowser.com/Userf1b6f53/Notes.txt
attributes:
  filesystem::remote: TRUE
$ gio info --filesystem --attributes "filesystem::remote" /run/user/1000/gvfs/dav:host=www.ajaxbrowser.com\,ssl=false/Userf1b6f53/Notes.txt
attributes:
  filesystem::remote: TRUE

Did you try with g_file_query_filesystem_info (i.e. --filesystem)?

Maybe the complete lockup is caused because of the following upstream issue:
https://gitlab.gnome.org/GNOME/gvfs/issues/6

Created attachment 1470518 [details]
fileinfo.c

Evolution queries set of attributes here:
https://gitlab.gnome.org/GNOME/evolution/blob/master/src/e-util/e-attachment.c#L57

I added also G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE there, but it didn't work, thus, after verifying that your command works on my files as well, I changed my addition to ",filesystem::*", and it didn't work either, thus I've been wondering whether I look at the right place, which led me to this simple fileinfo.c program (the first line contains a command how to compile it). I mounted the WebDAV directory in Nautilus and then ran it as:

   ./fileinfo /run/user/1000/gvfs/dav\:host\=cloud.example.com\,ssl\=true\,user\=mcrha\,prefix\=%2Fremote.php%2Fwebdav/1.doc

and it shows the remote attribute as FALSE (0), which is weird, because running

   gio info --filesystem --attributes "filesystem::remote" 

with exactly the same file name returns:

   attributes:
      filesystem::remote: TRUE

I do not see what I'm doing wrong here, I'm sorry.

(In reply to Ondrej Holy from comment #12)
> Maybe the complete lockup is caused because of the following upstream issue:
> https://gitlab.gnome.org/GNOME/gvfs/issues/6

I agree, this looks like the same issue.

You have to use g_file_query_filesystem_info instead of g_file_query_info for filesystem attributes.

I am going to prepare a fix for that upstream issue...

(In reply to Ondrej Holy from comment #15)
> You have to use g_file_query_filesystem_info instead of g_file_query_info
> for filesystem attributes.

Oh, I'm not that used to this part of glib/gio, thus I'm sorry if it's a known limitation, though the following contradicts it a bit, from my point of view.

> I am going to prepare a fix for that upstream issue...

That would be nice. Evolution asks for the attributes asynchronously and splitting the call into two would be a pita, both due to delay and due to code complexity.

Not sure why this API was chosen, but this corresponds to stat and statfs calls. However maybe, it would be a nice feature to obtain filesystem attributes automatically over g_file_query_info if g_file_info_has_namespace (info, "filesystem") is TRUE, but consequently, g_file_query_filesystem_info would be redundant...

This has been already fixed upstream, the fix is part of Fedora 29 yet and Fedora 28 will be fixed by the upcoming upstream release...