Page MenuHomePhabricator

Make "Upload File" dialog have a vanilla file upload control
Closed, ResolvedPublic

Description

(Related to Wikimedia community discussions in https://phabricator.wikimedia.org/T165 )

STEPS:

  1. Click on the "Upload file" icon in a Maniphest task.
  2. Message says "To add files, drag and drop them into the comment text area."

PROBLEM:
Might not have an application to drag and drop from; might not run a platform supporting input interpreted as dragging. => Alternative ways of file uploading aren't discoverable from the UI.

PROPOSAL:

  • Mention that you can paste an image from the clipboard into the comment area.
  • Link to /file/upload/ for classic upload (though it's rather unclear after uploading a file how to actually link to it from a Maniphest task)

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.)

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.

chelmertz added a comment.EditedOct 9 2014, 9:00 AM

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
qgil added a comment.Dec 11 2014, 7:14 AM

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

matmarex claimed this task.Jan 27 2015, 6:44 AM

It would be a lot simpler to use HTML 5 File API together with a regular <input type=file /> field. This won't help the IE8s of the world, but will help users of non-standard, but modern operating systems and browsers.

And turns out it's actually very easy to add to the existing system. I spent a few hours on this and it works! Patch on the way.

qgil updated the task description. (Show Details)Feb 9 2015, 10:28 AM

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.

Jidanni added a subscriber: Jidanni.Jun 3 2015, 6:22 AM

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 !!!!!!!!!!!!

eadler added a subscriber: eadler.
matmarex removed matmarex as the assignee of this task.Jun 5 2015, 1:51 AM

My patch seems to be stuck. Oh well.

eadler moved this task from Backlog to Nits on the FreeBSD board.Jun 14 2015, 4:39 AM
srijan added a subscriber: srijan.Jul 19 2015, 12:06 PM
epriestley moved this task from Backlog to vNext on the Files board.Nov 24 2015, 4:58 PM
benjumanji added a subscriber: benjumanji.
brion added a subscriber: brion.May 12 2016, 4:18 PM

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.)

brion added a comment.May 12 2016, 4:32 PM

@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.

brion added a comment.May 12 2016, 4:48 PM

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.

epriestley moved this task from Backlog to Preflight on the Prioritized board.
epriestley moved this task from Preflight to The Queue on the Prioritized board.May 12 2016, 7:31 PM
scode added a subscriber: scode.May 17 2016, 3:10 PM

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 FilesUpload 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.

epriestley moved this task from The Queue to Paused on the Prioritized board.May 20 2016, 11:41 PM

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.


GoalRefTimeNotes
Upload DialogD159531 HourAdd a file input to the "upload file" dialog.
Subtotal1 Hour
Cumulative Total1 Hour
epriestley closed this task as Resolved.Jun 17 2016, 1:47 AM
epriestley claimed this task.

I believe this is resolved and accounted for, let us know if anyone is hitting issues.

Twilight removed a subscriber: Twilight.Jul 16 2017, 2:10 PM