948082 - Notifications disrupt drag and drop

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[Jochen De Smet]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018

Steps to reproduce:

Select one or more messages in a folder.
Start dragging those messages to another folder but do not drop yet
Wait for a new mail notification to pop up


Actual results:

Cannot drop messages even after popup fades out.  You have to unselect and reselect the messages again before you can drag and drop successfully


Expected results:

Drag and drop operation should not have been disturbed by the notification.

Comment 1

[Wayne Mery (:wsmwk)]

like bug 458570?

Comment 2

[Jochen De Smet]

Yup exactly like that. It's IMAP in my case as well. Guess you can mark this as a dupe.

Comment 3

[WADA:World Anti-bad-Duping Agency]

Tb's mail folder relevant code does do nothing on XUL Drag relevant event.

Rough Drag processing based on TreeView.
 1. Tb's folder tree view code is based on "Tree View" feature.
      Simply pass x/y position of each row in folder tree(or thread tree)
      to TreeView feature.
 2. When mouse event happens and if it's determined as "Drag" by XUL event processor,
    Dragstart, Dragover event etc. is firered at an row in TreeView, and is passed to Tb's
    folder tree view code(or thread tree view code).
 3. TreeView feature+Tb's tree view simply calls Tb's DragStart event handler, Dragover
    event handler etc., when Drag relevant XUL event hadler is kicked by XUL Drag event
    processor, with passing x/y of event, associated folder/MsgDBHdr etc. to the row.
    And, TreeView feature+Tb's tree view calls canDrop handler while Dragover processing.
    canDrop handler is called three times : drag is beeing on this row, drag is on this
    row, drag is being out of this row.
    Tb's tree view code changes the row to "selected status"(highlighted) in "Tree" if
    canDrop returns true when "drag is on this row" state, and changes the row to "not
    selected status"(not hihlighted) at "Tree" after caling canDrop with "drag is being
    out of this row" state.
    canDrop handler in Tb merely returns true(this row is droppable)/false(this row is non
    droppable), with checking folder name etc. which is associated to the tree row.
    And, when Drop event is notified to TreeView feature+Tb's tree view by XUL Drag event
    processor, drop handler is invoked, and Tb starts Tb's action defined for resource
    associated to the tree row which is folder at folder tree view and is MsgDBHdr at
    thread tree.
This is irrelevant to IMAP or POP, nor, folder or MsgDBHdr.
This is at least true in Tb 17 and Tb 24.
I don't know mechanism in Tb releases during 2008/2009/2010 is same as one in Tb 17/Tb 24, so I can say nothing about this bug is dup of bug 458570 or not, even if external symptom is absolutely same.

Screen shot says:
 1. At a row, Dragover event happens, and canDrop handler is called, 
    then the row is shown as "selected state"(highligted).
 2. At the row, status of "drag is on this row" is cleared, so the row is shown as
    "not selected state"(highligted).
 3. After it, 
 3-1. any Drag relevant event is not happens at folder tree
      after "new mail notification panel" is opened and closed,
      so nothing occurs at folder tree.
      (Drag events based on mouse events was stolen by "new mail notification panel")
 3-2. Or TreeView feature + Tb's tree view code forgets state of "Drag is in progress"
      after "new mail notification panel" is opened and closed.
      (Drag events processing in TreeView is interfered by "new mail notification panel")

If issue like 3-1, problem may be in XUL Drag processing code.
If issue like 3-2, fault may be in TreeView code + Tb's folder tree view code.

Jochen De Smet, is problem consistently reproducible?
If so, tracking Tb's activity by DragStart, Dragover, canDrop, drop handler may help problem analysis.

Because Tb's these handler code, which is written in JavaScript, is held in global variable in Tb's XUL main window, for example, in gFolderTreeView if folder tree, following is possible.
  Replace Tb's handler code by code like following.
    Write log data to Error console, call original Tb's handler,
    return return code from Tb's original handler to caller of this event handler.
And I have such code which is packaged as add-on, which can run on Tb 24(checked on Win-XP only), which I wrote for test of other bug report(bug 866951), which is for folder tree, thread pane.
Can you test with this code?

Comment 4

[Jochen De Smet]

Yes it happens consistently.

