I think this also has some relevance to accessibility for no-mouse users. I tried using copy-paste (instead of drag and drop) to get the file from Konqueror to the file box, but it just pastes in the local filename (it does not upload it then post in the F-number).

As a quick improvement, perhaps the file dialog ("To add files, drag and drop them into the comment text area.") could at least mention /file/upload (e.g. https://secure.phabricator.com/file/upload/) as an alternative.

Just to clarify: the "no-mouse" users you refer to are users who can't use a mouse (for example, because they have limited manual dexterity), not users who prefer not to use a mouse, right? Do you have a sense of how many of these users exist?

See also T4843. We have several interactions which require drag-and-drop within the web UI (reordering search queries, reordering fields, reordering applications) which suffer from a similar accessibility problem. Other than dragging tasks between workboard columns, these interactions are all probably less important than file uploads, though.

(D9561 also seems to work fine, it just duplicates too much code between the completely vanilla uploader and the dialog uploader.)

In T5187#21, @epriestley wrote:

Just to clarify: the "no-mouse" users you refer to are users who can't use a mouse (for example, because they have limited manual dexterity), not users who prefer not to use a mouse, right?

Correct, I am thinking of the former (even though the latter may get a side benefit).

Do you have a sense of how many of these users exist?

No, nor do I know whether they have workarounds for this issue.

◀ Merged tasks: T5720.

Quoting myself from T6277:

I use i3 which is a window manager without a desktop environment, thus I am having a hard time drag & dropping files to upload. This goes for both pholio's "drag image here" field, and all wysiwyg-boxes, which ironically have "upload here" buttons that triggers an alert, telling me to drag & drop into the wysiwyg's textarea. Somewhat annoying :)

> console.log(navigator.userAgent)
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0

Just a question: the copy&paste scenario is mentioned here tangentially, but as a feature is very different from a vanilla upload button. Hast it been considered? The main use case are screenshots: user takes a screenshot, it's in the clipboard, can be inserted in a textarea with a paste action. This would be equally beneficial for all users, since it's simpler than drag & drop (you don't need to open the files app to drag from).

Copy/paste should already work in Chrome.

Last time we checked (June 2014) other browsers did not appear to support it, or support it only in a way that's really hacky/fragile. See D9647, T5437, T5411 for some discussion.

And unhappily this doesn't solve the problem for mobile browsers :/

+1 for mobile browsers

After T7149, drag-and-drop uploads support arbitrarily large files and resumable uploads for files larger than the chunk threshold (currently 8MB).

It would be desirable to intercept all <input type="file" /> controls and use the file.allocate workflow for the file data, to extend these features to the vanilla workflows. In particular, although vanilla uploads do not need to be buffered into memory during the upload itself, they currently do need to be buffered into memory before they can be written to a storage engine, so they're still bounded above by memory constraints.

A less aggressive approach would be to execute the file.allocate workflow on the server. This would remove the memory buffering constraints, but wouldn't give clients resume support or the upload progress UI.

Just chiming in to say I also have this issue as I use i3. I can drag and drop but it goes against the entire i3/tiling workflow.

Please where you say "To add files, drag and drop them into the comment text area.". be sure to also say what to do if one cannot/does not know how to do that !!!!!!!!!!!!

This is still a big problem for Wikimedia's Phabricator installation, making it unnecessarily difficult to file or amend bug reports about mobile issues.

We haven't seen much interest in this from outside WMF, so there are probably several hundred tasks ahead of it on our natural roadmap.

See also Planning.

(If that answer isn't particularly satisfying, maybe see discussion starting here: T7820#172877.)

@epriestley I'm happy to try to pay you to review the patch if that'll help.

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

See Paid Prioritization and L34 Phacility Prioritization Service Agreement for specifics, if you haven't run across them yet.

You're behind T10917 and T10939 in the queue (see the Prioritized workboard) and some other things which are wrapping up, so it will probably be about a week before we can pursue this. If that sounds reasonable, we can get this into the queue now and confirm with you before starting work.

In T5187#175015, @epriestley wrote:

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

See Paid Prioritization and L34 Phacility Prioritization Service Agreement for specifics, if you haven't run across them yet.

You're behind T10917 and T10939 in the queue (see the Prioritized workboard) and some other things which are wrapping up, so it will probably be about a week before we can pursue this. If that sounds reasonable, we can get this into the queue now and confirm with you before starting work.

Sounds perfect. Let's go with you folks doing fresh development -- we're not 100% sure the old patch still works, and you know the current state of the system better than we do.

I'll check in to make sure I know whose budget this'll come out of on Wikimedia's end.

After D12066, we have an upload workflow which gracefully accommodates very large files (progress bars, resumable uploads, no server host needs to handle more than 4MB of data on disk or in memory at once). This flow is activated when you drag-and-drop, and we've successfully used it to transfer reasonably-sized cluster import/export files (1-2GB) for the better part of a year now.

I'd like this flow to replace all upload flows, including the remarkup upload flow. The proposed interaction in D11513 uses this flow, but is fairly abrupt: you select a file and it is immediately uploaded. I don't particularly like that from a UX viewpoint (partly, I think it's easier to accidentally pick embarrassing_racoon_photo.jpg accidentally from a file selector than via drag-and-drop), and it also isn't adaptable to solving other similar problems in this vein (like Files → Upload or Pholio) where the control is part of a full form with other inputs.

(Technically, we also have these controls in Macro and a few "Upload Profile Image" interfaces, but those interfaces are almost never used to upload files which are large enough to benefit from progress bars, chunked transfer, or resumable uploads, so I think they're of very low priority.)

Instead, I think the interaction I want is something like this:

• When you submit a form, it queries all of its controls and gives them an opportunity to prepare data.
• Upload controls in the form pause the submission process, start their uploads, and replace their UI with something like this:

Uploading: [XXX.............] [ Cancel ]

• Upon completion, the controls replace their data with the PHID of the uploaded file and release their lock on the submission process.
• Once all controls complete, the form is submitted.

This would be able to serve as a drop-in replacement for a vanilla upload control in any form, including complex forms with multiple inputs (and multiple file inputs).

In the specific case of the remarkup uploader, it would possibly be even better to close the form without waiting for the upload to complete so you can begin another upload immediately.

However, we're generally very light on Javascript. Controls don't have an object that represents them on the client side, forms don't either and can't currently enumerate contained controls in a structured way, and the JX.Workflow code that drives dialog boxes has been nearly unchanged for quite a while, so there isn't much infrastructure to support this today.

As we don't currently have other use cases and the major driver here is "make this work whatsoever on mobile and for the 5 people that use non-cursor windowing systems", investing a lot of time in that infrastructure doesn't really make sense at this juncture, so this implementation is probably going to be pretty flimsy in places for the moment. I think the control itself can be implemented properly today, but the interaction between the control logic and the form logic is going to be a pile of wishes.

D15953 played out more or less as described above. I'm not going to land it before cutting stable this week since it touches Workflow in a couple of ways that might have unforseen consequences, but I expect it to be available in master some time later tonight or tomorrow.

quick note: even on systems with 'normal' windowing systems many users
dislike or can't use drag-and-drop workflows. I'm mostly mentioning this so
that the non-D&D workflow isn't entirely treated as a second class citizen.

This is in master and live on this install. Let me know if you hit issues with it, especially on mobile. Seems fine on my iPhone 4 but I don't have a ton of devices on hand for testing.

I don't have any more planned changes here, so I'm pausing this for feedback and bugs.