Comment 1 by jteh on 2011-09-06 23:21
This is already possible without any additional functionality. All related commands are already documented, so you just drag like any other user would:

1. Move the mouse to the source position. You can do this with the help of NVDA's move mouse to current navigator object command.
2. Lock the mouse button. You can do this with a physical mouse or you can use NVDA's left/right mouse button lock commands.
3. Move the mouse to the target position, similar to step 1.
4. Unlock the mouse button, similar to step 2.

Have you tried this? Why is this not sufficient?

Comment 2 by Ahiiron on 2011-09-06 23:39
I can see this being useful to copy formatting and HTML markup from a webpage. Currently, doing the lock/unlock method and copying the text doesn't retain any of the formatting, it just copies the text from the virtualBuffer. Is there perhaps a way to get at the actual page with pictures and all?

Comment 3 by Ahiiron on 2011-09-07 02:47
On closer inspection, the formatting is copied correctly. I was testing in wordpad and wasn't getting any links /list item notifications from NVDA like in Thunderbird's compose message window. Should I open a ticket for a feature request to have markup be indicated in RichEdit apps like WordPad?

Thanks.

Comment 4 by jteh (in reply to comment 3) on 2011-09-07 07:09
Replying to Ahiiron:

On closer inspection, the formatting is copied correctly. I was testing in wordpad and wasn't getting any links /list item notifications from NVDA like in Thunderbird's compose message window. Should I open a ticket for a feature request to have markup be indicated in RichEdit apps like WordPad?

You should get notifications for links at least; I've definitely seen this. However, I don't think !RichEdit supports any other kind of structural formatting.

Comment 5 by jteh on 2011-10-16 22:36
No reply to comment:1, so assuming this is sufficient.
Changes:
Added labels: wontfix
State: closed

