jr...@devio.us (Josh Rickmar) wrote:

> Hi,
>
> I'm doing some development work on xombrero.  We recently (last month
> or so) switched to GTK3 (3.4.4 on my OpenBSD/amd64 system), and have
> noticed some recurring focus issus.  Unfortunately, we haven't found a
> good way to reproduce them, and that has made it incredibly hard to
> debug.
>
> For whatever reason, we've found that after a while our browser will
> enter a weird state where many things begin to break.  Searching a
> webpage with the '/' key and pressing enter no longer focuses the
> WebKitWebView, and keyboard commands no longer work.  Our link hinting
> works correctly in all cases except if we press enter (the hints on
> the page are never cleared, until a new page is loaded).  And, the
> text cursor in our URL and search bars becomes completely invisible.
>
> After some more looking around it seems that our main toplevel
> GtkWindow no longer has the is-active and has-toplevel-focus
> properties set to true.  We think this is the cause of the invisible
> cursor (just as how the cursor becomes invisible if you use your
> window manager to focus a different window), and believe the other
> bugs are a result of it as well (perhaps not all signal callbacks are
> being run?).
>
> I'm not sure if this is a bug in GTK3, or our fault due to a bad
> switch to GTK3. Has anyone seen this sort of eratic behavior when
> switching applications to GTK3?  If not, can anyone point me in the
> right direction about what possible things may be causing this
> toplevel window from losing those active and focus properies?  This
> bug is driving us nuts and we'd love to get it solved before our next
> major release.  Any help would be greatly appreciated.
>
> -- 
> Josh Rickmar
> http://jrick.devio.us/

So this may cause even more fallout for being so hackish, but I think
I found a workaround.

I went through the GTK source code and found the
_gtk_window_set_is_active function.  I manually added a prototype for
this function to our code (because it is not declared static) and was
able to use it to confirm that it was the is-active property being set
to false that was causing all of our issues.  As a workaround, I'm now
calling this function, setting this property to true, before any
GtkEntry is foucsed (to get rid of the invisible cursor), and before
any keypress is handled.

Can anyone see any potential issues with this workaround, and have a
better idea about how to remove this issue in the first place?

-- 
Josh Rickmar
http://jrick.devio.us/
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Reply via email to