Currently synthesizeDragStart and synthesizeDrop hard-code the coordinates and coordinate stepping to be used (2, +9). This may be fine for the elements they are currently used for (e.g. Firefox Download Manager richlistitems) but it's not flexible enough for other cases, e.g. trees (see below). synthesizeMouse OTOH allows to specify x and y coordinates. The drag&drop functions should optionally allow that, too. Specifying the stepping should probably also be allowed for complete flexibility. Concerning the tree use case: Tree contents are created dynamically. Tree rows and cells cannot be accessed directly using getElementById (because they do not exist as actual elements in the first place). However, cell coordinates can be found through tree.treeBoxObject.getCoordsForCellItem. If the drag&drop test functions can be passed these coordinates, drag&drop can be tested in trees. Example: bug 192728 (SM port of FF bug 462172) needs a test. Unlike the FF Download Manager, SM's Download Manager is tree-based. Thus the above requirement. I already have a test for bug 192728 ready, but this one blocks it. Attached you'll find a patch that implements my suggestion. All additions are optional so existing callers need not be adapted. I included some cleanup since the parameter ordering in the comments was partially wrong.

Comment on attachment 434310 [details] [diff] [review] patch You shouldn't need to change synthesizeDrop; the synthesized mouse events are only used to get a useful 'dataTransfer' object to pass to the other drag events. Also, the 'step' argument shouldn't be needed. The threshold to start a drag is the same for all elements (5 or 8 pixels depending on platform).

Addressed review comments (thanks!)

Pushed as: http://hg.mozilla.org/mozilla-central/rev/09a3a8d02702