I looked in the other bug but didn't see an actual download link for your package. Where do I get it ?

Comment 5

[WADA:World Anti-bad-Duping Agency]

Package is not opened to public, as personal test purpose only. If you need, I'll send you in mail, or upload to my site. Can you test with it?

Comment 6

[Jochen De Smet]

Yes go ahead and send it over.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Quick look of your trace data sent to me.
You did at least following.
  Select mails at tread pane, Start drag at thread pane, dragover at some folders.
  alert is shown and closed.
  After a while, you clicked "1" button to see log by add-on.
Log.
  DragStart at thread pane, many canDrop at many rows in folder pane.
  After a while, DragStart at Thread pane, and end of log.
Why DragStart is invoked at thread pane again?
Similar to following?
1. You are executing Dragging.
2. Alert happens -> focus is moved to alert panel.
3. To click "OK", you have to stop Drag and move mouse position on "OK" button, click "OK".
   Or mouse position is moved to "OK" button automatically. You have to stop Dragging,
   then you click "OK" button.
4. In this scenario, if alert panel is automatically closed by someone before you stop
   drag operation, mouse position may be moved back to "drag start area",
   or "area or position where last click operation was done"(=="select mails" operation).
   This is "thread pane" in your test, then DragStart is invoked at thread pane 
   when you moved mouse.
5. Because you need to click "1" button to see log data, you stopped dragging.
When pop-up was shown and closed, where was mouse position moved by Tb/OS?

Comment 8

[WADA:World Anti-bad-Duping Agency]

What happens if "folder drag within folder pane"?
Click a folder at row=A, drag the folder, when dragover on row=M, popup is shown and closed.
After popup close, try to continue dragging.
From which row is dragging resumed?

It may be focusing issue.
Click at thread pane -> drag to folder pane -> dragging in folder pane
-> popup is shown, then focus is moved to popup -> popup is closed
-> focus is moved back to thread pane where last click happened
-> mouse event is passed to focused element -> for Tb, mouse pointer is on thread pane

Comment 9

[Jochen De Smet]

(In reply to WADA from comment #7)
> Why DragStart is invoked at thread pane again?

I think I had to try twice after enabling the tracing before the
issue happened.

> Similar to following?
> 1. You are executing Dragging.
> 2. Alert happens -> focus is moved to alert panel.
> 3. To click "OK", you have to stop Drag and move mouse position on "OK"
> button, click "OK".

There's no button, so nothing to click.  It's a notification, not an alert.

>    Or mouse position is moved to "OK" button automatically. You have to stop
> Dragging,
>    then you click "OK" button.
> 4. In this scenario, if alert panel is automatically closed by someone
> before you stop
>    drag operation, mouse position may be moved back to "drag start area",
>    or "area or position where last click operation was done"(=="select
> mails" operation).
>    This is "thread pane" in your test, then DragStart is invoked at thread
> pane 
>    when you moved mouse.
> 5. Because you need to click "1" button to see log data, you stopped
> dragging.

Well, I stopped dragging because it no longer had any effect, i.e. I tried to
release over the destination folder, but nothing happened.

> When pop-up was shown and closed, where was mouse position moved by Tb/OS?

Mouse didn't move.

Comment 10

[Jochen De Smet]

(In reply to WADA from comment #8)
> What happens if "folder drag within folder pane"?
> Click a folder at row=A, drag the folder, when dragover on row=M, popup is
> shown and closed.

Folder dragging doesn't appear to work at all. Trying to drag a folder shows the "circle with diagonal line" icon.

> After popup close, try to continue dragging.
> From which row is dragging resumed?
> 
> It may be focusing issue.
> Click at thread pane -> drag to folder pane -> dragging in folder pane
> -> popup is shown, then focus is moved to popup -> popup is closed
> -> focus is moved back to thread pane where last click happened
> -> mouse event is passed to focused element -> for Tb, mouse pointer is on
> thread pane

Comment 11

[Jochen De Smet]

I'm sending you another trace.  Here's the exact sequence of what I did:

1) Enable drag tracing
2) Select all mails in PROCMAILBACKUP folder (Ctrl-A)
3) Click "Get Mail->Get all new messages"
4) Start dragging the selected messages, hovering over "2008 Q1" folder
5) notification (unable to connect to server) pops up and disappears
6) mouse curses remained in place; it's still the drag cursor
7) drag cursors remains even when moving mouse over a non-droppable location
8) release mouse button, cursor returns to normal, drop does not happen

