1323427 - Vertical scrolling speed of folders tree not fair when trying to drag and drop mail(s) or bookmark(s)

Status: NEW

(Core :: XUL, defect, P5)

Description

[TREMBLAY,Bernard]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161129173726

Steps to reproduce:

Drag and drop a mail from list (or search window) to a folder into tree which is not visible, this using auto scroll when mouse is out of tree above or under the folder array.
This starts a scroll which can show the searched folder. 


Actual results:

The scroll starts most of time but not softly, by important steps, too quickly (unable to read list).
If accidentally a "mouseup" is performed the mail are drop into an unknown folder.
Folders closed are opened and displayed if the user stops on it (suitable), but the scroll remains active which adds to difficulty to drop in right way


Expected results:

When mouse (pointer) reach the above or under list zone the scroll begins slowly but never try to get back the missed scrolled zone if the computer have needed time to begin.
I explain : everything happens as if the height of scroll was calculated from the time the mouse is "seen" out of zone, but if it not start, after a while the scroll when began will perform suddenly a jump. The scroll must begin when the mouse is seen out of zone, not when it was (the problem of detection)

The limit speed of scroll is out of capability of any reader and it is easy to have scrolled down and get the element above and again not visible. The change of direction doesn't change the speed. Up and down it is impossible to drop the elements.

It should be impossible to drop with "mouseup" if scroll is not stopped since a while and the icon "drop here is possible" shown.

Another problem occurs, if the target folder is closed, after a while it will be opened. But in such case the target can be still not visible (under the list) and the same problem restarts.

When badly dropped the lonely solution is to remember data of the mail(s) and use search to find where the are now, select again...

The other ways and workaround to perform this are :
- use "quickfolders"
- open the target into folder tree before perform the drag and drop then don't use the feature

This is an enhancement of ergonomy, not a pure bug
Best regards

Comment 2

[TREMBLAY,Bernard]

Hi,

I partially agree because the origin and thematic is the same, but the description and details of feature that I give are much more advanced (and have needed test to understand the details).

Particularly :
- the fact that during scroll the drop remains activated
- the problem of the opening of folders (I precise that when opening the position of parent doesn't seem stable, develop under a fixed position, but while scrolling this generates a jump)
- the start-stop delay 
- the detection of position of mouse which should begin-stop the scroll and the speed (with a maximum for readability) depending of the distance between mouse and the edge of the tree panel. If the speed depends directly of the distance the scroll is jerky.

With what I describe the development can easily check described behavior and correspondence with the code details, not with the 833443 (that I had seen but not consider as duplicate) and maximum "speed" is just one parameter of the problem.
Solving 833443 is just a little part of the whole feature which need enhancement.

Note : As I had by the past to develop such function (in a time when everything had to be written with low levels languages) I could analyze more accurately the problem

Comment 3

[TREMBLAY,Bernard]

Please read my previous comment sent after the classification as "resolved" "duplicate".
After reading you could confirm the identity of the subject.

Even exists obviously a common phenomenon the content of the exposure of the problem and content are not at all the same.

Comment 4

[Wayne Mery (:wsmwk)]

Adding 3people who probably have some insight

Comment 5

[Wayne Mery (:wsmwk)]

You may be describing thie issue in more detail, but fundamentally I believe this is bug 833443.

Comment 6

[Wayne Mery (:wsmwk)]

(Given that this describes the issue(s) more clearly, I am reversing the dup direction)

What is the major sensitivity/issue/component here?  rdf, d&d?

(taking a stab that gijs might know)

Comment 8

[Richard Marti (:Paenglab)]

Huh,I can't say at all what does or where the speed is set. Let's hope Gijs can.

Comment 9

[:Gijs (he/him)]

As far as I can tell this is an issue with scrolling in <tree>s. I don't see any special handling for `dragover` events in the JS in Thunderbird, and the same thing happens e.g. in Firefox's bookmarks manager (library) when dragging a bookmark to that tree. I expect this means it's a XUL issue. Enn, can you confirm?

Comment 10

[Neil Deakin]

Yes, this is done in nsTreeBodyFrame::ComputeDropPosition and nsTreeBodyFrame::LazyScrollCallback.

We should probably make it improve the algorithm along with improve ScrollFrameHelper::DragScroll so that both work similar.

Comment 11

[Wayne Mery (:wsmwk)]

Does the ball game change with Bug 464710 - Use folderPane.js to convert other rdf-trees to js

Comment 12

[:Gijs (he/him)]

(In reply to Wayne Mery (:wsmwk) from comment #11)
> Does the ball game change with Bug 464710 - Use folderPane.js to convert
> other rdf-trees to js

No, the library's tree doesn't use RDF.

Comment 13

[TREMBLAY,Bernard]

Hi,
I currently checked the drag and drop : if seems that the speed of vertical scroll is limited but the movement occurs by jerks.
It remains impossible to move a folder by drag and drop into a long list.

Because simple cut and paste doesn't exist it is quite impossible to manage an optimization of the organization of the folder tree.

Because more there is quite no way to find the folders into the tree (by declared keyword or more simply using chars chains (masks) for the folder name using in file finders since thirty years(c?*)) the user creates duplicate names with some variations, awful.

More we could imagine to use an external way to manage the tree, for example export xml format the folder informations, the previous extension is knw not compatible with the 60.4 version...

A dead lock ? :

• current workaround :

  • use quickfolders to localize folders

  • A JOKE : screencopy and print :
    (1) - screencopy the screen showing the tree (on an image tool like irfanview)

    • print on paper (near 100 hundred pages for the 30 accounts that I manage without archives) two exemplaries
    • stick together and get a papyrus of 30m long
    • find 5 persons to work on this job during one week
    • use on your knees on the floor into a long corridor to mark moving operation to perform
    • cut the second following instructions
    • paste on a clean new paper
    • create a new tree manually
    • move the mail form the old folder, for this find the folder
    • for this go to step (1) (while you have not ended)

Hope that one day we should be able to use cut-paste, copy-paste

Best regards
Trebly