|Subject:||bug#7464: 24.0.50; mouse highlighting vanishes upon unsplitting window|
|Date:||Fri, 30 Mar 2012 09:43:52 +0200|
|User-agent:||Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0|
Hello. Eli Zaretskii skrev 2012-03-29 20:47:
From: Stephen Berman<address@hidden> Cc: address@hidden, address@hidden Date: Thu, 29 Mar 2012 09:57:53 +0200 openSUSE's 23.3 has GTK scroll bars, while I built 23.4 like I build 24, i.e., without toolkit scroll bars. So I rebuilt 23.4 with GTK scroll bars, did the bug recipe and sure enough, now the mouse highlighting remained, i.e., no bug. Then I disabled the scroll bars in that build, tested again, and got the bug again. Then I rebuilt Emacs 24 with GTK scroll bars, and now did not see the bug with them enabled but did see it with them disabled. So the answers to my questions above appear to involve the presence vs. absence of GTK scroll bars. (I guess Chong Yidong also builds Emacs 24 with GTK scroll bars and tested the recipe with them enabled, so that's why he did not observe the bug.)Unfortunately, I know almost nothing about how GTK in general and GTK scroll bars in particular are integrated into Emacs, and what, if anything, they change in how the Emacs display engine works.
It probably has something to do with the fact that Gtk+ scrollbars aren't handeled by the display engine and we therefore have to force a redraw of the scroll bars at certain points so the scrollbars look ok. Presumably one of these redraws does something that triggers a redraw of mouse highlight? It might be that a redraw of the scroll bar generates some X expose/configuration event that in turn invokes the display engine. I'm just speculating.
|[Prev in Thread]||Current Thread||[Next in Thread]|