At this point, trying to drag the selected messages again does nothing at all.

Comment 12

[WADA:World Anti-bad-Duping Agency]

(In reply to Jochen De Smet from comment #10)
> Folder dragging doesn't appear to work at all.
> Trying to drag a folder shows the "circle with diagonal line" icon.
Did you test with "movable folder"?
example. "Inbox" can't be moved, so Tb returns false to canDrop if Dragged folder is Inbox.
         If dragged on Search Folder, Tb returns false to canDrop.
         If Offline mode, Tb returns false to canDrop for IMAP folder.
Was trace data normally written for the "drag a folder"?

Comment 13

[WADA:World Anti-bad-Duping Agency]

(In reply to Jochen De Smet from comment #11)
> 5) notification (unable to connect to server) pops up and disappears
> 6) mouse curses remained in place; it's still the drag cursor
> 7) drag cursors remains even when moving mouse over a non-droppable location
> 8) release mouse button, cursor returns to normal, drop does not happen
Key event(s) after step 5(popup hidden), before step 8(release mouse button), may help observation, because key event is invoked at focused element, and because it's perhaps independent from XUL Drag events which is based on mousemove after mousedown before mouseup.
- Tab, or Shift+Tab

Comment 14

[WADA:World Anti-bad-Duping Agency]

(In reply to Jochen De Smet from comment #11)
> I'm sending you another trace.  Here's the exact sequence of what I did:
> 1) Enable drag tracing
> 2) Select all mails in PROCMAILBACKUP folder (Ctrl-A)
> 3) Click "Get Mail->Get all new messages"
> 4) Start dragging the selected messages, hovering over "2008 Q1" folder
> 5) notification (unable to connect to server) pops up and disappears
> 6) mouse curses remained in place; it's still the drag cursor
> 7) drag cursors remains even when moving mouse over a non-droppable location
> 8) release mouse button, cursor returns to normal, drop does not happen

Following is last trace data.
After 26 seconds from last canDrop() call at folder pane row, onDragStart event is invoked again at thread pane.
> DateTime=2013/12/20 00:59:31.913 GMT, EventType=canDrop, ... aRow=38, ...
> DateTime=2013/12/20 00:59:57.615 GMT, EventType=ThreadPaneOnDragStart, ...
This is same as your first trace sent to me. I believe that you surely didn't do "Drag start operation at thread pane twice while tracing is active" in both tests.

Comment 15

[WADA:World Anti-bad-Duping Agency]

Second ThreadPaneOnDragStart() call may be by "XUL dragend event at drag source node" which was invoked upon "8) release mouse button"(==mouseup).
> https://developer.mozilla.org/en-US/docs/XUL/Events
If so, XUL Drag processor himself keeps "dragging state" after "5) notification", and TreeView/Tb's FolderTreeView doesn't forget "dragging state" at least for thread pane where drag was initiated even after "5) notification".

Tb's FolderTreeView(ftv) code can do nothing, if Tb/TreeView/XUL doesn't invoke XUL dragenter/dragover/dragexit event at folder pane row which corresponds to canDrop() call in ftv, and XUL dragdrop event at folder pane row which corresponds to drop() call in ftv.

Comment 16

[WADA:World Anti-bad-Duping Agency]

What happens if multiple messenger windows exist?
0. Open error console
1. At win-1, via account context menu, "Open in new window" -> win-2 is opened
2. At win-1, enable tracing, at win-2, enable tracing.
   (log is held in global JS variable of each messenger window)
3. At win-1, start drag at thread pane, hold at a folder in folder pane
4. popup notification is shown and is hidden
5. after it, continue drag, and move mouse to folder pane of win-2
6. finally, release mouse button, stop tracing at win-1, and stop tracing at win-2.
7. close win-2 by Alt+F4, if problem of "multiple windows are closed at once and re-opened by restart if multiple windows are opened" occurs.

Comment 17