Comment 6 by Palacee_hun on 2012-01-02 20:15
I suggest a simplification of the documented drag and drop procedure (see Comment #1) which would be very easy to implement. My suggestion would reduce the process from 4 steps to just 2 steps. The only thing to be done would be to modify the "lock left mouse button" script so that the "route mouse to nav. object" script would be called prior to locking/unlocking the left mouse button. This simple modification would yield the following drag and drop procedure whichseems much more practical, yet would not differ from the way sighted people do it:
[Locate the object to be dragged with object nav., then activate the modified "lock left button" script (would route the mouse and then immediately lock the button)
2. Locate the object where you want to drop and activate the modified script again (would first route the mouse to it, then unlock the button) and you are done!
[[BR]([BR]]
1.)]
Better still the suggested modification can also be done on not the original "left mouse button lock" script itself, but on a clone of it. This way the clone script would be turned into an independent "drap and drop" script (e.g. NVDA+D can be assigned to it), while leaving the original left button lock/unlock script alone. This latter solution would make it possible to lock/unlock the left mouse button independent of drag and drop operations, if it has any other uses besides that at all.
Changes:
Removed labels: wontfix
State: reopened

Comment 7 by jteh on 2012-01-02 22:28
I'll grant that this reduces the procedure from four keystrokes to two. However, it also introduces redundancy, inconsistency and potential confusion. The user already has to learn how to route the mouse to left click, right click, etc., so why should drag/drop be any different?

Comment 8 by Palacee_hun (in reply to comment 7) on 2012-01-02 23:00
That's partially why I suggested to implement this modification on a clone script of the "left mouse button lock toggle" script turning it into a simple "drag and drop" script. I think this would not introduce any confusion and inconsistency, maybe only a bit of redundancy. In this way existing scripts wouldn't change, only users would have a more convenient drag and drop facility if they wished to make use of it.
[to [comment:7 jteh]([BR]]
Replying):

I'll grant that this reduces the procedure from four keystrokes to two. However, it also introduces redundancy, inconsistency and potential confusion. The user already has to learn how to route the mouse to left click, right click, etc., so why should drag/drop be any different?

@jcsteh #1755 (comment) responds to your initial doubts about whether or not drag-and-drop requires simplification. Is the cited comment cogent or do you still maintain that this ticket should be closed as a wontfix?

This is still arguably redundant. Having said that, I've seen quite a few users struggle with these concepts; it just doesn't feel natural and I guess it's a lot to think about. Also, I've seen a few other problems with this over the years:

1. Some apps freeze or misbehave in terms of accessibility when you lock the mouse button. If I recall correctly, iTunes is one example, but I'm pretty sure I've seen others too.
2. The fact that the lock left mouse button command involves the shift key seems to interfere with dragging in some apps; e.g. dragging icons on the Windows Taskbar. I guess it gets interpreted as a shift+click, which might have different behaviour.

So, I don't think the implementation proposed earlier will work because of the freeze issue I mentioned in 1). I think we're going to need a separate command for this. Rough thoughts:

1. The first press should mark for drag but not actually start it.
2. The second press should begin the drag and then drop where it was pressed.
3. Rather than just performing all the actions in quick succession, there will need to be some additional mouse movements and delays to stop some apps just treating this as a click. Dragging users to channels in Mumble is one example where this is necessary.
4. If the user marks for drag by mistake (step 1), they can press it again at the current location to cancel.

Marking as feature.

Actually, the mouse dragging feature currently implemented is quite ok in my view. It works prety well in applications where the mouse can be routed reliably to the focus (i.e. internet explorer, Windows explorer, Firefox etc.). In my view mouse routing without using the mouse at all is quite inefficient. This is how I deal with this in Windows 10:

1. Open for example a web application in INternet explorer which allows dragging files into it
2. Open a windows explorer window
3. Focus the windows explorer window with NVDA
4. Press windows+left arrow key multiple times to drag the windows explorer window to the left side of the screen
5. After step 4 you will be automatically placed into the taskbar where you can chose with arrow keys a window which should be displayed to the right side of the screen
6. Press enter on the window that should be placed on the right side (in this case the internet explorerer window with the web app)
7. Now you have two windows visible on the screen (Windows explorer on the left, Internet explorer on the right)
8. Switch with alt+tab to the window from which you want to drag the file
9. Route the mouse with the coresponding command to the file
10. Now use the mouse and press left click, then drag the mouse to the window where you want to move the file (i.e. from left to right, meaning from Windows explorer to the web app) and release the left click after finding the region where you want to drop the file.

It is not a simple solution, but it works really nice after exercising abit.

Imo the only way that would make this process more agile would be to implement a customized dialog into NVDA which would let you to choose the application and the region you want to drop the file into. The process would look like this:

1. Open a folder with files
2. Press a shortcut on a file to open the NVDA drag 'n drop dialog. NVDA would find automatically the applications currently running which support dragging and dropping files.
3. Chose an application from the dialog and pres tab
4. You would land into a list of regions in the opened windo of the coresponding application in which you can drop files
5. Press enter on the region and the file will be droped there.

The biggest problems are the following:

• This should not depend on the mouse cursor, otherwise we have big inconsistencies in different applications. Means this should work through an alternative way (i.e. a dedicated API or so)
• NVDA needs to recognize automatically applications and regions in currently opened windows which allow dragging and dropping files. In many applications this property is not exposed at all
• NVDA needs to fetch a title for the regions where you can drop files (i.e. name of folders, a certain table etc.)

cc: @JulienCochuyt maybe you have some helpful thoughts on this as well.

IMHO attempting to automate too much detection of drop regions and proper disposition of windows is a huge work with tons of reasons to fail and uselessly block the user.
The steps described in #1755 (comment) are tedious but hardly avoidable in a safe and generic way.
Still, I agree we could come up with something more user friendly than the current process, especially regarding drag & drop with modifiers (eg. right button drag & drop with control key held, etc...).
Based on #1755 (comment), I'd propose:

• A single command to mark the drag origin and the drop destination.
• First press marks the drag origin and informs of it.
• Navigate by usual means to the drop destination.
• Second press marks the drop destination.
• If the drag origin is not visible any more, the user is informed and the whole operation canceled.
• Otherwise, the user is prompted by a speech and braille message (no interfering dialog or menu) of the form:
  "Drag&drop: Press left, down or right arrow to select the mouse button or press escape to cancel"
• Scanning of keys pressed in response should accommodate for allowing holding down modifiers.
• If NVDA detects the operation fails (ie. the mouse cursor turned into a no entry shape), the user should ideally be informed.

I think this approach would be nice, however this also assumes that NVDA moves the mouse from an application into another by itself. This will fail in many instances due to missing object location coordinates, offsets and what not. I think an alternative API handling this specific drag 'n drop process is a better choice in the long term. However, I don't really have any idea on how this should be acomplished consistently. I think UIA defines drag 'n drop properties if I am not wrong, so at least between applications with UIA support this should work via the API without routing a mouse to a certain region. But I am not sure how this exactly works.

Another approach to simplify this could be as follows:

1. Add the possibility to interact with the mouse directly via the numpad or the arrow keys (take the example from the addon golden cursor). For example nvda+num1 and num7 or nvda+home and nvda+end in laptop layout, changes the navigation between object review, document review, screen review and mouse review.
2. Define the keys for mouse interaction in mouse review, i.e.

• NVDA+arrow keys for laptop layout or numpad keys for desktop layout to move the mouse cursor also visually
• NVDA+enter or numpad enter performs one left mouse click, double enter performs double click, tripple enter locks or unlocks the left mouse key
• NVDA+context menu key performs a right mouse click
  Note: these commands would work only in mouse review mode.

This approach would have following advantages:

• It is consistent with what we have already for object navigation or screen review
• It would allow for more features (i.e. reporting of mouse coordinates, etc.).

@Adriani90, a "mouse cursor" is definitely a needed feature in NVDA, but IMHO it would not solve the issue altogether. It might be of some help in navigating from drag location to drop location, but ineffective in supporting drag&drop with modifiers or working around UI that do not emit AT events while the mouse button is kept pressed.

Hi,

As of NVDA 2022.4, UIA drag and drop state and properties are supported and announced if appropriate (see #12271).

Thanks.

@josephsl - do you think this issue can be closed then?