From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: master 4b98a79a50: Improve X event timestamp tracking Date: Sun, 07 Aug 2022 01:43:43 -0400 Message-ID: <0b58658c390b8c62cc1c5dfadd9e1f0621f64d82.camel@dancol.org> References: <165984385935.14715.8191942019361575877@vcs2.savannah.gnu.org> <20220807034419.B5F2FC09BFD@vcs2.savannah.gnu.org> <87y1w0zpe9.fsf@yahoo.com> <87r11szp6h.fsf@yahoo.com> <19d020d85bed5d030e706800f8cbb0b7fbb3bc65.camel@dancol.org> <875yj4znp5.fsf@yahoo.com> <75aa6286819b4ca9b008a3697b293567321c0d86.camel@dancol.org> <87h72oy682.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10992"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.44.1-0ubuntu1 Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 07 07:47:51 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oKZ8f-0002gl-5Q for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 07:47:49 +0200 Original-Received: from localhost ([::1]:41122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKZ8d-0003el-Mq for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 01:47:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZ4o-0002Os-4r for emacs-devel@gnu.org; Sun, 07 Aug 2022 01:43:50 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:42298) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZ4l-0000ul-DE for emacs-devel@gnu.org; Sun, 07 Aug 2022 01:43:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Nx4fq/8+LLYTlYW/w/zIQ2W+msrWnG9PJsXCzMPDu2U=; b=Oc08OTGdNyALOk/rTm65eyNt01 +OFRJrbENj7qa5tCHjSiG9SZrq7BBeopEsjAD3wvRkTAYyHYz1pBcHMSoFNbE48ut79huYNbx9NN8 6UgxEY70KzTqG5fdOmHeX5ReVClF0oqaqUDsG8I3k5ed/DFFPx+XARA+RSaN+1ZPJP62sAfSgAlXV KxtFE65OGwrS89pkHB6plln0Y/gv5cBDveujxJnn9JldGYW1hEV5naOlD+OAuWybkRAvYmq4fVwSA xjrtCm8Nk3w1wH2UbjQ4h3+nBGuvhaNO2YcDtJOsQFxKNFZVhJMhTp/+G5wkI1PM9aZTliYR+41ZT 5yvv8X0g==; Original-Received: from 2603-9001-4203-1ab2-d8bc-e9aa-fed2-dc13.inf6.spectrum.com ([2603:9001:4203:1ab2:d8bc:e9aa:fed2:dc13]:59920) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oKZ4j-0007CX-C5; Sat, 06 Aug 2022 22:43:45 -0700 In-Reply-To: <87h72oy682.fsf@yahoo.com> Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293172 Archived-At: On Sun, 2022-08-07 at 13:26 +0800, Po Lu wrote: > The window manager doesn't get to decide what the > author of some Lisp code wanted. Yes, it does. That's the whole point of being the window manager. Are you suggesting that application developers, not users, ought to get the final word on what windows go where? > Our users and developers are not sloppy programmers who write code that > steals focus from other windows for no reason whatsoever. =C2=A0 Yes, they are sloppy, just like all other users and developers, you and me included, are sloppy. What's the old quip? Ah, right: "If men were angels, no laws would be necessary".=C2=A0If developers were perfect, we wouldn't need ASLR, or memory protection, or file permissions, or fuzzing, or memory-safe languages --- yet here we are. Developers of Emacs are no more angelic than developers using any other toolkit, and focus stealing prevention mitigates their mistakes as much as it does any others. If a user doesn't want focus stealing preventation, he can disable it or use a window manager that doesn't provide it. It's not the place of Emacs to override the user's preference. > The intent is > demonstrated by code calling x-focus-frame being written. If a process filter tries to asynchronously raise a window when the user is the middle of browsing cat pictures, and that user has configured his WM to block attempts by applications in the background to raise windows, the WM is right to block that raise attempt. The WM is where policy belongs. > > server.el is a special case:=C2=A0it's okay to break the usual event > > ordering here because the user *did* interact with Emacs, albeit > > through a side channel, not the X server. It's not that developers > > need to call two functions to make some API work, but rather, > > developers should call an additional function to communicate > > information to the core that allows an otherwise forbidden-by-design > > state transition to occur after all. >=20 > Why would the activation otherwise be "forbidden-by-design" (_our_ > design, not the design of the window manager authors?) Focus stealing > prevention doesn't exist on any other platform we support, so > x-focus-frame always works there. =C2=A0 >=20 It does exist elsewhere. From MSDN's page on SetForegroundWindow (https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setf= oregroundwindow) : The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true: * The process is the foreground process. * The process was started by the foreground process. * The process received the last input event. * There is no foreground process. * The process is being debugged. * The foreground process is not a Modern Application or the Start Screen. * The foreground is not locked (see LockSetForegroundWindow). * The foreground lock time-out has expired (see * SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo). * No menus are active. Also from that page: A process that can set the foreground window can enable another process to set the foreground window by calling the AllowSetForegroundWindow function. The process specified by dwProcessId loses the ability to set the foreground window the next time the user generates input, unless the input is directed at that process, or the next time a process calls AllowSetForegroundWindow, unless that process is specified. Guess what API emacsclient calls. > As such, users expect the same from > X. This is compounded by the fact that x-focus-frame says nothing about > requiring "user interaction" before the frame is activated. >=20 > > In other words, the clean abstraction *is* telling Emacs "Oh, by the > > way, the user interacted with this frame", not telling x-focus-frame > > "please, actually do your job for some reason". There's nothing X- > > specific about giving the Emacs core a hint that the user recently > > interacted with a frame in some manner not reflected in the normal > > flow of events. If most window systems want to ignore this hint, > > that's fine, but that doesn't make the hint a leaky abstraction. >=20 > It is a leaky abstraction because such a hint only exists on X, and was > never ever part of Emacs design. Other window systems don't "ignore > this hint", because such a hint simply does not exist. It's a generic hint that only one or two backends care about right now. That's not the same as a leaky abstraction. >=20 > > Don't you think it is the job of server.el to tell that window system > > core code a fact that it wouldn't have otherwise known --- that the > > user interacted with the frame in some manner the window system > > wouldn't have otherwise know about? >=20 > No. Lisp code not a platform implementation detail (be it in server.el > or whatever) does not have to know about this at all. Platform-implementation code shouldn't have to know about platform specifics. That's why frame operations should be generic and polymorphic, not ad-hoc and gated behind type tests. I'll say it again: server.el hinting to Emacs that the user has interacted with a frame is not an implementation detail of a window system. >=20 > > I think an invocation of gnuserver that raiess a window ought to count > > as interaction. There are probably other use-cases as well. >=20 > No, it's not. There is an actual startup notification protocol, but > it's not well suited for implementation in emacsclient. Startup notification isn't suitable here because we're not starting anything. >=20 > > Yes. Ideally, we'd detect in emacsclient that emacsclient and emacs > > were running on the same X server and transmit the command buffer as > > a ClientEvent --- and we'd update our user timestamp when we got that > > event, giving us a globally correct event ordering. In the meantime, > > the "user interacted out of band" hint seems like the most > > conservative approach for working around focus stealing mitigations. >=20 > Client events don't include timestamps, so while you can ensure "correct > event ordering" with those, you cannot get the server time from them. Emacsclient could include *its* server time in the message. > The actual protocol here is the startup notification protocol, which > emacsclient doesn't support for an obvious reason. Well, a related protocol would be nice. Feel free to propose one.