This was broken since commit b2aaa94 in 2008. Its commit message
clearly states that the intention was to check for GTK_GRAB,
GTK_UNGRAB and STATE_CHANGED. Lets do that, then.
This was found by Coverity.
gtk+ was trying to display already freed strings, leaking memory,
...I noticed this because I was getting weird blinking characters
as the status of my cups printers, and valgrind confirmed something
was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=683072
When checking for modal grabs in gtk_main_do_event(), forward
GDK_SCROLL events to event_widget, even if it is insensitive.
(cherry picked from commit 343f1706bd)
In gtkimcontextime.c, use gdk_win32_window_get_impl_hwnd() to get to
the impl's existing native window instead of GDK_WINDOW_HWND() which
implicitly ensures a native window for the widget itself. This seems
to work around whatever GDK problem with native subwindows and fixes
the bug.
This is based on Michael Natterer's fix for gtk-2-24.
We must not release the GtkClipboardOwner in pasteboardChangedOwner
becaue we don't own a reference to ourselves (NSPasteboard does).
Instead, release the owner right after setting it, transferring
ownership to NSPasteboard
Also, fix repeated setting of the same owner by keeping the
owner around in GtkCLipboard, and re-use it if "user_data"
doesn't change. To avoid clipboard_unset()ting our own contents
in the process, add an ugly "setting_same_owner" boolean to
GtkClipboardOwner, set it during re-setting the same owner,
and avoid calling clipboard_unset() from pasteboardChangedOwner
if it's TRUE.
(cherry picked from commit 4a8df7a33c)
This is necessary because values in a GtkCssComputedValues can change
now. So if the font-size is inherited or animated, the cached value will
be outdated.
pasteboardChangedOwner is not called as reliably as we'd want to get it,
so keep track of [pasteboard changeCount] and drop clipboard ownership
when a change happened. Also better unset the clipboard content redundantly
in a few places rather than missing one, and reorder the code in
gtk_clipboard_set_contents() so that the new aggressive unsetting
won't unset the clipboard under our feet when we call
[pasteboard declareTypes].
(cherry picked from commit f2b74db5dc)
Both flashing a window and setting the window opacity were using
incorrect declarations for function pointers. They were missing the
WINAPI annotation as defined in windows.h. As a result, the stack
could be corrupted when these functions were invoked.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=689235
(cherry picked from commit 5637ef1f97)
The documentation for gtk_file_chooser_get_filenames() states that the
returned filenames are absolute paths, and uses g_file_get_path() to
construct the filename. The same function is used to construct the
filename in gtk_file_chooser_get_filename(), so it should also return
absolute paths.
https://bugzilla.gnome.org/show_bug.cgi?id=371034
When event capturing is enabled, stop propagating scroll events
at insensitive widgets, but don't handle them (don't return TRUE),
so they can bubble up again and reach their handling widgets.
(cherry picked from commit 2d9454363f)
