Last Comment Bug 100180 - UI freezes if alert/dialog comes up while dragging (Modal dialog during drag causes hang)
: UI freezes if alert/dialog comes up while dragging (Modal dialog during drag ...
Status: VERIFIED FIXED
[Workaround: use keyboard to dismiss ...
: hang, testcase
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: -- critical with 28 votes (vote)
: mozilla31
Assigned To: Mike Conley (:mconley) - (needinfo me!)
: Camelia Badau, QA [:cbadau]
Mentors:
: 82910 106464 131373 138748 143554 180428 210819 235154 237082 237251 238253 243683 246801 257666 270635 285720 296027 318257 342809 353735 365602 394240 407653 414462 426242 427687 428751 437872 438005 438690 440187 451275 452730 461679 466374 472836 477499 486876 489360 507781 507854 517197 531828 556680 562263 568456 578628 591630 597489 600792 609894 620299 631472 644936 655232 728593 732247 745972 747632 816434 819691 839744 872977 976093 (view as bug list)
Depends on: 14716 1001549 1003194
Blocks: 977957
  Show dependency treegraph
 
Reported: 2001-09-17 15:24 PDT by Erik Bruchez
Modified: 2016-01-27 21:45 PST (History)
112 users (show)
mmucci: firefox‑backlog+
roc: wanted‑next+
roc: wanted1.9.2+
roc: wanted1.9.1+
roc: blocking1.9-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
verified
verified
wontfix


Attachments
testcase (645 bytes, text/html)
2006-11-20 07:39 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
Output of !analyze -v hang (6.26 KB, text/plain)
2008-06-10 03:24 PDT, Arie Paap [:wildmyron]
no flags Details
testcase2 (457 bytes, text/html)
2008-08-09 04:38 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
modal dialog document needed for testcase3 (179 bytes, text/html)
2008-08-11 17:29 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
testcase3 (740 bytes, text/html)
2008-08-11 17:32 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
patch? (1.07 KB, patch)
2008-08-11 17:53 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
roc: review-
Details | Diff | Review
WIP Patch 1 (7.15 KB, patch)
2014-04-21 09:31 PDT, Mike Conley (:mconley) - (needinfo me!)
no flags Details | Diff | Review
Patch v1 (2.10 KB, patch)
2014-04-23 12:35 PDT, Mike Conley (:mconley) - (needinfo me!)
roc: review+
gavin.sharp: approval‑mozilla‑aurora+
Details | Diff | Review

Description Erik Bruchez 2001-09-17 15:24:46 PDT
If a DnD is in progress, for example between your Inbox and a mail folder, and
an alert pops up, for example because a site is unreachable, the UI freezes and
you have to kill Mozilla. To reproduce, enter a non-existant URL in Navigator,
then quickly start a DnD in Messenger and keep your mouse button down until the
alert pops up.
Comment 1 John Morrison 2001-09-17 15:45:11 PDT
confirming on win32(2k) and linux(rh6.1). This doesn't hang on Mac though 
(where the drag blocks out other events from being serviced).
Comment 2 joki (gone) 2002-02-12 01:16:13 PST
*** Bug 82910 has been marked as a duplicate of this bug. ***
Comment 3 John Levon 2002-06-18 12:53:01 PDT
isn't this a dupe of bug 63139 ?
Comment 4 David Hyatt 2002-08-02 11:18:44 PDT
--> default owner
Comment 5 R.K.Aa. 2002-10-22 11:30:01 PDT
*** Bug 143554 has been marked as a duplicate of this bug. ***
Comment 6 R.K.Aa. 2002-10-22 11:30:37 PDT
i think this may have been fixed quite a while back in bug 96504
Comment 7 Chris Lyon 2002-11-15 20:42:41 PST
*** Bug 180428 has been marked as a duplicate of this bug. ***
Comment 8 Mark Stier 2003-10-24 16:35:35 PDT
This bug still exists in Mozilla 1.5 under Windows XP.

Additionally, I have downloaded the Mozilla 1.5 source code, did a "./configure
--disable-debug --enable-optimize" on it, and then a "make install" under the
latest Debian 3.0 (woody). The compiled version of mozilla 1.5 seems to work ok
and this special bug is not existent there _at once_. But I did the following
and it reappeared:

1.) set your pop server to a server name that does not exist.
2.) drop the internet connection
3.) retrieve messages
4.) while mozilla tries to resolve the pop servers host name and before it
displays the alert, drag a message and hold it with your mouse pointer
5.) wait for the alert popup window to appear
6.) drop the message to a folder
7.) click away the popup
8.) move the message back to the first folder
9.) next, mozilla AND the XFree86 4.1.0 server completely lock up (kde2), only a
CTRL-ALT-DEL recovers control
 
