I cannot reproduce that issue under Emacs 24 or 25.  Mouse-1 clicks in
either the menu and toolbar in a part with no menu or icon appear to be
simply ignored.

I used ldd to confirm that the emacs binary uses Gtk3.  I am using KDE 5.15
though, unlike the OP's 4.14.

Best Regards,
Jeff

On Sun, Mar 6, 2016 at 6:26 AM, Stephen Berman <stephen.berman@gmx.net>
wrote:

> Jeff,
>
> Since (based on your reply to bug#3195) you appear to use KDE, can you
> reproduce this bug -- in particular, the observation (repeated in the
> last paragraph below) that clicking with mouse-1 on an empty part of the
> Emacs menu bar (i.e., a part containing no menu bar item) makes the
> mouse pointer changes to "move" mode for relocating the frame on the
> desktop by dragging?  If you can and have any idea how to debug it, I'd
> be very interested to hear.
>
> Steve Berman
>
> On Mon, 11 Jan 2016 10:49:02 +0100 Stephen Berman <stephen.berman@gmx.net>
> wrote:
>
> > On Mon, 11 Jan 2016 18:17:43 +1100 Alexis <flexibeast@gmail.com> wrote:
> >
> >> Sorry it's taken so long to get back to you. Do you still observe this
> >> behaviour with more recent versions of Emacs?
> >
> > Yes, I still see this with current builds of emacs-25 and master (built
> > with GTK+ 3.14.15) running in KDE 4.14.9 on openSUSE 13.2.  However, in
> > checking the behavior again now, it seems this is normal in KDE: the
> > same thing happens when I switch focus to any KDE application by
> > clicking on a menu bar item.  Once difference between Emacs and other
> > KDE applications is that with the latter, moving the mouse pointer over
> > a menu bar item highlights it, even when the application window is not
> > in focus, whereas moving the mouse pointer over an Emacs menu bar item
> > does not highlight it (it gets highlighted only when it's clicked, which
> > brings it into focus here).  Perhaps this is a limitation of the gtk-qt
> > engine or a theme issue which I didn't notice or didn't obtain at the
> > time of my OP.  Anyway, as far as the behavior of my OP is concerned, I
> > now think it is not an Emacs bug.
> >
> > However, there is a related behavior which appears to be Emacs-specific:
> > if I click with mouse-1 on an empty part of the Emacs menu bar (i.e., a
> > part containing no menu bar item), then the mouse pointer changes to
> > "move" mode for relocating the frame on the desktop by dragging.  As
> > with the menu bar item behavior, no other mouse or keyboard action is
> > possible until I hit ESC.  This happens both when switching focus to the
> > Emacs frame as well as when it is already in focus.  This "move"
> > functionality of the mouse pointer is bound to the key combination
> > Alt+mouse1 in my KDE (the default binding), as well as to clicking and
> > holding down mouse-1 on the application window title bar, but Emacs is
> > the only application in which clicking on an empty part of the menu bar
> > also activates it, and I often do that unintentionally when switching
> > focus, so it's annoying -- all the more so, since the mouse pointer
> > remains in "move" mode even after releasing the mouse button (whereas
> > when pressing Alt+mouse1 or clicking on the title bar, "move" mode is
> > active only while holding down the mouse button).  In fact, I encounter
> > this much more often than the menu bar item behavior, and while I don't
> > remember if it also happened at the time of my OP, I think I would have
> > noticed it then, given how frequent and annoying it is.  Moreover,
> > although in my OP I said I couldn't reliably reproduce the behavior, it
> > is 100% reprodicible with my current Emacs and KDE, in both the menu
> > item and "move" realizations, though again, only the latter is
> > Emacs-specific and hence relevant to this bug.
> >
> > Steve Berman
>