Bug 767769 - Tracking bug for GTK+ regressions due to GDK_MOD1_MASK changes
Summary: Tracking bug for GTK+ regressions due to GDK_MOD1_MASK changes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk2
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 626792 766607 767766 767767
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-14 20:40 UTC by Felipe Contreras
Modified: 2012-02-02 18:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-02 18:49:00 UTC


Attachments (Terms of Use)

Description Felipe Contreras 2011-12-14 20:40:57 UTC
This problem can be seen in bugs bug #626792, bug #766607, bug #767766, and bug #767767.

So far vte and vte3 seem to be affected, but possibly others are too.

The solution for Fedora 16 should be to revert the GTK+ commit that broke things, presumably this one:
http://git.gnome.org/browse/gtk+/commit/?id=ac943bf69a87c992cfde59c6720ef08fdd20e683

That's bug #767766 for gtk2, and bug #767767 for gtk3.

At the same time, vte (bug #626792), vte3 (bug #766607), and possibly others should be fixed in rawhide for Fedora 17.

Comment 1 Felipe Contreras 2011-12-14 20:41:41 UTC
Adding dependencies.

Comment 2 Paul Howarth 2011-12-14 20:48:51 UTC
Switching component to gtk2 since gtk+ (gtk1) is not affected by this.

Comment 3 Matthias Clasen 2011-12-14 21:54:12 UTC
Whats the point in filing a ton of bugs after the problem has already been dealt with ?

Comment 4 Felipe Contreras 2011-12-15 01:07:19 UTC
(In reply to comment #3)
> Whats the point in filing a ton of bugs after the problem has already been
> dealt with ?

How exactly has it been dealt with?

Have you made sure that *all* GTK+ clients avoid GDK_MOD1_MASK/GDK_META_MASK as they are supposed to? I quick search in Google suggests that there's quite a lot of people using them, not only vte, so I doubt that.

And from what I can see GNOME's bug 663779 is still open.

And if this is the patch that is supposed to fix the issues:
http://bugzilla-attachments.gnome.org/attachment.cgi?id=201649

A quick look reveals major issues:

if (modifiers & VTE_META_MASK)
  modifiers |= VTE_META_MASK;

Are my eyes deceiving me, or is that a no-op?

Therefore the changes to use _vte_keymap_fixup_modifiers() are doing nothing. I would comment on the bug, but I was banned unfairly.

So the real change is:

-#define VTE_META_MASK		GDK_META_MASK
+#define VTE_META_MASK		(GDK_META_MASK | GDK_MOD1_MASK)

Which is basically kind of reverting these:

http://git.gnome.org/browse/vte/commit/?id=b73782a28894e25ed146271f9d6c6775a6836199
http://git.gnome.org/browse/vte/commit/?id=724195be5ba53c45d650366a8e029939c20d43a4

So, it seems like the behavior and meaning of these keys has been changing through the years. Such changes on behavior are *API breaks*, they shouldn't be introduced in gtk2-2.24.x, or even gtk2-2.x, but whatever, go ahead with those breaks.

But breaking API like that _certainly_ should not happen in Fedora 16.

Comment 5 Matthias Clasen 2011-12-15 01:27:19 UTC
(In reply to comment #4)

> A quick look reveals major issues:
> 
> if (modifiers & VTE_META_MASK)
>   modifiers |= VTE_META_MASK;
> 
> Are my eyes deceiving me, or is that a no-op?

They are. it is not a no-op, as is carefully explained in the upstream bug.

Comment 6 Felipe Contreras 2011-12-15 10:34:23 UTC
(In reply to comment #5)
> They are. it is not a no-op, as is carefully explained in the upstream bug.

Now I see, it has multiple bits enabled.

Comment 7 Felipe Contreras 2011-12-15 10:38:46 UTC
I've attached the patches for gtk2/gtk3, and I confirm the issue goes away.

Again, this is the safest route for Fedora 16, as we don't know if other clients will be affected (other than vte/vte3).

Comment 8 Felipe Contreras 2012-02-02 18:49:00 UTC
(In reply to comment #7)
> Again, this is the safest route for Fedora 16, as we don't know if other
> clients will be affected (other than vte/vte3).

Looks like nobody cares if the risk of regressions is being increased.


Note You need to log in before you can comment on or make changes to this bug.