1200033 - Dragging a large number of files into a webpage hangs Firefox on Windows for some time

Status: NEW

(Core :: Widget, defect, P3)

Description

[Jonathan Watt [:jwatt]]

Dragging a large number of files into a webpage hangs Firefox for some time. Dragging 10,000 files in hangs the browser for around 20 seconds for me, whereas in IE there is very little delay.

Comment 1

[Jonathan Watt [:jwatt]]

The time seems to be spent under:

  MaybeInvokeDragSession
    DataTransfer::FillAllExternalData
      DataTransfer::FillInExternalData
        nsDragService::GetData
          nsClipboard::GetDataFromDataObject
            nsClipboard::GetNativeDataOffClipboard
              ::DragQueryFileW

https://mxr.mozilla.org/mozilla-central/source/widget/windows/nsClipboard.cpp?rev=275301e64d0e&mark=489-489,493-493,496-496#488

Of the three lines marked in the above link, half the samples in my profile were in the first DragQueryFileW call and the rest were split roughly evenly between the other two calls.

We call nsDragService::GetData once for each file dropped, but the number of files doesn't change across those calls. The value returned from first DragQueryFileW call could in principle be cached and reused then.

The second DragQueryFileW call is only necessary because the contract that GetNativeDataOffClipboard makes with its callers is that it passes out an allocated object that the caller is responsible for freeing. This second DragQueryFileW call is used to determine the size of the buffer to be allocated. We could avoid this by having a different API that more directly returns nsIVariant objects, or even files.

The third DragQueryFileW call seems unavoidable since that's the call that gets the actual path of each dragged file. Unless there is better API that we can use nowadays.

Anyway, if we could get rid of the first and second DragQueryFileW calls we could cut the drag-and-drop time by 75%.

Comment 2

[Jonathan Watt [:jwatt]]

Bas, the fact that IE doesn't really have any delay seems to imply that they are not using DragQueryFileW even to get the paths of the dragged files, or else they would be suffering more noticeable delay. Do you know of any other faster API?

Comment 3

[Jonathan Watt [:jwatt]]

Attachment: createfiles.py - utility to create a given number of files in CWD

Comment 4

[Jonathan Watt [:jwatt]]

Attachment: test file

Comment 5

[Bas Schouten (:bas.schouten)]

(In reply to Jonathan Watt [:jwatt] from comment #2)
> Bas, the fact that IE doesn't really have any delay seems to imply that they
> are not using DragQueryFileW even to get the paths of the dragged files, or
> else they would be suffering more noticeable delay. Do you know of any other
> faster API?

I don't, sorry for the slow reply.