Mouse capture should be released when losing focus

[Jiří Techet]

Hi,

with code::blocks (which uses wxScintilla) I ran into a problem where
when a selection was being made with the mouse and some dialog
appeared, the whole system got frozen. After some experimenting I
realised that this happens because of scintilla - scintilla doesn't
release mouse capture when losing focus so what happens is that all
input is captured by scintilla, but it cannot get it because a modal
dialog is displayed in front of it and the modal dialog cannot get the
input because it's captured by scintilla - deadlock.

This problem doesn't seem to be so serious with gtk scintilla - I've
tested it with SciTE by selecting some text and at the same time
pressing Ctrl+O. Then you can release the mouse button and close the
dialog. What happens is that the editor behaves as if the mouse button
was depressed and you can select text without pressing the button.

Even though the problems with gtk are much less serious, I think this
should get fixed so I'm sending a trivial patch that should fix this
problem (I sent similar patch to code::blocks developers as well).

Thanks for the great component and Happy New Year!

Jiri

[Neil Hodgson]

Jiří Techet:

> Even though the problems with gtk are much less serious, I think this
> should get fixed so I'm sending a trivial patch that should fix this
> problem (I sent similar patch to code::blocks developers as well).

This isn't needed on Windows because application hot keys aren't
processed during capture and global commands like Alt+Tab
automatically break capture and send WM_CAPTURECHANGED so Scintilla's
internal state can be reset. I don't think it is safe to drop capture
for focus out in the platform-independent code since there could be
problems with dropping capture twice or reentrance if the platform
performs some automatic capture manipulation. Therefore, it would be
better to place any such code in the platform layer where it can be
tweaked.

GTK+ is complicated by there being two capture (grab) mechanisms. A
higher level one used by Scintilla (gtk_grab_add / gtk_grab_remove)
and a low level one (gdk_pointer_grab). The corresponding
notifications are grab_notify and grab_broken_event. GTK+ restores the
capture state to Scintilla after the open dialog is closed because it
is managing a stack of grab widgets. GTK+ (or possibly the Window
Manager) doesn't allow Alt+Tab while in grab. Since it appears GTK+
does not automatically release grab upon focus drop, it may be OK to
release grab then but I could imagine other scenarios such as the
application displaying helper widgets and moving focus to them so that
they receive keystrokes.
http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#GtkWidget-grab-notify

Neil

[Jiří Techet]

Hello Neil,

On Sat, Jan 2, 2010 at 14:01, Neil Hodgson <nyama...@gmail.com> wrote:
> Jiří Techet:
>
>> Even though the problems with gtk are much less serious, I think this
>> should get fixed so I'm sending a trivial patch that should fix this
>> problem (I sent similar patch to code::blocks developers as well).
>
>   This isn't needed on Windows because application hot keys aren't
> processed during capture and global commands like Alt+Tab
> automatically break capture and send WM_CAPTURECHANGED so Scintilla's
> internal state can be reset. I don't think it is safe to drop capture
> for focus out in the platform-independent code since there could be
> problems with dropping capture twice or reentrance if the platform
> performs some automatic capture manipulation. Therefore, it would be
> better to place any such code in the platform layer where it can be
> tweaked.

OK, I see - things are much more complicated than I thought so you are
right that it's better to move this to the platform layer. wxWidgets
don't have any capture stack and the stack manipulation functions are:

virtual void wxWindow::ReleaseMouse()
virtual void wxWindow::CaptureMouse()
virtual bool wxWindow::HasCapture() const

and wxMouseCaptureLostEvent, wxMouseCaptureChangedEvent events (under
Windows only).

Because there is no capture stack there, I think the best way to test
and set the capture is to call wxWidgets directly:

bool ScintillaWX::HaveMouseCapture() {
return sci->HasCapture();
}

void ScintillaWX::SetMouseCapture(bool on) {
if (mouseDownCaptures) {
if (on && !sci->HasCapture())
sci->CaptureMouse();
else if (!on && sci->HasCapture())
sci->ReleaseMouse();
}
}

and call SetFocusState() when EVT_KILL_FOCUS of wxWidgets is received.

But also with other platforms you shouldn't be able to drop capture
twice since from what I've seen, the platform code tests whether it
has capture (plus in addition you could add HaveMouseCapture() test to
the platform-independent code)

>   GTK+ is complicated by there being two capture (grab) mechanisms. A
> higher level one used by Scintilla (gtk_grab_add / gtk_grab_remove)
> and a low level one (gdk_pointer_grab). The corresponding
> notifications are grab_notify and grab_broken_event. GTK+ restores the
> capture state to Scintilla after the open dialog is closed because it
> is managing a stack of grab widgets. GTK+ (or possibly the Window
> Manager) doesn't allow Alt+Tab while in grab. Since it appears GTK+
> does not automatically release grab upon focus drop, it may be OK to
> release grab then but I could imagine other scenarios such as the
> application displaying helper widgets and moving focus to them so that
> they receive keystrokes.
> http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#GtkWidget-grab-notify

I think that in such scenarios the applications should re-capture the
scintilla window by themselves.

>   Neil

Thanks,

Jiri

[Neil Hodgson]

Jiří Techet:

> Because there is no capture stack there, I think the best way to test
> and set the capture is to call wxWidgets directly:

While there are often people from wxWidgets reading this list, its
better to push the issue onto the wxWidgets bug tracker to ensure it
is noticed.

> I think that in such scenarios the applications should re-capture the
> scintilla window by themselves.

People expect their applications to continue working when a new
version of Scintilla is released.

Neil

[Jiří Techet]

On Sun, Jan 3, 2010 at 10:02, Neil Hodgson <nyama...@gmail.com> wrote:
> Jiří Techet:
>
>> Because there is no capture stack there, I think the best way to test
>> and set the capture is to call wxWidgets directly:
>
>   While there are often people from wxWidgets reading this list, its
> better to push the issue onto the wxWidgets bug tracker to ensure it
> is noticed.

wxScintilla isn't part of wxWidgets and the original wxScintilla
project seems to be kind of abandoned (last CVS commit 3 years ago
based on Scintilla 1.73). The most recent version of wxScintilla seems
to be the branch that codeblocks uses (based on 1.77) so I've
submitted the patch there (I'll post a link to this discussion there
as well). A bit pity that the development of wxScintilla is scattered
in this way...

>
>> I think that in such scenarios the applications should re-capture the
>> scintilla window by themselves.
>
>   People expect their applications to continue working when a new
> version of Scintilla is released.

Understand that - even though this feature isn't probably used
frequently, it's better to be safe. After all the problem under gtk
isn't at all as serious as under wxWidgets.

Jiri

[MortenMacFly]

> wxScintilla isn't part of wxWidgets and the original wxScintilla
> project seems to be kind of abandoned (last CVS commit 3 years ago
> based on Scintilla 1.73).

Nope, actually it's being actively developed as STC component inside
the wxWidgets itself. Especially the 29 branch and trunk have quite up-
to-date sources. Hence it's not called wxScintilla.

> The most recent version of wxScintilla seems
> to be the branch that codeblocks uses (based on 1.77)

That might be true.