Bug#800747: wesnoth-1.12: Some buttons don't respond to mouse clicks

[Ben Longbons]

Control: clone -1 kwin-x11
Control: retitle -1 Wesnoth UI does not work properly if WM does not
respect requested size.
Control: retitle -2 KWin 5 does not respect resize requests if the
application starts maximized.

(hopefully that control stuff works right ...)

I have further isolated the bug, and not filed it upstream.

What happens is that wesnoth starts in a window that is maximized (I'm
running under kwin 5 at 1366x768), and then I use the kwin
"fullscreen" option (either from the window corner menu or the
keyboard shortcut - alt-enter by default) to change it to fullscreen.
Any buttons that were not visible in the maximized window (off the
bottom of the screen - I have both a top taskbar and a bottom one) are
not clickable.

I also observed that, when the window is maximized, going into
preferences and requesting a resolution change does NOT work. This is
likely related - wesnoth should only be drawing its UI in the
resolution that the window manager gives it, regardless of whether or
not that resolution is satisfying its request. I believe that other
WMs typically implement "resize to native resolution" as an implicit
request for fullscreen.

Note: the reason I start Wesnoth in windowed mode and then switch it
to fullscreen from the WM is that SDL1's fullscreen support steals all
input focus from the WM and forcibly changes the resolution, whereas
WM fullscreen is implemented as resize with no border. I *think* SDL2
supports the "nice" fullscreen (not sure by default?).

Upstream documentation indicates that 1.13 should be switching to SDL2
eventually, but that doesn't seem to have been done yet for the
version that Debian has packaged.

Workaround: leave fullscreen, unmaximize the wesnoth window, then
resize it (either from in-game or by dragging the corners in the WM -
which will give a resize event that wesnoth recognizes), then enter
fullscreen again. Note that merely unmaximizing (without resizing)
will leave wesnoth in a buggy state, and is a simple way to make even
*more* buttons unresponsive.

Summary: I believe there are at least two bugs here: the KWin not
respecting the application's request, and Wesnoth (or possibly SDL)
not properly respecting it. I am fairly certain that the
mouse-specific issue is merely a side effect of the resize-related
bugs.

-Ben


On Thu, Oct 8, 2015 at 2:05 PM, Vincent Cheng <vcheng at debian.org> wrote:
> Control: tags -1 + moreinfo unreproducible
>
> Hi Ben,
>
> On Sat, Oct 3, 2015 at 12:45 AM, Ben Longbons <brlongbons at gmail.com> wrote:
>> Package: wesnoth-1.12
>> Version: 1:1.12.4-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> A handful of the UI buttons cannot be clicked (tested with multiple mice).
>>
>> In particular I have noted:
>>
>> * The "End Turn / End Scenario" button (action menu or ctrl-space works)
>> * The "OK" button in the Addons Manager (double-click or enter works)
>> * The "Close" button in Help/Unit Description (escape works)
>>
>> This did not occur with wesnoth-1.10.
>>
>> Using the keyboard shortcuts or alternative mouse actions above still works,
>> and the mouse works perfectly on all other buttons that I have noticed.
>>
>> (I normally use the keyboard, but was demoing the game for a friend, so
>> this was quite embarrassing.)
>>
>> There is also something funny with clicking on a unit that has
>> had the spacebar pressed to ignore its remaining move for the N key. It
>> cannot be moved unless you press space again and *then* press the N key.
>
> Unfortunately I cannot reproduce this at all; UI buttons work as
> expected for me.
>
> I have no idea what might be causing this issue; you may want to
> report this directly upstream and see if they have any suggestions.
> Instructions for filing a bug report for wesnoth can be found at [1].
>
> Regards,
> Vincent
>
> [1] http://wiki.wesnoth.org/Reportingbugs