866951 - Drag and drop of email to a mailbox folder gets dropped before release of left mouse button

Status: RESOLVED WORKSFORME

(Thunderbird :: Untriaged, defect)

Description

[Pieter van Vliet]

User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)
Build ID: 20130409194949

Steps to reproduce:

Since I upgraded to version 17.0.5 I often see strange behavior when I attempt to drag and drop email(s) from my Inbox into local TB mail folders. I also see this strange behavior when moving (sub)folders around using the drag and drop method.

I am now forced to use "Message --> Move to" which is much slower to work with.


Actual results:

The email(s) I want to move from a folder (e.g. Inbox) using the drag and drop method get suddenly dropped in a folder the cursor passes over while I haven't released the left mouse button yet. What is worse, a folder gets selected and the whole folder is now being moved to another folder. This creates havoc very quickly.


Expected results:

When I drag and drop one or more emails those emails should not be dropped into any folder until I have positioned my cursor on that destination folder AND I have released the left mouse button.

Comment 1

[WADA:World Anti-bad-Duping Agency]

When Drag of mails, following may occur.
(0) At move/copy sorce folder, select mails => highlighted
(1) Start Drag => dragstart event is raised at move source folder
(2) upon mouseover of a expanded folder for a while,
    folder is highlighted to indicate expanded,
    in order to provide a way to Drop not-shown folder.
(3) upon mouseover of a collapsed folder for a while,
    if folder is selectable as move target,
    folder is highlighted to indicate "folder is selectable",
    and mouse pointer is changed to "not selectable" to 
    "selectable(move)" or "selectable(copy)".
(4) upon mouseup at the selected folder(==Drop event after dragstart),
    "Move mails" or "Copy mails" is ivoked.

Can you describe detailed(step by step) state transition of folder at Folder pane, mouse cursor, Error Console message, status bar message etc. with your operation?    

Because mouse events is affected by mouse driver settings, very short delay in mouse button states detection may produce "false mouseup".
Is your mouse driver(or touchpad driver) setting appropriate?

Comment 2

[Pieter van Vliet]