Comment 9 Mark Stier 2003-10-24 16:38:53 PDT
Request: drag operations must be canceled on such events!
Comment 10 Fabian Guisset 2004-03-20 08:28:53 PST
*** Bug 138748 has been marked as a duplicate of this bug. ***
Comment 11 Fabian Guisset 2004-03-20 08:29:47 PST
*** Bug 106464 has been marked as a duplicate of this bug. ***
Comment 12 R.K.Aa. 2004-03-21 07:12:45 PST
*** Bug 237251 has been marked as a duplicate of this bug. ***
Comment 13 R.K.Aa. 2004-03-21 07:13:03 PST
*** Bug 235154 has been marked as a duplicate of this bug. ***
Comment 14 R.K.Aa. 2004-03-21 08:25:22 PST
FWIW: On Linux, when this happens, the cursor deadlock is UN-locked by simply
hitting the "Esc"-key. Windows users have confirmed it helps there too.
Comment 15 R.K.Aa. 2004-03-21 11:32:31 PST
*** Bug 237082 has been marked as a duplicate of this bug. ***
Comment 16 R.K.Aa. 2004-03-22 04:10:28 PST
*** Bug 238253 has been marked as a duplicate of this bug. ***
Comment 17 R.K.Aa. 2004-07-04 20:12:45 PDT
*** Bug 210819 has been marked as a duplicate of this bug. ***
Comment 18 Rob North 2004-09-02 09:44:15 PDT
*** Bug 257666 has been marked as a duplicate of this bug. ***
Comment 19 Rob North 2004-09-02 10:29:24 PDT
Just tried to replicate this bug on Linux (Suse 8.2), and couldn't 
(Moz build == 20040812).

Can replicate every time on Windows XP (See bug 257666)

At first glance it appears that this may be fixed on GTK
platforms by bug 96504 (See in comment #6 in this bug )
But yet, I'm not clear that the patches present were ever checked in!
Might this have been fixed in GTK itself?

Can someone else attempt to replicate this bug on Linux?

Comment 20 Markus J. Q. Roberts 2004-10-13 20:55:30 PDT
First, this may be a dup of 58276

Second, if someone has access to the Quality Feedback Agent data, look at
TB1294986K for more details & (I assume) a core dump.

Comment 21 OstGote! 2004-11-08 06:21:37 PST
corresponding Firefox bug is Bug 246801
Comment 22 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2004-11-18 12:13:46 PST
*** Bug 270635 has been marked as a duplicate of this bug. ***
Comment 23 OstGote! 2004-12-02 06:14:59 PST
*** Bug 243683 has been marked as a duplicate of this bug. ***
Comment 24 OstGote! 2005-03-11 05:46:56 PST
*** Bug 157168 has been marked as a duplicate of this bug. ***
Comment 25 Marcus Kommnick 2005-03-11 10:03:49 PST
*** Bug 285720 has been marked as a duplicate of this bug. ***
Comment 26 OstGote! 2005-06-03 17:20:08 PDT
*** Bug 296027 has been marked as a duplicate of this bug. ***
Comment 27 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-07-20 01:52:23 PDT
I suspect this may have the same cause as bug 203573.
What I think what is happening is this. When an alert comes up, the drag
operation isn't cancelled (mentioned in comment 9, and should also be fixed,
probably).
When a drag operation is executing, in windows, all the timers are postponed,
until after the drag operation has completed.
When I look at:
http://lxr.mozilla.org/seamonkey/source/xpfe/components/alerts/resources/content/alert.js
I see a lot of timers.
So, I think, when bug 203573 gets fixed, this may also be fixed. 
Comment 28 Paul Stone 2005-11-02 14:45:39 PST
This bug only appears to block all mouse input. The popup dialog can still be dismissed using the keyboard (i.e pressing space)
Comment 29 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-08-11 09:47:50 PDT
*** Bug 342809 has been marked as a duplicate of this bug. ***
Comment 30 Adam Guthrie 2006-09-21 21:25:30 PDT
*** Bug 353735 has been marked as a duplicate of this bug. ***
Comment 31 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-11-20 07:39:11 PST
Created attachment 246023 [details]
testcase

It also happens when an alert is called on a dragenter/dragover event.
Comment 32 Adam Kowalczyk 2007-01-02 17:53:46 PST
*** Bug 365602 has been marked as a duplicate of this bug. ***
Comment 33 Phil Ringnalda (:philor) 2007-12-10 11:28:41 PST
*** Bug 407653 has been marked as a duplicate of this bug. ***
Comment 34 Phil Ringnalda (:philor) 2008-01-28 15:28:50 PST
*** Bug 414462 has been marked as a duplicate of this bug. ***
Comment 35 Serge Gautherie (:sgautherie) 2008-02-29 16:26:49 PST
(In reply to comment #27)
> I suspect this may have the same cause as bug 203573.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022604 Minefield/3.0b4pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022601 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Bug still there, per testcase.
Bug 389931 (which fixed bug 203573) was not a likely cause, as the current bug is way way older.

> What I think what is happening is this. When an alert comes up, the drag
> operation isn't cancelled (mentioned in comment 9, and should also be fixed,
> probably).