[Jochen De Smet]

(In reply to WADA from comment #12)
> (In reply to Jochen De Smet from comment #10)
> > Folder dragging doesn't appear to work at all.
> > Trying to drag a folder shows the "circle with diagonal line" icon.
> Did you test with "movable folder"?
> example. "Inbox" can't be moved, so Tb returns false to canDrop if Dragged
> folder is Inbox.
>          If dragged on Search Folder, Tb returns false to canDrop.
>          If Offline mode, Tb returns false to canDrop for IMAP folder.
> Was trace data normally written for the "drag a folder"?

I'm not in offline mode. Folder dragging does not appear to work for any of my IMAP folders, and I don't have any non-IMAP accounts.

Comment 18

[Jochen De Smet]

(In reply to WADA from comment #13)
> (In reply to Jochen De Smet from comment #11)
> > 5) notification (unable to connect to server) pops up and disappears
> > 6) mouse curses remained in place; it's still the drag cursor
> > 7) drag cursors remains even when moving mouse over a non-droppable location
> > 8) release mouse button, cursor returns to normal, drop does not happen
> Key event(s) after step 5(popup hidden), before step 8(release mouse
> button), may help observation, because key event is invoked at focused
> element, and because it's perhaps independent from XUL Drag events which is
> based on mousemove after mousedown before mouseup.
> - Tab, or Shift+Tab

How do I capture key events?  I know I do not manually press any keys at all.

Comment 19

[Jochen De Smet]

Attachment: Trace requested in comment 16

Comment 20

[WADA:World Anti-bad-Duping Agency]

