"critical" severity seems a bit exagerated on this one. Severity hyperboles generaly don't help upstream developers be in a good mood when discovering a new bug report.

I chose "critical" since "data loss" was part of this level's characterization. However admittedly we're talking of usually mild data loss here (in many cases people would remember what they selected, as opposed to e.g. full-disk data loss).


I just grabbed zenity source and built it, yet then (post-build!) found that whenever removing the
    <property name="selectable">True</property>
line from
    <object class="GtkLabel" id="zenity_info_text">
in zenity.ui file, the dialog's text label becomes non-selectable, *and the X11 primary selection's content remains alive*.

So that seems to point at a selection issue in GTK core areas!?
(IMHO it's simply still not acceptable to have "selectable" text nullify prior selection content - it should simply replace the selection the moment that the user does a new selection, and not a nanosecond before that event)

I'm now trying to whip up a quick Python example to cross-verify these observations.

Hello,

Thanks for the bug, I'm moving to another country, and I will be with restrict access to internet for the next two weeks. I will take a look when I settle down.

Kind regards

I've now installed libgtk-3-0-dbg and found out that selection destruction also depends on
     <property name="can_focus">True</property>
being available.
I then started another gdb session with
    set args --info --text foobar
, and then did
    b gtk_selection_owner_set
    b gtk_selection_owner_set_for_display
    run

I then hit gtk_selection_owner_set_for_display
(gdb) bt full

+ Trace 233929

fin:ishing that function entry then made the prior selection disappear,
which confirms that it's processing within this function which is responsible.

I then had a look at

static void
gtk_label_grab_focus (GtkWidget *widget)
{
  GtkLabel *label;
  gboolean select_on_focus;
  GtkLabelLink *link;

  label = GTK_LABEL (widget);

  if (label->select_info == NULL)
    return;

  GTK_WIDGET_CLASS (gtk_label_parent_class)->grab_focus (widget);
  if (label->select_info->selectable)
    {
      g_object_get (gtk_widget_get_settings (widget),
                    "gtk-label-select-on-focus",
                    &select_on_focus,
                    NULL);

      if (select_on_focus && !label->in_click)
        gtk_label_select_region (label, 0, -1);
    }
  else
    {
      if (label->select_info->links && !label->in_click)
        {
          link = label->select_info->links->data;
          label->select_info->selection_anchor = link->start;
          label->select_info->selection_end = link->start;
        }
    }
}

of gtklabel.c
of http://www.cs.binghamton.edu/~sgreene/cs360-2011s/topics/gtk+-2.20.1/gtk/

where I found that it checks the gtk-label-select-on-focus property,
which seems to be TRUE for our case, which is why it proceeds with calling into the selection-destroying gtk_label_select_region().




OK, so in general for this issue we have a backtrace of:
gtk_label_grab_focus
-> gtk_label_select_region
-> gtk_label_select_region_index
-> gtk_clipboard_set_with_owner
-> gtk_clipboard_set_contents
-> gtk_selection_owner_set_for_display


But note that after the first gtk_label_select_region(), gtk_dialog_map() does
another unconditional gtk_label_select_region(..., 0, 0) on that label!?!?
(to choose the dialog's focussed widget)
But even *before* that second gtk_label_select_region(), the primary selection is already zilched. This might possibly be because the dialog window is not actually mapped yet at the first invocation, thus we even never end up with the label string (here: "foobar") in the primary selection (to add insult to injury).

And this second gtk_label_select_region(): gtk_dialog_map() -> gtk_label_select_region(..., 0, 0) -> gtk_label_select_region_index() -> gtk_clipboard_clear()
*actively* clears primary selection! (i.e. a manually chosen selection will be unavailable from that moment)


I'm now wondering whether we're staring in the face of toolkit handling bugs
in the case of clipboard processing relating to GtkLabel widget selection changes.
After all why would focus handling and/or tab group handling changes
need to destroy a pre-existing foreign-application primary selection,
prior to actual *user-side* manual selection changes??

Possibly this issue should thus be forwarded to the relevant GTK package instead...


Side note: I have to admit that I've already had major PITA
(quite a bit worse than most other "interesting" GUI widget areas)
with GTK's behaviour in this area
(selection behaviour of wxWidgets wxTextCtrl, in wxGTK port),
which caused me to have to implement multiple workarounds
against "unexpected" selection behaviour there.

Created attachment 282542 [details] [review]
Workaround/hotfix to avoid loss of foreign X11 primary selection content

Setting the gtk-label-select-on-focus property of the label widget to FALSE manages to avoid the primary selection loss which occurs on every launch of zenity --info --text foobar. Further docs see source (patch).

Patch against zenity 3.8.0 as available on my Debian testing,
but given some luck it should easily apply to trunk, too.

While this is a workable hotfix, this issue quite likely should still end up as an issue report of GTK libraries proper, if only to have a clarifying discussion about why clipboard / primary selection / widget focus behaviour is (possibly rightfully) implemented the (rather annoying) way it is.

Fixed on master.