Running gnome-shell under valgrind, I saw the attached invalid write.
Basically we can destroy a window during event processing, and the old
window_remove_filters simply called g_free() on the filter, ignoring
the refcount. Then later in event processing we call filter->refcount--,
which is writing to free()d memory.
Fix this by centralizing list mutation and refcount handling inside
a new shared _gdk_window_filter_unref() function, and using that
everywhere.
==13876== Invalid write of size 4
==13876== at 0x446B181: gdk_event_apply_filters (gdkeventsource.c:86)
==13876== by 0x446B411: _gdk_events_queue (gdkeventsource.c:188)
==13876== by 0x44437EF: gdk_display_get_event (gdkdisplay.c:410)
==13876== by 0x446B009: gdk_event_source_dispatch (gdkeventsource.c:317)
==13876== by 0x4AB7159: g_main_context_dispatch (gmain.c:2436)
==13876== by 0x4AB7957: g_main_context_iterate.clone.5 (gmain.c:3087)
==13876== by 0x4AB806A: g_main_loop_run (gmain.c:3295)
==13876== by 0x8084D6B: main (main.c:722)
==13876== Address 0x1658bcac is 12 bytes inside a block of size 16 free'd
==13876== at 0x4005EAD: free (vg_replace_malloc.c:366)
==13876== by 0x4ABE515: g_free (gmem.c:263)
==13876== by 0x444BCC9: window_remove_filters (gdkwindow.c:1873)
==13876== by 0x4454BA3: _gdk_window_destroy_hierarchy (gdkwindow.c:2043)
==13876== by 0x447BF6E: gdk_window_destroy_notify (gdkwindow-x11.c:1115)
==13876== by 0x43588E2: _gtk_socket_windowing_filter_func (gtksocket-x11.c:518)
==13876== by 0x446B170: gdk_event_apply_filters (gdkeventsource.c:79)
==13876== by 0x446B411: _gdk_events_queue (gdkeventsource.c:188)
==13876== by 0x44437EF: gdk_display_get_event (gdkdisplay.c:410)
==13876== by 0x446B009: gdk_event_source_dispatch (gdkeventsource.c:317)
==13876== by 0x4AB7159: g_main_context_dispatch (gmain.c:2436)
==13876== by 0x4AB7957: g_main_context_iterate.clone.5 (gmain.c:3087)
https://bugzilla.gnome.org/show_bug.cgi?id=637464
Before hide_all was used on popup_window, which means popup_widget
was also unmapped. This is now no longer the case. This fixes
subsequent pop ups for appears-as-list == 1.
The old functions to get core pointer and devices list are gone as
well. This slice is entirely replaced internally by multidevice
handling and may just go.
Mention that it's safe to use <cell-packing> tag for any GtkCellLayout
in GTK+ since they *all* use an underlying GtkCellArea (at least they
will once the other branches land).
I have never really liked the updates done to the adjustments in
do_validate_rows() and other validation functions. But it is really
required. I have to come up with a real solution to this one day.
This fixes a GTK+ 3.0 regression. In GTK+ 2, the render method
on GtkCellRenderer had a expose_area parameter, typically set to
cell_area. This parameter was used for clipping cell content to be
rendered to the cell area (and thus clipping to within the focus
rectangle). During the rendering clean up this parameter was removed
and no clipping put back into place.
Since expose_area was usually equal to cell_area anyway, it does not make
sense to reintroduce the expose_area parameter. Instead, we do clipping at
two levels:
- in gtk_cell_renderer_render() we clip to background_area. We cannot
clip to cell_area here because we want to allow cell renderers to
render in the background area (e.g. background color/effect).
- cell renderers should clip to clip_area when rendering cell
content individually (as they had to individually clip to expose_region
before).
Check (x, y) is inside background area. If yes, continue processing
and clamp the coordinates into cell area. This way we will properly
handle getting a cell (which is only used for setting the focus cell)
for clicks in the indentation area (in LTR and RTL mode) and clicks
in the focus rectangle area in case focus-line-width is large.
The cell's focus rectangle is located around the cell's aligned area.
To get to the correct coordinates for this rectangle, we have to subtract
focus_line_width from the found aligned_area.