This does look like a possible explanation/cause.
Comment 36 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-03-05 16:02:44 PST
Seems like we should just be able to terminate a drag if a modal dialog comes up during it.  Would that be a sufficient fix?
Comment 37 Luiz Antonio 2008-03-09 12:49:31 PDT
Theoretically a modal dialog should contain information that is important enough to, well, be modal. If its not important enough to deserve exclusive attention, then it should use some other mean to inform the user. Hence, it seems to me that the modal dialog should cancel the current drag and drop operation.
Comment 38 Phil Ringnalda (:philor) 2008-03-31 13:35:24 PDT
*** Bug 426242 has been marked as a duplicate of this bug. ***
Comment 39 Wayne Mery (:wsmwk, NI for questions) 2008-04-12 21:10:19 PDT
*** Bug 428751 has been marked as a duplicate of this bug. ***
Comment 40 Serge Gautherie (:sgautherie) 2008-04-13 05:46:16 PDT
*** Bug 131373 has been marked as a duplicate of this bug. ***
Comment 41 Serge Gautherie (:sgautherie) 2008-04-13 06:03:29 PDT
(In reply to comment #23)
> *** Bug 243683 has been marked as a duplicate of this bug. ***

FWIW,
Bug 243683 comment 3:
{{
neil@parkwaycc.co.uk   2004-05-16 06:20:03 PDT

The other way to fix this is to make window deactivation kill capturing and
other stateful operations. On Windows the WM_CANCELMODE message is provided for
this purpose. Needless to say we ignore it, which causes e.g. bug 97014.
}}

BugZilla has 11 bugs (only 1 still opened) with 'WM_CANCELMODE' in a comment.
Comment 42 Serge Gautherie (:sgautherie) 2008-04-13 07:11:31 PDT
*** Bug 246801 has been marked as a duplicate of this bug. ***
Comment 43 Serge Gautherie (:sgautherie) 2008-04-13 07:14:41 PDT
(In reply to comment #42)
> *** Bug 246801 has been marked as a duplicate of this bug. ***

That Firefox bug had another load of various duplicated cases !
All hopes in "wanted‑next+".
Comment 44 Dominic 2008-05-18 20:26:28 PDT
Reproducible with Firefox 3.0 RC1 with Windows XP.
Comment 45 Dominic 2008-05-20 15:11:23 PDT
In the screenshots, I was dragging and an alert came up. dragend did not occur until after the UI froze:
http://img362.imageshack.us/img362/53/bugws1.png - Frozen
http://img387.imageshack.us/img387/3689/bug2lz1.png - Unfrozen (used "Esc")
Comment 46 timeless 2008-06-10 00:03:02 PDT
please excuse my ignorance, would someone please use:

http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg

!analyze -v -hang

i'd like to have a stack trace for this "problem" available in the bug (an attachment is fine)
Comment 47 timeless 2008-06-10 00:45:49 PDT
*** Bug 437872 has been marked as a duplicate of this bug. ***
Comment 48 Arie Paap [:wildmyron] 2008-06-10 03:24:36 PDT
Created attachment 324426 [details]
Output of !analyze -v hang

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060207 Minefield/3.0pre

Recorded after hang with attachment 246023 [details].
Comment 49 timeless 2008-06-10 16:16:26 PDT
so... if someone could make a testcase and report how ie5/5.5/6/7/8 handle this (Windows), that'd help neil.

tentatively, i think the window on opening can get the drag service, get the current drag session, if there's a drag session, try to qi it to nsIWindow, and then call enableDragDrop(false).

this path doesn't seem to exist for mac, but for mac the path isn't needed as it shouldn't happen.

before we'd implement this, we need to know what ie actually does :)
Comment 50 Serge Gautherie (:sgautherie) 2008-06-10 16:28:50 PDT
[Microsoft Internet Explorer, version 6.0.2800.1106 (128b, SP1)] (release++) (W2Ksp4)

Attached testcase does not work because it does not like
|document.links[0].addEventListener('dragenter', doe, true);|
Comment 51 Arie Paap [:wildmyron] 2008-06-12 07:36:40 PDT
*** Bug 438690 has been marked as a duplicate of this bug. ***
Comment 52 Phil Ringnalda (:philor) 2008-06-18 16:12:10 PDT
*** Bug 440187 has been marked as a duplicate of this bug. ***
Comment 53 Dão Gottwald [:dao] 2008-07-04 05:49:47 PDT
*** Bug 438005 has been marked as a duplicate of this bug. ***
Comment 54 Keith Corlett 2008-08-07 06:59:40 PDT
I just recreated this bug on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1.

... and the workround: "use the keyboard to clear the dialog" didn't work either. The dialog wouldn't accept the focus... ergo deadlock.

Also bug in the bug tracking system... maybe half the reason this bug has SO MANY duplicated reports is that shotgun search string "firefox freezes when a page displays an alert while dragging the tab" did NOT find this bug, but it did find one of the duplicate reports, so I supposed one could say the indexing system still works, even if the initial hit rate is approximately zero.
Comment 55 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-08-09 04:38:18 PDT
Created attachment 333081 [details]
testcase2

IE seems to suffer from the same bug.

I tried the suggestion in comment 49 (and a lot more), but that didn't seem to work at all.
Comment 56 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-08-11 17:29:35 PDT
Created attachment 333325 [details]
modal dialog document needed for testcase3
Comment 57 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-08-11 17:32:25 PDT
Created attachment 333327 [details]
testcase3

IE seems to cancel the drag just fine for modal dialogs.
Comment 58 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-08-11 17:53:52 PDT
Created attachment 333330 [details] [diff] [review]
patch?

This seems to work.
But after the dialog is dismissed, you still get a drop effect, which shouldn't happen.
Comment 59 Phil Ringnalda (:philor) 2008-08-19 16:52:22 PDT
*** Bug 451275 has been marked as a duplicate of this bug. ***
Comment 60 Dão Gottwald [:dao] 2008-09-01 17:55:27 PDT
*** Bug 452730 has been marked as a duplicate of this bug. ***
Comment 61 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-09-02 01:04:27 PDT
Comment on attachment 333330 [details] [diff] [review]
patch?

But that drop effect isn't a big deal.
But perhaps this might cause other, unwanted side-effects?
Comment 62 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2008-09-08 23:26:17 PDT
With this patch, can you actually operate the dialog with the mouse? I'm not sure why this would work.
Comment 63 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-09-09 05:29:15 PDT
Yes, I don't know why the patch works, either, to be honest.
Comment 64 Ere Maijala (slow) 2008-09-14 10:50:21 PDT
I think a popup should rather cancel the drag and release mouse capture from the drag source. The drag effect remains because the source doesn't get the mouse exit as the capture has changed. Setting capture to the target just isn't right.
Comment 65 K. Adams 2008-10-26 21:58:34 PDT
*** Bug 461679 has been marked as a duplicate of this bug. ***
Comment 66 Ria Klaassen (not reading all bugmail) 2008-11-23 08:16:31 PST
*** Bug 466374 has been marked as a duplicate of this bug. ***
Comment 67 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-12-17 11:33:38 PST
How do I cancel a drag?
Comment 68 Serge Gautherie (:sgautherie) 2008-12-17 11:47:06 PST
(In reply to comment #67)

By pressing Escape...
Comment 69 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2008-12-17 14:04:24 PST
(In reply to comment #68)
> (In reply to comment #67)
> 
> By pressing Escape...

Heh, I meant, how can I cancel a native drag programmatically?
Comment 70 Phil Ringnalda (:philor) 2009-02-08 10:35:48 PST
*** Bug 477499 has been marked as a duplicate of this bug. ***
Comment 71 Henrik Skupin (:whimboo) 2009-02-08 11:05:03 PST
*** Bug 394240 has been marked as a duplicate of this bug. ***
Comment 72 Ria Klaassen (not reading all bugmail) 2009-04-05 09:56:22 PDT
*** Bug 486876 has been marked as a duplicate of this bug. ***
Comment 73 Ria Klaassen (not reading all bugmail) 2009-08-02 00:48:52 PDT
*** Bug 507854 has been marked as a duplicate of this bug. ***
Comment 74 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-08-12 20:32:11 PDT
Neil, see comment #69
Comment 75 Neil Deakin 2009-08-17 05:41:47 PDT
(In reply to comment #69)

> Heh, I meant, how can I cancel a native drag programmatically?

I don't think it's possible to do this, but you'd have to ask someone more familiar with each platform.
Comment 76 Ria Klaassen (not reading all bugmail) 2009-09-17 06:15:23 PDT
*** Bug 517197 has been marked as a duplicate of this bug. ***
Comment 77 Henrik Skupin (:whimboo) 2009-10-12 16:47:59 PDT
*** Bug 472836 has been marked as a duplicate of this bug. ***
Comment 78 Ria Klaassen (not reading all bugmail) 2009-11-30 08:58:37 PST
*** Bug 531828 has been marked as a duplicate of this bug. ***
Comment 79 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-03-01 17:02:36 PST
Comment on attachment 333330 [details] [diff] [review]
patch?

minusing because I think we don't understand why this would work
Comment 80 zug_treno 2010-04-10 14:25:31 PDT
*** Bug 556680 has been marked as a duplicate of this bug. ***
Comment 81 James 2010-05-16 15:38:06 PDT
Still the same. This is getting very badly annoying because whenever I open a new window, a message box pops up, and I open new windows to move certain tabs over, hanging every time. I use the ALT key to access the file menu, select exit, and then restart the browser.
Comment 82 Henrik Skupin (:whimboo) 2010-07-14 02:17:27 PDT
*** Bug 578628 has been marked as a duplicate of this bug. ***
Comment 83 Henrik Skupin (:whimboo) 2010-08-29 01:56:19 PDT
*** Bug 591630 has been marked as a duplicate of this bug. ***
Comment 84 Henrik Skupin (:whimboo) 2010-09-17 16:08:24 PDT
*** Bug 597489 has been marked as a duplicate of this bug. ***
Comment 85 Henrik Skupin (:whimboo) 2010-09-30 01:46:40 PDT
*** Bug 600792 has been marked as a duplicate of this bug. ***
Comment 86 Wedge009 2010-10-22 06:08:00 PDT
Not sure if bug 427687 is related, as it seems specific to moving tabs, and not 'dragging' in general.
Comment 87 Wayne Mery (:wsmwk, NI for questions) 2010-10-22 07:44:22 PDT
if solution for this issue (which is sev=critical) really depends on 
 Bug 78248 - API to determine if a mouse button is pressed, or
 Bug 14716 - don't popup new windows while mouse button is down
then their priority should be raised above ENH.
Comment 88 Henrik Skupin (:whimboo) 2010-11-05 10:41:09 PDT
*** Bug 609894 has been marked as a duplicate of this bug. ***
Comment 89 Henrik Skupin (:whimboo) 2010-11-15 13:11:28 PST
*** Bug 318257 has been marked as a duplicate of this bug. ***
Comment 90 Henrik Skupin (:whimboo) 2010-11-17 02:42:53 PST
*** Bug 427687 has been marked as a duplicate of this bug. ***
Comment 91 BillyNair 2010-11-17 14:46:04 PST
Is there a workaround? maybe for those of us that know the risks of disabling all modal windows that we can set something in the about:config to disable that "feature"? only a few times ever have I needed to know what the fatal error was going to be unless I addressed it, but multiple times daily am I forced to deal with issues that are not only NOT fatal, they arnt even much of an issue at all!! Example: allowing a cookie on a page I am not actively looking at.
Comment 92 Henrik Skupin (:whimboo) 2010-12-19 16:12:18 PST
*** Bug 620299 has been marked as a duplicate of this bug. ***
Comment 93 Konomi 2011-01-24 18:46:21 PST
I'd just like to add I think I came across this bug on firefox. I had a download fail and the dialog for the fail pop up with the OK button, at the same time I was dragging a tab to rearrange them. The dialog popped up at the same time and made firefox unsuable. I could not do anything to get rid of the dialog. I couldn't click ok I couldn't press space or enter to do it on the keyboard. No matter what I did.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Comment 94 Henrik Skupin (:whimboo) 2011-02-13 01:35:14 PST
*** Bug 568456 has been marked as a duplicate of this bug. ***
Comment 95 Wedge009 2011-02-18 12:29:35 PST
What does it mean that status2.0 is 'wontfix'? Is that referring to Gecko 2.0? Does that mean this not an issue in a future version?
Comment 96 bb10 2011-02-18 13:17:11 PST
It means that it won't be fixed for Firefox 4. So it will have to be fixed in Firefox 5+.
Comment 97 Serge Gautherie (:sgautherie) 2011-03-27 06:14:43 PDT
*** Bug 644936 has been marked as a duplicate of this bug. ***
Comment 98 Henrik Skupin (:whimboo) 2011-05-06 10:18:12 PDT
*** Bug 655232 has been marked as a duplicate of this bug. ***
Comment 99 Jordan 2011-10-10 16:31:10 PDT
Definitely still an issue - ran into it just today.
Comment 100 Matthias Versen [:Matti] 2012-02-18 14:13:44 PST
*** Bug 562263 has been marked as a duplicate of this bug. ***
Comment 101 Matthias Versen [:Matti] 2012-02-18 14:13:58 PST
*** Bug 728593 has been marked as a duplicate of this bug. ***
Comment 102 flii (cj) 2012-02-28 14:01:21 PST
still an issue in v9.

i was dragging a tab to a new location when a cookie confirmation box popped up.  locked up the whole browser, i can't click anything, and no keyboard shortcut registers.
Comment 103 Wedge009 2012-02-28 22:41:53 PST
Agreed, still an issue in 10.0.2. Got caught with it again at work and even after I killed the process from Windows 7's Task Manager, the translucent shadow of the tab being dragged remained 'stuck' on the desktop.

Save for trying to dig through the source code, is there anything regular users can do to help with this issue? I admit this problem doesn't happen too often, but when it does, it's quite inconvenient.
Comment 104 Bram Speeckaert 2012-02-29 00:07:42 PST
I've found that in some cases pressing Esc or Tab may allow you to dismiss dialogs and regain control over the browser. Issue is also still present in the latest Nightly builds (13.0a1 2012-02-28).
Comment 105 Alice0775 White 2012-02-29 00:31:18 PST
I cannot reproduce testcase, testcase2 and 3 on ubuntu.
http://hg.mozilla.org/releases/mozilla-release/rev/72ad46d416ce
Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 ID:20120215223356

But I can reproduce on Windows.
Comment 106 Matthias Versen [:Matti] 2012-03-01 16:17:10 PST
*** Bug 732247 has been marked as a duplicate of this bug. ***
Comment 107 Matthias Versen [:Matti] 2012-03-01 16:41:15 PST
*** Bug 631472 has been marked as a duplicate of this bug. ***
Comment 108 Matthias Versen [:Matti] 2012-03-01 16:41:58 PST
*** Bug 507781 has been marked as a duplicate of this bug. ***
Comment 109 James 2012-03-02 15:07:37 PST
Is this ever going to get fixed? I've been tracking this for so long it's not even funny. At this rate, I guess the best fix is to install Chrome instead....
Comment 110 Matthias Versen [:Matti] 2012-04-16 16:23:25 PDT
*** Bug 745972 has been marked as a duplicate of this bug. ***
Comment 111 Matthias Versen [:Matti] 2012-04-21 13:39:20 PDT
*** Bug 747632 has been marked as a duplicate of this bug. ***
Comment 112 Notlost 2012-05-27 15:37:13 PDT
This happens on the latest nightly when dragging a tab and the master password box comes up.

(froze ui).

I killed FF using task manager applications tab, but the drag icon stayed following the mouse, even with the FF window gone. Killing the firefox.exe process under task manager left an afterimage that lasted until something else was dragged.

windows 7 x64,
Comment 113 Jeb Rosen 2012-09-12 13:41:58 PDT
Confirming on Win7x64 Nightly 18.0a1 (2012-09-11)

This happens when I'm dragging a tab and a security warning appears. I can press Escape at this point to 'cancel' both the message and the tab drag.
Comment 114 nathankohagen 2012-11-15 14:53:34 PST
I just observed this bug in Thunderbird 16.0.2 on Windows 7 Pro 64-bit.  
I was dragging a email message to another mail folder and a modal dialog due to a login failure of the 2nd email account popped up (random server failure?).  I was unable to dismiss the modal dialog box because of the message dragging already in progress.  I did not try to dismiss it with the keyboard.  I killed the thunderbird process and I was left with the translucent/shaded message info line stuck on the screen similar to the description in comment #103.
Comment 115 Matthias Versen [:Matti] 2012-11-29 15:09:36 PST
*** Bug 816434 has been marked as a duplicate of this bug. ***
Comment 116 Mats Palmgren (:mats) 2013-02-09 09:32:19 PST
*** Bug 839744 has been marked as a duplicate of this bug. ***
Comment 117 Mats Palmgren (:mats) 2013-02-09 09:40:05 PST
*** Bug 819691 has been marked as a duplicate of this bug. ***
Comment 118 [:Aleksej] 2013-05-21 05:26:56 PDT
*** Bug 872977 has been marked as a duplicate of this bug. ***
Comment 119 YF (Yang) 2014-03-01 15:50:04 PST
*** Bug 976093 has been marked as a duplicate of this bug. ***
Comment 120 Wayne Mery (:wsmwk, NI for questions) 2014-04-09 03:45:07 PDT
*** Bug 489360 has been marked as a duplicate of this bug. ***
Comment 121 Mike Conley (:mconley) - (needinfo me!) 2014-04-21 09:31:25 PDT
Created attachment 8409705 [details] [diff] [review]
WIP Patch 1

Fixing this will take care of bug 977957, so that's why I'm looking at this. Thanks to Enn and khuey for their guidance on the approach.

This patch _almost_ works - all of the wiring to have QueryContinueDrag return false after a modal dialog opens is there.

The problem is that as soon as the modal dialog opens, Gecko seems to stop handling the QueryContinueDrag callbacks... I'm really not at all familiar with how Gecko processes native callbacks, but we seem to block the QueryContinueDrag callback with the modal dialog opened. If I dismiss the modal dialog with my keyboard, the QueryContinueDrag callback is fired, and we cancel (although by this time, it's too late, since I just dismissed the modal by keyboard).

So, if we go with this approach... how do we get Gecko to allow the QueryContinueDrag callback to fire once the modal is opened?
Comment 122 Mike Conley (:mconley) - (needinfo me!) 2014-04-21 09:33:40 PDT
Comment on attachment 8409705 [details] [diff] [review]
WIP Patch 1

Hey Mark, I remember seeing your name in the list of contributors to this Windows dragndrop stuff... do you know how I might get Gecko to allow the QueryContinueDrag callback to be called from the OS?
Comment 123 Tim Abraldes [:TimAbraldes] [:tabraldes] 2014-04-21 14:53:54 PDT
Comment on attachment 8409705 [details] [diff] [review]
WIP Patch 1

(In reply to Mike Conley (:mconley) from comment #121)
> Created attachment 8409705 [details] [diff] [review]
> WIP Patch 1
> 
> Fixing this will take care of bug 977957, so that's why I'm looking at this.
> Thanks to Enn and khuey for their guidance on the approach.
> 
> This patch _almost_ works - all of the wiring to have QueryContinueDrag
> return false after a modal dialog opens is there.
> 
> The problem is that as soon as the modal dialog opens, Gecko seems to stop
> handling the QueryContinueDrag callbacks... I'm really not at all familiar
> with how Gecko processes native callbacks, but we seem to block the
> QueryContinueDrag callback with the modal dialog opened. If I dismiss the
> modal dialog with my keyboard, the QueryContinueDrag callback is fired, and
> we cancel (although by this time, it's too late, since I just dismissed the
> modal by keyboard).
> 
> So, if we go with this approach... how do we get Gecko to allow the
> QueryContinueDrag callback to fire once the modal is opened?

`QueryContinueDrag` is called by `DoDragDrop` when the mouse or keyboard state changes; see documentation at [1] and [2]. We can't expect `QueryContinueDrag` to be called in any other circumstance, so there's no guarantee that `DoDragDrop` will ever successfully cancel the drag even with this patch applied.

When we call `DoDragDrop`, we hand off program control to that function and, with the limited exception provided by `QueryContinueDrag`, we don't get to tell it when we want to cancel the drag operation.

Based on my reading of the documentation, I don't believe the approach we're taking (cancel any current drag operation when a popup is opened) is going to work on Windows. A better approach might be to make popups wait for the drag operation to end before appearing.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms678486%28v=vs.85%29.aspx
[2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms690076%28v=vs.85%29.aspx
Comment 124 Mike Conley (:mconley) - (needinfo me!) 2014-04-22 10:06:20 PDT
(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #123)
> A better approach might be to make popups wait for the
> drag operation to end before appearing.
> 

Hm. So what you're suggesting is that if some script calls for a modal while we're dragging, that script gets blocked, but not modal is shown until the drag operation ends, after which we display the modal.

How would one accomplish that? We're already outside of my domain of expertise - and this bug is threatening to drift further down that path. :/
Comment 125 Mike Conley (:mconley) - (needinfo me!) 2014-04-22 12:17:20 PDT
Comment on attachment 8409705 [details] [diff] [review]
WIP Patch 1

Withdrawing review request because this is probably not the way to go.
Comment 126 Mark Hammond [:markh] 2014-04-22 15:37:57 PDT
(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #123)
> Comment on attachment 8409705 [details] [diff] [review]
> `QueryContinueDrag` is called by `DoDragDrop` when the mouse or keyboard
> state changes; see documentation at [1] and [2]. We can't expect
> `QueryContinueDrag` to be called in any other circumstance, so there's no
> guarantee that `DoDragDrop` will ever successfully cancel the drag even with
> this patch applied.

What I don't yet understand is why the user clicking the mouse once we are in this strange state will not abort the drag/drop with this patch applied?  While that would still be far from ideal, it would reduce the severity of the issue.

(Sadly my attempts to inspect the stack during some of this was thwarted by MSVC not showing me the entire stack, and I'm probably not going to find more time in the next week)
Comment 127 Tim Abraldes [:TimAbraldes] [:tabraldes] 2014-04-23 07:44:19 PDT
(In reply to Mark Hammond [:markh] from comment #126)
> (In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #123)
> > Comment on attachment 8409705 [details] [diff] [review]
> > `QueryContinueDrag` is called by `DoDragDrop` when the mouse or keyboard
> > state changes; see documentation at [1] and [2]. We can't expect
> > `QueryContinueDrag` to be called in any other circumstance, so there's no
> > guarantee that `DoDragDrop` will ever successfully cancel the drag even with
> > this patch applied.
> 
> What I don't yet understand is why the user clicking the mouse once we are
> in this strange state will not abort the drag/drop with this patch applied? 
> While that would still be far from ideal, it would reduce the severity of
> the issue.

My initial hunch would be that our dialog box is capturing the mouse [1] and/or doing something else that causes the mouse clicks not to get noticed by `DoDragDrop`. I found and old article that claims that "DoDragDrop calls SetCapture to associate mouse input with a hidden OLE window" [2]. I think this implies that calling `SetCapture` from our dialog window breaks the ability of `DoDragDrop` to notice when a mouse button has been pressed.
 
> (Sadly my attempts to inspect the stack during some of this was thwarted by
> MSVC not showing me the entire stack, and I'm probably not going to find
> more time in the next week)

I'm also not going to be able to look at this within a week :/


[1] http://msdn.microsoft.com/en-us/library/ms646262%28v=vs.85%29.aspx
[2] https://support.microsoft.com/kb/139408
Comment 128 Mike Conley (:mconley) - (needinfo me!) 2014-04-23 12:35:06 PDT
Created attachment 8411255 [details] [diff] [review]
Patch v1

So I looked at this with ehsan, and here's what we've figured out (this may have already been obvious to others, but I think it was still coming together in my head - also, I may not have this 100% correct and ehsan can correct me where I go wrong):

What we've got here is a mouse capture problem in conjunction with a nested event loop problem. When we call ::DoDragDrop to start the dragging operation, we suspect that Windows calls ::SetCapture on some hidden window belonging to the Firefox process that only Windows knows about.

When we enter our nested event loop, the mouse events coming into that hidden window (and sent to the main event loop), get blocked.

The solution in this patch is to try to force a ReleaseCapture if we've got mouse events captured when we enter a modal state.

Not sure if it's the best solution, but it definitely solves this bug as well as bug 977957.
Comment 129 Mike Conley (:mconley) - (needinfo me!) 2014-04-23 12:36:00 PDT
Comment on attachment 8411255 [details] [diff] [review]
Patch v1

How do we feel about this?
Comment 130 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2014-04-23 16:09:44 PDT
Comment on attachment 8411255 [details] [diff] [review]
Patch v1

Review of attachment 8411255 [details] [diff] [review]:
-----------------------------------------------------------------

Seems reasonable.
Comment 131 Mike Conley (:mconley) - (needinfo me!) 2014-04-23 20:00:50 PDT
Sweet! Thanks roc.

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/0aab0a3738cf
Comment 132 Carsten Book [:Tomcat] 2014-04-24 04:14:55 PDT
https://hg.mozilla.org/mozilla-central/rev/0aab0a3738cf
Comment 133 Mike Conley (:mconley) - (needinfo me!) 2014-04-25 07:38:29 PDT
Comment on attachment 8411255 [details] [diff] [review]
Patch v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 

This bug has existed for practically forever.


User impact if declined: 

Users who are dragging and dropping while a modal dialog comes up will be unable to use their mouse until the modal dialog is dismissed via keyboard.

This is the root of bug 977957, which is an Australis P3 (which is why I'm requesting Aurora uplift, otherwise I'd just leave it).


Testing completed (on m-c, etc.): 

Local testing and a night on m-c.


Risk to taking this patch (and alternatives if risky): 

It's a pretty simple patch that's easy to back out if necessary, but it's also down in the guts of widget. If we don't think that the scenario laid out in bug 977957 is likely, we could let this ride the trains normally. I'll leave that up to the release drivers.


String or IDL/UUID changes made by this patch:

None.
Comment 134 Mike Conley (:mconley) - (needinfo me!) 2014-04-25 09:11:34 PDT
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/fa4aff8faf05
Comment 135 Liz Henry (:lizzard) (needinfo? me) 2014-04-28 13:31:53 PDT
Hi Florin, I don't know if your team will have time to QA this before the end of the day tomorrow, but if you can't, it should be carried over into the next iteration. Thanks!
Comment 136 Liz Henry (:lizzard) (needinfo? me) 2014-04-28 13:34:16 PDT
See Comment #133 for the (low) risk of having to back this out if it goes to Aurora without being verified.
Comment 137 Camelia Badau, QA [:cbadau] 2014-04-29 07:35:57 PDT
Verified on Windows 7 64bit, Ubuntu 13.10 32bit and Mac OS X 10.8 using:
#latest Aurora, build ID: 20140428004000 
#latest Nightly, build ID: 20140428030203. 

Additional issues were found and logged separately: bug 1003142 and bug 1003169.
Comment 138 Neil Deakin 2014-04-29 10:21:14 PDT
I don't see a bug filed for fixing this properly. The user is trying to drag something. The user is not requesting to show any dialogs. The right fix is to have dragging continue to work as normal, not have a dialog override what someone is doing. With this patch, a website can still prevent me from dragging just by calling alert().

 
> nsDragService::EndDragSession(bool aDoneDrag)
> {
>+  // Bug 100180: If we've got mouse events captured, make sure we release it -
>+  // that way, if we happen to call EndDragSession before diving into a nested
>+  // event loop, we can still respond to mouse events.
>+  if (::GetCapture()) {
>+    ::ReleaseCapture();
>+  }

A slightly safer fix here is to only do this in the one case when a modal dialog opens, as EndDragSession(false) will be called whenever you drag something from another application outside the window frame and there could be some theoretical edgecase broken.
Comment 139 :Ehsan Akhgari (busy, don't ask for review please) 2014-04-29 16:13:21 PDT
(In reply to comment #138)
> I don't see a bug filed for fixing this properly. The user is trying to drag
> something. The user is not requesting to show any dialogs. The right fix is to
> have dragging continue to work as normal, not have a dialog override what
> someone is doing. With this patch, a website can still prevent me from dragging
> just by calling alert().

You mean not focusing the tab which initiated the alert() in that case?  Even that won't work since alert() will end up spinning an event loop anyways.

(Which makes me think that the same issue can also happen with sync XHR which spins its own event loop too, but without an obvious UI.)
Comment 140 Łukasz Augustyński 2014-06-27 07:46:47 PDT
(In reply to Mike Conley (:mconley) from comment #134)
> if (::GetCapture()) {
> ::ReleaseCapture();
> }
I've created the NPAPI plugin with Drag & Drop functionality in it.
This fix is messing with D&D I start from the plugin. 

The ::GetCapture finds CLIPBRDWNDCLASS window having mouse captured. After ::ReleaseCapture I've got D&D cut in the middle: have D&D icon and D&D still in progress (blocked in my SHDoDrapDrop) but without mouse events loop it ends only on ESC press.
Comment 141 Mike Conley (:mconley) - (needinfo me!) 2014-10-18 09:16:06 PDT
As NPAPI plugins are slowly being phased out, I don't think we want to fix the case laid out in comment 140. Sorry about that!

Note You need to log in before you can comment on or make changes to this bug.