Closed Bug 100180 Opened 23 years ago Closed 10 years ago

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

Categories

(Core :: XUL, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla31
Tracking Status
firefox30 + verified
firefox31 --- verified
status2.0 --- wontfix

People

(Reporter: Erik.Bruchez, Assigned: mconley)

References

(Depends on 2 open bugs)

Details

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

Attachments

(6 files, 2 obsolete files)

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.
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
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 82910 has been marked as a duplicate of this bug. ***
isn't this a dupe of bug 63139 ?
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Target Milestone: Future → ---
*** Bug 143554 has been marked as a duplicate of this bug. ***
i think this may have been fixed quite a while back in bug 96504
*** Bug 180428 has been marked as a duplicate of this bug. ***
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
 
Request: drag operations must be canceled on such events!
*** Bug 138748 has been marked as a duplicate of this bug. ***
*** Bug 106464 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
*** Bug 237251 has been marked as a duplicate of this bug. ***
*** Bug 235154 has been marked as a duplicate of this bug. ***
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.
*** Bug 237082 has been marked as a duplicate of this bug. ***
*** Bug 238253 has been marked as a duplicate of this bug. ***
*** Bug 210819 has been marked as a duplicate of this bug. ***
*** Bug 257666 has been marked as a duplicate of this bug. ***
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?

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.

corresponding Firefox bug is Bug 246801
*** Bug 270635 has been marked as a duplicate of this bug. ***
Summary: UI freezes if alert comes up while dragging → UI freezes if alert/dialog comes up while dragging
*** Bug 243683 has been marked as a duplicate of this bug. ***
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)
*** Bug 157168 has been marked as a duplicate of this bug. ***
Blocks: 246801
*** Bug 285720 has been marked as a duplicate of this bug. ***
*** 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
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. ***
*** Bug 353735 has been marked as a duplicate of this bug. ***
Keywords: hang
Attached file testcase
It also happens when an alert is called on a dragenter/dragover event.
Keywords: testcase
(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-
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.
(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
(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+".
Reproducible with Firefox 3.0 RC1 with Windows XP.
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")
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)
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].
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);|
No longer blocks: 246801
Severity: normal → major
Flags: blocking1.9.1?
QA Contact: jrgmorrison → xptoolkit.widgets
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.
Attached file 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.
Attached file testcase3
IE seems to cancel the drag just fine for modal dialogs.
Attached patch patch? (obsolete) — Splinter Review
This seems to work.
But after the dialog is dismissed, you still get a drop effect, which shouldn't happen.
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.
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+
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?
No longer blocks: 394240
Flags: wanted1.9.2?
Flags: wanted1.9.2? → wanted1.9.2+
(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.
Hardware: x86 → All
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-
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.
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]
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.
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
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?
It means that it won't be fixed for Firefox 4. So it will have to be fixed in Firefox 5+.
No longer blocks: 644936
Definitely still an issue - ran into it just today.
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.
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.
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).
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.
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....
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,
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.
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.
Blocks: 977957
Flags: firefox-backlog?
Attached patch WIP Patch 1 (obsolete) — Splinter Review
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)
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)
Attached patch Patch v1Splinter Review
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+
https://hg.mozilla.org/mozilla-central/rev/0aab0a3738cf
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
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+
Depends on: 1001549
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.
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
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!]
Depends on: 1003194
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)
Depends on: 1280031
Flags: in-qa-testsuite?
Flags: in-qa-testsuite?
You need to log in before you can comment on or make changes to this bug.