GNU bug report logs - #31546
27.0.50; macOS child frames with no mode-line mouse click problem

Previous Next

Full log

View this message in rfc822 format

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 31546 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: bug#31546: 27.0.50; macOS child frames with no mode-line mouse click problem
Date: Wed, 23 May 2018 04:14:19 -0700

On Tue, May 22, 2018 at 11:36 PM martin rudalics <rudalics <at> gmx.at> wrote:
> Now I am confused.  Is this in any way related to the OP's report?
> There the window below in the z-order gets scrolled but here you seem
> to mean that a mouse click affects the window above in the z-order.

I'm the OP. I'm sorry if I wasn't clear in the initial report. The problem
is that the child frame (which appears on top of the parent frame) gets
scrolled on click. In this gif, the visible frame is the child frame:
https://dzwonsemrish7.cloudfront.net/items/3p2o232r1S333y1o1H3S/Screen%20Recording%202018-05-22%20at%2005.44%20AM.gif?v=b53e93c1

> I still don't understand which command gets executed in order to
> scroll the parent frame's window.  That is, if with emacs -Q I click
> anywhere on my single frame's only window's mode line, that window
> never scrolls.  So please tell me how your window gets scrolled.

I do not know what the command is that is scrolling the child frame. It
does not appear in view-lossage.

> If "the frame" is a child frame then this problem is pertinent to your
> windowing system: With X or Windows child frames cannot be moved out
> of their parent frames.

This may be, but I'm at a loss as to how my windowing system would increase
the height of an emacs window. It seems more likely that it is due to some
bug in nsterm, but I have been wrong before.

Thanks,

Aaron

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.