The default bug view has changed. See this FAQ.

UI freezes if alert/dialog comes up while dragging (Modal dialog during drag causes hang)

VERIFIED FIXED in Firefox 30

Status

()

Core
XUL
--
critical
VERIFIED FIXED
16 years ago
a month ago

People

(Reporter: Erik Bruchez, Assigned: mconley)

Tracking

(Depends on: 4 bugs, {hang, testcase})

Trunk
mozilla31
hang, testcase
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +
wanted-next +
wanted1.9.2 +
wanted1.9.1 +
blocking1.9 -

Firefox Tracking Flags

(firefox30+ verified, firefox31 verified, status2.0 wontfix)

Details

(Whiteboard: [Workaround: use keyboard to dismiss dialog][has draft patch] p=0 s=it-32c-31a-30b.1 [qa!])

Attachments

(6 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
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

16 years ago
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 2

15 years ago
*** Bug 82910 has been marked as a duplicate of this bug. ***

Comment 3

15 years ago
isn't this a dupe of bug 63139 ?

Comment 4

15 years ago
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Target Milestone: Future → ---

Comment 5

15 years ago
*** Bug 143554 has been marked as a duplicate of this bug. ***

Comment 6

15 years ago
i think this may have been fixed quite a while back in bug 96504

Comment 7

15 years ago
*** Bug 180428 has been marked as a duplicate of this bug. ***

Comment 8

14 years ago
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

14 years ago
Request: drag operations must be canceled on such events!

Comment 10

13 years ago
*** Bug 138748 has been marked as a duplicate of this bug. ***

Comment 11

13 years ago
*** Bug 106464 has been marked as a duplicate of this bug. ***

Updated

13 years ago
OS: Windows 2000 → All

Comment 12

13 years ago
*** Bug 237251 has been marked as a duplicate of this bug. ***

Comment 13

13 years ago
*** Bug 235154 has been marked as a duplicate of this bug. ***

Comment 14

13 years ago
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

13 years ago
*** Bug 237082 has been marked as a duplicate of this bug. ***

Comment 16

13 years ago
*** Bug 238253 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
*** Bug 210819 has been marked as a duplicate of this bug. ***

Comment 18

13 years ago
*** Bug 257666 has been marked as a duplicate of this bug. ***

Comment 19

13 years ago
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

13 years ago
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

13 years ago
corresponding Firefox bug is Bug 246801
*** Bug 270635 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Summary: UI freezes if alert comes up while dragging → UI freezes if alert/dialog comes up while dragging

Comment 23

13 years ago
*** Bug 243683 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Summary: UI freezes if alert/dialog comes up while dragging → UI freezes if alert/dialog comes up while dragging (Modal dialog during drag causes hang)

Comment 24

12 years ago
*** Bug 157168 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 246801

Comment 25

12 years ago
*** Bug 285720 has been marked as a duplicate of this bug. ***

Comment 26

12 years ago
*** Bug 296027 has been marked as a duplicate of this bug. ***
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. 
Depends on: 203573

Comment 28

12 years ago
This bug only appears to block all mouse input. The popup dialog can still be dismissed using the keyboard (i.e pressing space)
*** Bug 342809 has been marked as a duplicate of this bug. ***

Comment 30

11 years ago
*** Bug 353735 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Keywords: hang
Created attachment 246023 [details]
testcase

It also happens when an alert is called on a dragenter/dragover event.

Updated

11 years ago
Keywords: testcase

Updated

10 years ago
Duplicate of this bug: 365602
Duplicate of this bug: 407653
Duplicate of this bug: 414462
(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.
No longer depends on: 203573
Flags: blocking1.9?
Whiteboard: [Workaround: use keyboard to dismiss dialog]
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?
Flags: wanted-next+
Flags: blocking1.9?
Flags: blocking1.9-

Comment 37

9 years ago
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.
Duplicate of this bug: 426242
Duplicate of this bug: 428751
Duplicate of this bug: 131373
(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.
Depends on: 14716
Duplicate of this bug: 246801
(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

9 years ago
Reproducible with Firefox 3.0 RC1 with Windows XP.

Comment 45

9 years ago
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

9 years ago
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)

Updated

9 years ago
Duplicate of this bug: 437872
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

9 years ago
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 :)
[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);|

Updated

9 years ago
Duplicate of this bug: 438690
Duplicate of this bug: 440187

Updated

9 years ago
Duplicate of this bug: 438005
No longer blocks: 246801
Severity: normal → major
Flags: blocking1.9.1?
QA Contact: jrgmorrison → xptoolkit.widgets

Comment 54

9 years ago
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.
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.
Created attachment 333325 [details]
modal dialog document needed for testcase3
Created attachment 333327 [details]
testcase3

IE seems to cancel the drag just fine for modal dialogs.
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.
Duplicate of this bug: 451275

Updated

9 years ago
Duplicate of this bug: 452730

Updated

9 years ago
Blocks: 394240
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?
Attachment #333330 - Flags: review?(roc)
With this patch, can you actually operate the dialog with the mouse? I'm not sure why this would work.
Yes, I don't know why the patch works, either, to be honest.

Comment 64

9 years ago
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.
Flags: blocking1.9.1? → wanted1.9.1+

Updated

9 years ago
Duplicate of this bug: 461679
Duplicate of this bug: 466374

Updated

8 years ago
Assignee: jag → nobody
How do I cancel a drag?
(In reply to comment #67)

By pressing Escape...
(In reply to comment #68)
> (In reply to comment #67)
> 
> By pressing Escape...

Heh, I meant, how can I cancel a native drag programmatically?
Duplicate of this bug: 477499
No longer blocks: 394240
Duplicate of this bug: 394240
Duplicate of this bug: 486876
Duplicate of this bug: 507854
Flags: wanted1.9.2?
Neil, see comment #69
Flags: wanted1.9.2? → wanted1.9.2+

Comment 75

8 years ago
(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.
Duplicate of this bug: 517197
Hardware: x86 → All
Duplicate of this bug: 472836
Duplicate of this bug: 531828
Comment on attachment 333330 [details] [diff] [review]
patch?

minusing because I think we don't understand why this would work
Attachment #333330 - Flags: review?(roc) → review-

Updated

7 years ago
Duplicate of this bug: 556680

Comment 81

7 years ago
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.
Duplicate of this bug: 578628
Duplicate of this bug: 591630
Duplicate of this bug: 597489
Duplicate of this bug: 600792
status2.0: --- → ?

Comment 86

7 years ago
Not sure if bug 427687 is related, as it seems specific to moving tabs, and not 'dragging' in general.
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.
Severity: major → critical
Whiteboard: [Workaround: use keyboard to dismiss dialog] → [Workaround: use keyboard to dismiss dialog][has draft patch]
Duplicate of this bug: 609894
Duplicate of this bug: 318257
Duplicate of this bug: 427687

Comment 91

6 years ago
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.
Duplicate of this bug: 620299

Comment 93

6 years ago
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
Duplicate of this bug: 568456
status2.0: ? → wontfix

Comment 95

6 years ago
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

6 years ago
It means that it won't be fixed for Firefox 4. So it will have to be fixed in Firefox 5+.
Blocks: 644936
No longer blocks: 644936
Duplicate of this bug: 644936
Duplicate of this bug: 655232

Comment 99

6 years ago
Definitely still an issue - ran into it just today.
Duplicate of this bug: 562263
Duplicate of this bug: 728593

Comment 102

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
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.
Duplicate of this bug: 732247
Duplicate of this bug: 631472
Duplicate of this bug: 507781

Comment 109

5 years ago
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....
Duplicate of this bug: 745972
Duplicate of this bug: 747632

Comment 112

5 years ago
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

5 years ago
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

4 years ago
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.
Duplicate of this bug: 816434

Updated

4 years ago
Duplicate of this bug: 839744

Updated

4 years ago
Duplicate of this bug: 819691

Updated

4 years ago
Duplicate of this bug: 872977

Updated

3 years ago
Duplicate of this bug: 976093
Duplicate of this bug: 489360
Blocks: 977957
Flags: firefox-backlog?
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?
Assignee: nobody → mconley
Status: NEW → ASSIGNED
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?
Attachment #8409705 - Flags: review?(mhammond)

Updated

3 years ago
Flags: firefox-backlog? → firefox-backlog+
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
(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. :/
Flags: needinfo?(tabraldes)
Comment on attachment 8409705 [details] [diff] [review]
WIP Patch 1

Withdrawing review request because this is probably not the way to go.
Attachment #8409705 - Flags: review?(mhammond)
(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)
(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
Flags: needinfo?(tabraldes)
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.
Attachment #8409705 - Attachment is obsolete: true
Comment on attachment 8411255 [details] [diff] [review]
Patch v1

How do we feel about this?
Attachment #8411255 - Flags: review?(roc)
Comment on attachment 8411255 [details] [diff] [review]
Patch v1

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

Seems reasonable.
Attachment #8411255 - Flags: review?(roc) → review+
Sweet! Thanks roc.

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/0aab0a3738cf
https://hg.mozilla.org/mozilla-central/rev/0aab0a3738cf
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31

Updated

3 years ago
Whiteboard: [Workaround: use keyboard to dismiss dialog][has draft patch] → [Workaround: use keyboard to dismiss dialog][has draft patch] p=0 s=it-31c-30a-29b.3 [qa?]
Attachment #333330 - Attachment is obsolete: true
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.
Attachment #8411255 - Flags: approval-mozilla-aurora?
Attachment #8411255 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox30: --- → affected
tracking-firefox30: --- → +
remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/fa4aff8faf05
status-firefox30: affected → fixed
Depends on: 1001549
status-firefox31: --- → fixed
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!
Flags: needinfo?(florin.mezei)
QA Contact: florin.mezei
Whiteboard: [Workaround: use keyboard to dismiss dialog][has draft patch] p=0 s=it-31c-30a-29b.3 [qa?] → [Workaround: use keyboard to dismiss dialog][has draft patch] p=0 s=it-31c-30a-29b.3 [qa+]
See Comment #133 for the (low) risk of having to back this out if it goes to Aurora without being verified.

Updated

3 years ago
Whiteboard: [Workaround: use keyboard to dismiss dialog][has draft patch] p=0 s=it-31c-30a-29b.3 [qa+] → [Workaround: use keyboard to dismiss dialog][has draft patch] p=0 s=it-32c-31a-30b.1 [qa+]
Flags: needinfo?(florin.mezei)
QA Contact: florin.mezei → camelia.badau
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.
Status: RESOLVED → VERIFIED
status-firefox30: fixed → verified
status-firefox31: fixed → verified
Whiteboard: [Workaround: use keyboard to dismiss dialog][has draft patch] p=0 s=it-32c-31a-30b.1 [qa+] → [Workaround: use keyboard to dismiss dialog][has draft patch] p=0 s=it-32c-31a-30b.1 [qa!]

Updated

3 years ago
Depends on: 1003194

Comment 138

3 years ago
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.
(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.)
(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.
Flags: needinfo?(mconley)
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!
Flags: needinfo?(mconley)

Updated

10 months ago
Depends on: 1280031
You need to log in before you can comment on or make changes to this bug.