(In reply to WADA from comment #1)
> 
> Can you describe detailed(step by step) state transition of folder at Folder
> pane, mouse cursor, Error Console message, status bar message etc. with your
> operation?    
> 
> Because mouse events is affected by mouse driver settings, very short delay
> in mouse button states detection may produce "false mouseup".
> Is your mouse driver(or touchpad driver) setting appropriate?

There is really nothing I can add.
1. I select the email(s) from the summary (for example Inbox).
2. Left click on selected emails and keep mouse down.
3. As I move my mouse the cursor changes between "not selectable" and "selectable" and folder opens when mouse is over a selectable folder. At the same time a feint image of the selected emails is shown.
4. Today I tried for almost an hour to reproduce the problem repeating step 3 over and over. During that time twice the feint emails image suddenly disappears and was replace by a feint folder name that is about one or two folders away from the folder in which the emails were dropped.
5. I definitely did not released the left mouse button.
6. Status bar: no messages.
7. Error console: only messages related to dictionaries.
8. Control panel, mouse setting: has no settings related to drag and drop.

I use Logitech M110 wired optical mouse via USB, and Microsoft's driver version 6.1.7600.16385 since my system was built in Aug 2011. 

In the days leading up to the date/time I reported the presumed bug I got a failure 6 to 7 times within half an hour. Cannot explain why so few failures today. Nor can I explain why no failures before version 17.0.5. I upgraded from 17.0.4 to 17.0.5 about a month ago.

I use drag and drop a lot in text editing and also in moving files around in Windows Explorer and have never seen these failures there.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to Pieter van Vliet from comment #2)
> There is really nothing I can add.

Never "nothing". Following is very important observation.
> and was replace by a feint folder name that is about one or two
> folders away from the folder in which the emails were dropped.

After Drop at a folder in Folder Pane, "selected move target folder" is notified to process for "move mails from move source folder by drag&drop at Thread Pane". IIUC, "folder selection at Folder Pane" is "row number in Folder Tree at Folder Pane", and it is finally converted to Internal Folder URI or msgFolder object.

Did "automatic folder expansion" occur at Folder Pane during Drag&Drop when your problem happened?

Do you use add-on which is relevant to https://bugzilla.mozilla.org/show_bug.cgi?id=866951Folder Pane display?
  For example, sort folder in folder pane in any order,
  hide folder at folder pane, add separator in folder pane, ...
Do you have Search Folder under the move target account?

Where was Dropped folder position in Folder Pane?
  x & y of mouse position -> row number in folder pane
  may be affected by rounding error in pixel calculation

Comment 4

[Pieter van Vliet]

Attachment: Shows my main folder structure to help explain where problems occur.

Comment 5

[Pieter van Vliet]

(In reply to WADA from comment #3)
 
> Did "automatic folder expansion" occur at Folder Pane during Drag&Drop when
> your problem happened?

I don't remember, but will keep an eye on that next time it happens again.

> Do you use add-on which is relevant to
> https://bugzilla.mozilla.org/show_bug.cgi?id=866951Folder Pane display?
>   For example, sort folder in folder pane in any order,
>   hide folder at folder pane, add separator in folder pane, ...

No.

> Do you have Search Folder under the move target account?

No.

> Where was Dropped folder position in Folder Pane?
>   x & y of mouse position -> row number in folder pane
>   may be affected by rounding error in pixel calculation

Yesterday the first time it it dropped the email in the 9th subfolder under Friends, and pickup the 7th subfolder under Friends.

The second time it dropped the emails (I had three selected) in the Business folder and picked up the Outbox folder. (see also attachment)

Two other comments I like to make.

The folder symbol in front of the (sub)folders is normally closed. I need to hoover over a folder for about a second to have the symbol change to an open folder and it opens the list of subfolders if there are any. However, when I work quickly I can drop an email in a folder with the closed folder symbol and after the drop the symbol does not change to the open folder symbol.

When I was experiencing 6 to 7 failures I did have a few occasions where a folder was picked up without the email(s) being dropped. The email(s) were still in the source folder. Most likely that was during the "non selectable" state. So, coming to think about this I have observed the failures during both "selectable" and "non selectable" state.

Finally, although I am not experiencing any mouse problems during any other activities I do on my PC (CAD, Windows Explorer, etc.), I was wondering what if the mouse itself is causing these problems and what should happen to get the observed sequence of events.

I am hoovering over the folder pane. Button up is detected, when in "selectable" state email(s) are dropped in that folder, and when in "non selectable" state email(s) stay in source folder. Next button down is detected and the (sub)folder under the cursor is selected. The obvious condition that can cause that is when I let go of the button for a fraction of a second. Question is, are there any other mechanical events that can cause a temporary button up?

Comment 6

[WADA:World Anti-bad-Duping Agency]

FYI.
Drop event at folder tree is processed by ftv_drop.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#592
> 592   drop: function ftv_drop(aRow, aOrientation) {

When Drag%Drop of folder, following is perhaps executed.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#608
> 608     if (Array.indexOf(types, "text/x-moz-folder") != -1) {
When Drag&Drop of messages, following is perhaps executed.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#641
> 641     else if (Array.indexOf(types, "text/x-moz-message") != -1) {

During Drag, following occurs on non-Dropped folder.  
When mouse is moved on a folder.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#703
> 487   canDrop: function ftv_canDrop(aRow, aOrientation) {
When mouse is moved out from a folder.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#703
> 703   _onDragOver: function ftv_onDragOver(aEvent) {
> 704     this._currentTransfer = aEvent.dataTransfer;
> 705   },

In multi-CPU environment, following may occur.
   Folder-X, two above Drop target     Folder-Z, Drop target
     Mouse over occurs
       canDrop is executed         
     Mouse out occurs
                                         Mouse over occurs
      CPU-2                                  CPU-1
                                           canDrop is executed
                                         Mouse up occurs
       onDragOver is executed
                                           drop is executed

Anyway, to rule out unwanted mouse hardware/setting related problems, do next please.
- If "File open by Single click" is enabled in Folder Options of
  Windows Explorer, change to "File open by Double click".
- Use newest mouse driver provided by Logitec.
  Many of mouse driver relevant problems is around scroll button/wheel,
  and your mouse doesn't have scroll button(middle button only),
  so I don't think this is driver related problem.
  However, rule out of driver related problem is needed in this kind of
  problem.

Comment 7

[Pieter van Vliet]

(In reply to WADA from comment #6)
> Anyway, to rule out unwanted mouse hardware/setting related problems, do
> next please.
> - If "File open by Single click" is enabled in Folder Options of
>   Windows Explorer, change to "File open by Double click".

Was already set to "File open by Double click".

> - Use newest mouse driver provided by Logitec.
>   Many of mouse driver relevant problems is around scroll button/wheel,
>   and your mouse doesn't have scroll button(middle button only),
>   so I don't think this is driver related problem.
>   However, rule out of driver related problem is needed in this kind of
>   problem.

Although Microsoft claimed that the drivers were up-to-date, I let DriverManager upgrade the Logitech mouse driver to version 5.50.80.0. This is mainly to support the tilt-wheel aspect of the mouse and has nothing to do with drag&drop.

So far not seen anything unusual in drag&drop in TB. I will report as soon as I see something unusual again.

Comment 8

[WADA:World Anti-bad-Duping Agency]

Another concern : Wrap of QueryPerformanceCounter value
QueryPerformance Counter(QPC) uses RDTSC, and Tb uses QPC in timer routine. Because of high resolution timer, wrap may occur frequetly. In Tb's timer routine, Wrap of the counter, PC clock change to past by user etc. is not fully handled well yet, even though it's improved pretty much already.
If this kind of problem is relevant, it may affect on scheduling of "many events during very short period", and "quick Drag and quick Drop at folder pane" is an example of such "many events during very short period".

"Dragging speed" can be reduced if Tb's window is zoomed in.  
   layout.css.devPixelsPerPx = 1.1 (default=1.0)
   (same effect as Zoom size = 110%)
Can you easily reproduce your problem with larger devPixelsPerPx than 1.0 by ordinal your Drag&Drop operation?
How about with "smaller devPixelsPerPx than 1.0"?

About phenomenon of "schedule of Drop on non-selectable one, then nothing is done" which you saw.
With layout.css.devPixelsPerPx = 1.05, following was observed.
  Folder is layouted like next at folder pane.
  - FolderA (selectable)
  - spacer between FolderA and FolderB
  - FolderB (selectable)
  When mouse is on "spacer between FolderA and FolderB" during Drag,
  mouse cursor is changed to "non-selecable".
I guess Drop event was scheduled on this "spacer".

Comment 9

[Pieter van Vliet]

(In reply to WADA from comment #8)
> "Dragging speed" can be reduced if Tb's window is zoomed in.  
>    layout.css.devPixelsPerPx = 1.1 (default=1.0)
>    (same effect as Zoom size = 110%)
> Can you easily reproduce your problem with larger devPixelsPerPx than 1.0 by
> ordinal your Drag&Drop operation?
> How about with "smaller devPixelsPerPx than 1.0"?

I have not seen any significant changes (good or bad) when I changed layout.css.devPixelsPerPx to 1.1 and later to 0.9, other then increased size and decreased size of text and spacing.

However, the upgrade to Logitech driver 5.50.80.0 (see comment 7) and the associated SetPoint 6.5.1 addition for tilt-wheel support does seems to impact cursor performance, i.e. it is more sluggish (slow responding). Granted this is very subjective on my part, but one develops a feeling for ones own system.

Last night I created two subfolders (X and Y) under the Business folder and I put three emails in subfolder X. Subsequently I decided to move subfolder X under subfolder Y. A common activity to organize my emails in a structured fashion. It was then that I noticed that moving subfolder X around was very sluggish; my cursor with the subfolder X was easily 2 folders away from a highlighted folder where the cursor had passed over. Moving over the folders faster made that distance 6 to 7 folders away and once folder highlighting even stopped! I was able to reproduce the problem 5 times, 4 times subfolder X remained in its source position but a folder was picked up, and 1 time subfolder X was dropped in a folder where it should not have been dropped and another folder was picked up.

Notes:
1. I did not do a straight move, but moved around several times along the list of potential drop-to folders. Definitely faster then my usual speed of working.
2. All this moving around was done only in the folder pane.
3. TB was the only active program, other than the normal Windows 7 background programs and Norton Internet Security.
4. I should not have performance issues as my system uses a new motherboard with 3.2 GHz Intel i7-960.

I have seen this slowness before and that wi the reason that I stayed with the original Microsoft drivers for the mouse rather than the Logitech one. As soon as we are done testing the Logitech driver (and SetPoint) will be uninstalled again.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to Pieter van Vliet from comment #9)
> However, the upgrade to Logitech driver 5.50.80.0 (see comment 7)
> and the associated SetPoint 6.5.1 addition for tilt-wheel support
> does seems to impact cursor performance,
> i.e. it is more sluggish (slow responding).

SetPoint is utility and such utility usually has capability to change many mouse driver's behaviors. For example, optimize double click speed, swap right click button and left click button.
If utility has setting relevant to dragging, try with different setting from default, or different one from setting inherited from MS Win's mouse driver.
Note: My TouchPad utility/driver has setting for "Pointer Speed" and has feature called "Slow Motion" on mouse move.

> my system uses a new motherboard with 3.2 GHz Intel i7-960.

4 Core, 2 Threads per Core => 8 Threads, 3.2 GHz, with Intel QPI
> http://ark.intel.com/products/37151
If multi-CPU/multi-tasking relevant problem, it's perhaps easily exposed in Mozilla, because Mozilla is originally implemented on *nix but MS's applications are originally implemented for MS DOS or System x of Mac which never had concept of multi-tasking, virtual memory etc.
And, wrap of TSC occurs far frequently than my Core2 Duo 1.66 GHz.

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to Pieter van Vliet from comment #9)
> I have not seen any significant changes (good or bad) when I changed
> layout.css.devPixelsPerPx to 1.1 and later to 0.9,
> other then increased size and decreased size of text and spacing.

If larger devPixelsPerPx like 1.15, you may see phenomenon like next easily.
  Folder is layouted like next at folder pane.
  - FolderA (selectable)
  - spacer between FolderA and FolderB
  - FolderB (selectable)
  When mouse is on "spacer between FolderA and FolderB" during Drag,
  move mouse very few pixels to bellow, and make FolderB highlighted.
  Repeat "move mouse", and confirm "a pretty small mouse move" changes
  mouse pointer state from "space is non-selectable" to "FolderB" is
  highlighted(selected) or vice versa.
  At this status, Do Drop action(Click button up in your case).
Because my finger moves upon the "Drop actin" which is "taking off button + taking off finger at TouchPad" in my case, I could see "nothing is done by Drop" because spacer was selected by my　Drop　operation.

If "very quick Drag and very quick Drop", Drop may occur around edge of an XUL element.
Check with following in your Drag&Drop test, please.
(1) When move target folder is changed to "highligted"(selected),
(2) Confirm that mouse is placed at near center of "move target folder"
    at Folder Pane,
(3) Do deep breathing,
(4) Do "Drop" action on the "move target folder"
Can you still easily reproduce your problem with above (2) & (3)?

Comment 12

[WADA:World Anti-bad-Duping Agency]

Following is mouse related XUL DOM events.
> https://developer.mozilla.org/en-US/docs/XUL/Events
> Inherited DOM events
>   click
>   dblclick
>   mousedown
>   mousemove
>   mouseout
>   mouseover
>   mouseup
>   select : This event is sent to a listbox or tree when an item is selected.
> Common XUL events
>   command : This event handler is called when an element is activated.
>   drag
>   dragdrop
>   dragend
>   dragenter
>   dragexit
>   draggesture
>   dragover

As for Drag&Drop of messages to a folder, following occurs.
>
>     Folder Pane                           Thread Pane
>                                             After selection of some mails, Start Drag
>                                             => draggesture
>      Upon first mouse over on FolderA
>      => dragenter at Row-A
>      After a while at FolderA
>      => dragover
>         Handler should return selectable or not
>      Upon mouse out from FolderA
>      => dragexit
>                                            During Drag
>                                            => drag is invoked several times in second
>      Upon first mouse over on FolderB or ElementB
>      => dragenter at Row-B
>      After a while at Row-B
>      => dragover
>         Handler should return selectable or not
>      By Drop action
>      => dragdrop
>         Handler should do required action
>      After end of Drop
>      => dragover
>                                            After completion of Drag&Drop
>                                            => dragend

In your case, following occurs.
  Mouse over on Folder(N-2) at tree Row-(N-2)
     => mouse pointer == Selectable
     => Folder(N-2) is higlighted
  Mouse over on spacer under Folder(N-2)
     => Folder(N-2) returns to not-higlighted
     => mouse pointer == non-Selectable
  Mouse over on Folder(N-1) at tree Row-(N-1)
     => mouse pointer == Selectable
     => Folder(N-1) is higlighted
  Mouse over on spacer under Folder(N-1)
     => Folder(N-1) returns to not-higlighted
     => mouse pointer == non-Selectable
  Mouse over on Folder(N) at tree Row-N
     => Folder(N) is higlighted
     => mouse pointer == Selectable
  Drop action at Folder(N)
  => "dragdrop" event should be executed on Folder(N),  
     however, "Move mails" action was done on Folder(N-2).
Because Folder(N) is highlighted just before Drop, "dragover"event is actually scheduled and executed for Row-N, Folder(N) correctly.
So, I suspect that screen-x and screen-y value, or tree Row number, which is held in Tb's object for dragging, is changed to position of Row-(N-2)/folder(N-2) just before scheduling of "dragdrop" event at XUL element placed in tree Row-N.

Comment 13

[WADA:World Anti-bad-Duping Agency]

FYI.
After Copy/Move of mail(s) by Drag&Drop, target folder, copy or move, is saved in last_msg_movecopy_target_uri and last_msg_movecopy_was_move.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#659
> 659       prefBranch.setCharPref("last_msg_movecopy_target_uri", targetFolder.URI);
660       prefBranch.setBoolPref("last_msg_movecopy_was_move", isMove);
Checking these prefs.js entry before & after Drag&Drop may help your test.

Comment 14

[WADA:World Anti-bad-Duping Agency]

FYI.
As I wrote before, "drop event while dragging at Folder Pane tree" is processed by next code. 
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#592
> 592   drop: function ftv_drop(aRow, aOrientation) {
> 595     let targetFolder = gFolderTreeView._rowMap[aRow]._folder;
> 597     let dt = this._currentTransfer;
Data for "Drag Source"(it's "messages selected at Thread pane" in our case, and is always saved to this._this._currentTransfer by onDragOver handler from Event.dataTransfer, Data for "Drag Source" is always accurate in our case.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#703
> 703   _onDragOver: function ftv_onDragOver(aEvent) {
> 704     this._currentTransfer = aEvent.dataTransfer;
> 705   },

As seen in code, "XUL ondragdrop mouse event" is not directly processed by drop:(function ftv_drop) of folderPane.js.
Because "folder two rows above" is selected as "move target folder" in your cace, I can't imagine other case than "wrong row number" is passed to drop:(function ftv_drop) of folderPane.js.

XUL mouse events for Drag&Drop at Folder Pane is processed by layout/xul/tree/nsTree????.cpp modules for "XUL treeView", and "row number of cell where Drop while Dragging occurs" is passed to "drop()" of folderPane.js from nsTreeBodyFrame.cpp.

In nsTreeBodyFrame.cpp, "CreateTimer" is used only when "tree expansion" occurs. All other reference to "mSlots->mTimer" is for "cancel timer if timer is requested". 
> http://mxr.mozilla.org/comm-central/source/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp#2659
> 2659               CreateTimer(LookAndFeel::eIntID_TreeOpenDelay,
> 2660                           OpenCallback, nsITimer::TYPE_ONE_SHOT,
> 2661                           getter_AddRefs(mSlots->mTimer));
Similar timer use perhaps exists for "tree scrolling".

If timer related problem, and if your problem occurs only when "folder expansion" occurs or "folder scrolling" occurs during Drag, this timer use and "wrap of TSC = Wrap of QueryPerformanceCounter" may be relevant to your problem.

Comment 15

[Pieter van Vliet]

(In reply to WADA from comment #11)
> 
> If larger devPixelsPerPx like 1.15, you may see phenomenon like next easily.

If have been using the 1.15 setting since morning of May 4th. I don't like it at all as it slows me down, because the subfolder list of some of my main folders do not fit in the folder pane anymore and hence requires scrolling of the folder pane to get to the target folder.

Got a very unexpected problem during a "normal" drag & drop. It involved scrolling the folder pane and suddenly everything froze. A folder I moved over was permanently highlighted. I could move the cursor, but nothing reacted to the cursor moving over folders or otherwise. Released the mouse button outside TB and no harm was down. Stopped/started TB and everything was normal again.

> If "very quick Drag and very quick Drop", Drop may occur around edge of an
> XUL element.
> Check with following in your Drag&Drop test, please.
> (1) When move target folder is changed to "highligted"(selected),
> (2) Confirm that mouse is placed at near center of "move target folder"
>     at Folder Pane,
> (3) Do deep breathing,
> (4) Do "Drop" action on the "move target folder"
> Can you still easily reproduce your problem with above (2) & (3)?

See above freezing. So far not reproduced original problem or the freezing. Did not do much work either due to other weekend activities.

I do notice that after I select the email(s) for the drag & drop the vague image of the first mail is now very narrow and the text cannot be read anymore!

Comment 16

[Pieter van Vliet]

(In reply to WADA from comment #13)
> FYI.
> After Copy/Move of mail(s) by Drag&Drop, target folder, copy or move, is
> saved in last_msg_movecopy_target_uri and last_msg_movecopy_was_move.
> > http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#659
> > 659       prefBranch.setCharPref("last_msg_movecopy_target_uri", targetFolder.URI);
> 660       prefBranch.setBoolPref("last_msg_movecopy_was_move", isMove);
> Checking these prefs.js entry before & after Drag&Drop may help your test.

Thanks, that might help to more accurately determine what happens when I have the problem.

Comment 17

[Pieter van Vliet]

(In reply to WADA from comment #14)
> 
> If timer related problem, and if your problem occurs only when "folder
> expansion" occurs or "folder scrolling" occurs during Drag, this timer use
> and "wrap of TSC = Wrap of QueryPerformanceCounter" may be relevant to your
> problem.

I believe I follow your reasoning.

For the time being I keep Logitech driver installed.
Keep devPixelsPerPx = 1.15
Monitor last_msg_movecopy_target_uri and last_msg_movecopy_was_move to capture info when a failure occurs.

I will report again when I have a failure again.

Comment 18

[WADA:World Anti-bad-Duping Agency]

Attachment: Trace data example of canDrop: call and drop: call by folderTreeView by Drag&Drop

This is trace data obtained by my small add-on for Drag&Drop test.
> Replace original canDrop:, which is defined in folderTree.js and held in gFolderTreeView.canDrop.
>    Call original canDrop: with saving Return Code
>    Call routine of add-on, save trace data such as timestamp, parameters
>    Return saved Return Code to caller
> Replace original drop:, which is defined in folderTree.js and held in gFolderTreeView.drop.
>    Call original drop:
>    Call routine of add-on, save trace data such as timestamp, parameters
> After test, put saved trace data to Error Console,
> and restore original canDrop: and drop: to gFolderTreeView.canDrop and gFolderTreeView.drop.
If you want to check with my add-on, let me know.

Comment 19

[Pieter van Vliet]

(In reply to WADA from comment #18)
> If you want to check with my add-on, let me know.

Sorry about my delayed reply; I have been very busy the last few days.

Yes, I like to try your add-on.

BTW, I changed devPixelsPerPx back to 1.0. I had too much scrolling in the folder pane.

Secondly, while doing drag & drop I had twice a "frozen" situation where a folder was highlighted while the cursor passing over other folders did nothing.

Thirdly, one thing I did not think about, but I use as Appearance the Walnut Theme add-on. I have just switched to the standard Appearance that comes with TB, and will see if I have the same issues with that.

Comment 20

[WADA:World Anti-bad-Duping Agency]

(In reply to Pieter van Vliet from comment #19)
> Yes, I like to try your add-on.

I sent it to you in mail.

Comment 21

[Wayne Mery (:wsmwk)]

(In reply to WADA from comment #20)
> (In reply to Pieter van Vliet from comment #19)
> > Yes, I like to try your add-on.
> 
> I sent it to you in mail.

results?

Comment 22

[Pieter van Vliet]

The problem was in 17.0.5 and showed up often during testing as per WADA's instructions.

After I upgraded to version 17.0.6 the problem did not occur anymore. Right now I am on version 24.1.1 and everything is still okay.

Comment 23

[WADA:World Anti-bad-Duping Agency]

FYI.
My add-on for test didn't work as expected in Tb 24.
If my add-on replaces canDrop/drop handler and required modules on Tb 24.1.1, which worked as expected on Tb 17, Drag&Drop of folder was broken, and console log for canDrop/drop event was not written by module in add-on.
This was because "register/load of module" was done by this.Module_Name=function for my add_on; when canDrop/drop handler is called first time, and because call of the Module_Name was done via this.Module_Name(...) in canDrop/drop handler.
So, I changed the "register/load of module" code to explicit "gfolderView.Module_Name=function for my add_on;" and changed module call in canDrop/drop handler to explicit "gFolderView.Module_Name(...);", then my add-on worked as expected and console log was written as expected, and Drag&Drop worked well again even when my add-on replaced canDrop/drop handler.

This indicates that "'this' object of JavaScript in invoked canDrop/drop handler" is different between Tb 17 and Tb 24, and that the "'this' object of JavaScript in invoked canDrop/drop handler" is not gFolderView in Tb 24.
So, I can say that something relevant to Drag&Drop was changed between Tb 17 and Tb 24, and that "one of the something" is relevant to "'this' object of JavaScript in invoked canDrop/drop handler".

Comment 24

[WADA:World Anti-bad-Duping Agency]

(In reply to Pieter van Vliet from comment #22)
> The problem was in 17.0.5 and showed up often during testing as per WADA's
> instructions.
> After I upgraded to version 17.0.6 the problem did not occur anymore. 
If "problem showed up often only with my add-on" and "problem did not occur anymore after upgrade to version 17.0.6 without my add-on for test", and if "you didn't see problem in Tb 17.0.5 without my add-on", it may be due to fault in my add-on for test.

Did you see your problem in Tb 17.0.5 even without my add-on for test?

Comment 25

[Pieter van Vliet]

WADA,

See my starting topic: the problem manifested itself after I upgraded from 17.0.4 to 17.0.5. Subsequent testing was done only using 17.0.5 using the various versions of your add-on.

I removed your add-on before I upgraded to 17.0.6 (and later versions), and since then I haven't seen the problem anymore.

Comment 26

[WADA:World Anti-bad-Duping Agency]

Thanks for pointing your starting topic.
Following is correct?
  Tb 17.0.4(without my add-on) : Your problem didn't occur.
  Tb 17.0.5(without my add-on) : Your problem did    occur.
  Tb 17.0.5(with    my add-on) : Your problem did    occur.
  (I didn't see something bad with my add-on during I checked the add-on using Tb 17.)
  Tb 17.0.6(without my add-on) : Your problem didn't occur.
  Tb 24.1.1(without my add-on) : Your problem doesn't occur.
  (if you enabled trace of old my add-on on Tb 24, Drog&Drop would be broken always :-) )
If correct, even if something bad existed in my add-on, I can guess that my add-on simply increased frequency or probability of your problem by degrading Drag&Drop performance(to trace data, excess code steps are executed by my add-on during Drag&Drop operation).
If so, following can be used as valid data.
  Tb 17.0.4(without my add-on) : Your problem didn't  occur.
  Tb 17.0.5(without my add-on) : Your problem did     occur.
  Tb 17.0.6(without my add-on) : Your problem didn't  occur.
  Tb 24.1.1(without my add-on) : Your problem doesn't occur.

Anyway, do you think your this bug can be closed as WORKSFORME?
(problem due to flaw in code surely existed, but it's already resolved by unknown patch or change.)

Comment 27

[Pieter van Vliet]

Yes, this bug can be close as WORKSFORME.