From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: A GTK-only problem when making frames invisible Date: Sat, 04 Feb 2017 18:02:59 +0100 Message-ID: <58960943.7090805@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1486227909 7300 195.159.176.226 (4 Feb 2017 17:05:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Feb 2017 17:05:09 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 04 18:05:06 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ca3lp-0001h6-VQ for ged-emacs-devel@m.gmane.org; Sat, 04 Feb 2017 18:05:06 +0100 Original-Received: from localhost ([::1]:40133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ca3lv-0005tC-Mt for ged-emacs-devel@m.gmane.org; Sat, 04 Feb 2017 12:05:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ca3k0-0004Wv-Sw for emacs-devel@gnu.org; Sat, 04 Feb 2017 12:03:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ca3jx-0000I1-Q8 for emacs-devel@gnu.org; Sat, 04 Feb 2017 12:03:12 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:65493) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ca3jx-0000GK-FJ for emacs-devel@gnu.org; Sat, 04 Feb 2017 12:03:09 -0500 Original-Received: from [192.168.1.100] ([213.162.68.70]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MdWO8-1coRKd20xY-00PNg0 for ; Sat, 04 Feb 2017 18:03:03 +0100 X-Provags-ID: V03:K0:kRTU/8kSBQz5zdyRm7bPeD8Syp+q+dsHTsKhVksLSrKx3q221iG GgMQO+kwfASvNEXMAjUxp0KGexf+hY4h0JfgOK+xvg2vi8ovbMf80C1GJCrlLtEN71d6vON //mWhYeBFhWbdJ31i9N0DFWoL8n+AeZlQwse8B/udVFo0W9zE3plifZelORa8ho+ax7+Ko7 eb5Y67Vr83c44SVv2/eYA== X-UI-Out-Filterresults: notjunk:1;V01:K0:GgKuAwwcWZI=:2A6FFihzx8H4pUlFuDMkqZ Uc2VAf0oYodMB7jzi/k+rnRIeaSqFzn3cSHn0nZN67JF/NvVZX79D41DM+dqk1MQbSYdeWhlc mgaACkdZNhRSfy58oEm9ZLKdlsQq0kzYP+Rfi9TR0g8Er7zTBWlWTBHiTUF0oO/GsbaTfq5r2 D0zPRFnrR1r2mJ5kUvtiTJPyJws+HmXMpHyfXLBKs0UsOghkjACN02pBLlfjWsjoDGgQXAHct e8PzNT/dnmv3UGGYnUtXcGQkFPnAyP9FuHCiVIeSfNjWskqvU9X8oU2ac8QE303K6BhZ05fxs c00gEph6584SIvvSmsmiX7kGZDcrx879QJOzNegk51TsVUi7pSot9j8w6+TqzJAExZXk4GUBv l/1JXrJx0sJO3YjXp9I06wmMZhTtC5cYEyvuJpBC+2GVhvEU9ZqnbgZ21zTkbQgocgVK3QqqK mpA8i1YDUNqvll2ZbkPqeMz3OKVPlFKS5kGGVlrPbW4lKAu9YJte8xAXdXnQcvY1aF4j+vBwQ cvwPv2EevqIk5UFKkjydmie/kSlEkg6yhwM0ZtR8HOFuJUCkLl3RQ+HgBt/9j0qarwlvAccUZ SJkGU58BQV0sCBjZBf1cEmZW35MIXufPVai3YiZRYOQydDRr1CoTZiv+l8rE7IcjT0gKnOvGp ELhEsQAOonn26ceo5ayP0E7ojnHdD45ZtGmU118SCAsvqSfg3ufKVBn+TGSilpqaodjHtefjv L5+/p5x0ETo0DmyXIMjaAiSYmmR+BeZLSXkBpaF/0ST2sOrFg9fGZC7L+ZXT6LUtI7DTBZlb X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211962 Archived-At: Dear people For some time GTK builds of master here exhibit the following problem. Run emacs -Q, insert the three following lines in *scratch* (defvar frame (make-frame)) (make-frame-invisible frame) (frame-visible-p frame) and evaluate them line by line. Here, the last evaluation returns "icon" which is clearly wrong. Running the same procedure with older versions including the release candidate delivers "nil" which is correct. If a kind soul can reproduce the problem and has a sufficiently fast machine, it would be nice if she could bisect this to find the offending commit. Here building takes more than an hour so I'm not very eager to do that. I have a left over build from 2016-11-23 which already exhibits the problem so that commit should have occurred before that date. If anyone is interested in what happens, compare the results for running the output of xwininfo -root -tree -int with gdb output of a breakpoint in xterm.c around case Expose: f = x_window_to_frame (dpyinfo, event->xexpose.window); For the release session I get here: Parent window id: 0 (none) 49 children: 56623339 "*Messages*": ("emacs" "Emacs") 750x719+30+145 +30+145 2 children: 56623342 (has no name): () 750x648+0+71 +30+216 1 child: 56623372 (has no name): () 32000x32000+0+0 +30+216 56623340 (has no name): () 1x1+-1+-1 +29+144 (gdb) p event->xexpose.window $9 = 56623339 For the trunk session (at least after 2016-11-23) I get here: Parent window id: 0 (none) 49 children: 58720484 "*Messages*": ("emacs" "Emacs") 750x719+65+-50 +65+-50 2 children: 58720487 (has no name): () 750x648+0+71 +65+21 3 children: 58721343 (has no name): () 1x1+-1+-1 +64+20 58720516 (has no name): () 32000x32000+0+0 +65+21 58721338 (has no name): () 14x612+736+0 +801+21 58720485 (has no name): () 1x1+-1+-1 +64+-51 (gdb) p event->xexpose.window $5 = 58720487 Now x_window_to_frame produces no frame in the release session (IIUC because the 56623339 "*Messages* window is the window manager window) while it produces a frame (IIUC because window 58720487 is that frame's edit window). The subsequent code based on f not being zero contains an assignment that is responsible for setting the "iconified" state. Note also that the release session *Messages* window has one child while that of master has three. Thanks in advance, martin