(In reply to Jochen De Smet from comment #18)
> How do I capture key events?
Not capture key event. Invoke key event.
By Tab or Shift+Tab, focus is moved among thread pane <-> message pane <-> folder pane <-> tab bar. So, if Tab or Shift+Tab is effective while mouse is still pressed during drag, "currently focused pane when popup is shown and hidden" can be known by pressing Tab key or Shift+Tab key.

To hook key event, add keyXXX event handler or add eventLister for key event to an element, and write log data to somewhere in the evnt handler or eventListner.

Comment 21

[WADA:World Anti-bad-Duping Agency]

(In reply to Jochen De Smet from comment #19)
> Created attachment 8350499 [details]
> Trace requested in comment 16

Can you attach trace for comment #11 too?

A. comment #11 case: (single window)
   A-1. DragStart() at thread pane, multiple canDrop() at folder pane,
   A-2. after a while, DragStart(), End of log
B. comment #16 case: (two windows)
   B-1. win-1 : DragStart() at thread pane, multiple canDrop() at folder pane, End of log
                This is same as comment #11 case.
   B-2. win-2 : after a while, DragStart(), End of log
        Timestamp is smaller than win-1, despite that event occurred after events at win-1.
Two small problems are seen in B.
  Even though drag is started at thread pane of win-1, dragend is invoked at win-2.
  Timestamp obtained by "new Date()" at win-2 is smaller than "new Date()" at win-1.

It looks that Drag itself is still active in XUL as desined.
Why Drag&Drop event is not invoked at folder pane?
Problem like following?
  "drag" event is invoked at thread pane(perhaps focussed pane).
  "drag" event handler of thread pane does do nothing,
  because x/y is irrelevant to thread pane(x/y in folder pane).
Or following?
  TreeView/Tb's FolderTreeView considers "drag is end" when focus is stolen by popup,
  then TreeView/Tb's FolderTreeView does do othing when drag event is invoked by XUL.

Comment 22

[Jochen De Smet]

Attachment: Trace requested in comment 11

Comment 23

[WADA:World Anti-bad-Duping Agency]

"Second DragStart() at thread pane upon mouseup" is also problem.

1. select multiple mails at thread pane.
2. drag mails to desktop. because it's not supported, icon=non-droppable.
3. mouseup at desktop.
In this case, second DragStart() is not invoked at thread pane. dragend event etc. is processed by other handler. DragStart() of thread pane is for DragStart at thread pane.
"Second DragStart() at thread pane" indicates that Drag&Drop event is invoked at thread pane wrongly.

Problem like following?
  Focus is stolen by popup, and focus is moved to thread pane after popup close,
  then drag event is invoked at thread pane.

If this kind of problem, why some one says "Win only problem" but some other one says "problem on all of Win, Linux, Mac" in bug 458570, some one says "IMAP only problem" but some other one says "not IMAP only problem" in bug 458570?
"IMAP only" means that "toaster popup for error" is used for IMAP command error etc. in Tb, so problem occurs only when IMAP is used?
If so, "new mail alert" also uses "toaster pop up" on Win. "Toaster popup in New mail alert" is not "a window in Tb", so problem doesn't occur when "new mail alert"?
Or "Toaster popup by new mail alert" is Win only, so someone says "Win only problem"?

Comment 24

[WADA:World Anti-bad-Duping Agency]

FYI.
See following for used code to trace Drag&Drop event at thread pane and folder pane.
  http://www.h2.dion.ne.jp/~radon/mozilla/tb-addon/WinBackMyTrash-1-Button.js.txt
Code is pretty simple.
  New handler
    Write log of "start of handler"
    Call original handler of Tb
    Write log of "end of handler"
    If original handler rerurns RC, return RC
This is set in URL: field of this bug too.

Comment 25

[WADA:World Anti-bad-Duping Agency]

If single window(comment #11), focus is placed at thread pane by "message drag".
Does problem occur when focus is placed on folder pane at win-2 when drag from win-1 to win-2?
1. win-2 : click a folder at folder pane. In win-2, focus is on folder pane.
2. win-1 : click a folder to select messages.
           select some messages => at win-1, focus is moved to thread pane. 
3. drag messages from win-1 to folder pane of win-2.
   current window is changed to win-2.
   keep mouse on a folder in folder pane of win-2.
4. popup message is shown, and popup message is hidden.
5. try to continue drag operation at folder pane of win-2.

Comment 26

[WADA:World Anti-bad-Duping Agency]

Some bugs for similar phenomenon were duped to bug 458570.
Setting dependency for ease of problem analysis, tracking, search.

Comment 31

[Magnus Melin [:mkmelin]]

This needs some investigation. I'm guessing there's something that forces the focus to the alert and that causes the other problems.

Comment 32

[Lasana Murray]

From what I can tell so far, it looks like directly modifying the dimensions of a window causes nsDragService::EndDragSession to be called. If I recall correctly from other bugs I think there is only one nsIDragSession at any given point in time so the resizeAlert() function in newmailalert.js causes it to abruptly end when it changes outerHeight or calls window.moveTo.

Comment 33

[Lasana Murray]

After reading the comments of bug 100180, I get the impression that the above happens in EnterModalState though I'm not 100% sure because I don't see why that would be called for non-modal dialogs.
https://searchfox.org/mozilla-central/source/dom/base/nsGlobalWindowOuter.cpp#6367

Even the patch there looks like it's a workaround rather than a fix so I think it's better if we just alter our drag and drop code to not assume a dataTransfer object is always available.

Comment 34

[Lasana Murray]

Even the patch there looks like it's a workaround rather than a fix so I think it's better if we just alter our drag and drop code to not assume a dataTransfer object is always available.

I went a different direction, because this will still be disruptive to the user. Instead I made a change to the notification dialog to detect if a drag session is active before resizing. It's a workaround because I don't think there is anything we could do in comm-central to avoid this. I tried to reproduce the issue in firefox but there does not seem to be much dialogs in there that can be resized.

Comment 35

[Lasana Murray]

Attachment: Bug 948082 - Detect active drag session before setting up new mail alert dialog. r?mkmelin

Comment 36

[Magnus Melin [:mkmelin]]

(In reply to Lasana Murray from comment #33)

After reading the comments of bug 100180, I get the impression that the above happens in EnterModalState though I'm not 100% sure because I don't see why that would be called for non-modal dialogs.

I didn't verify, but since this "window" get opened from chrome it probably to it from start - https://searchfox.org/mozilla-central/rev/2b372b94ce057097a6ef8eb725f209faa9d1dc4d/toolkit/components/windowwatcher/nsWindowWatcher.cpp#889

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e7906f9a1cb1
Detect active drag session before setting up new mail alert dialog to avoid notifications cancelling a drag. r=mkmelin