| Summary: | Tracking bug for GTK+ regressions due to GDK_MOD1_MASK changes | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Felipe Contreras <felipe.contreras> |
| Component: | gtk2 | Assignee: | Matthias Clasen <mclasen> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | mclasen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-02 18:49:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 626792, 766607, 767766, 767767 | ||
| Bug Blocks: | |||
|
Description
Felipe Contreras
2011-12-14 20:40:57 UTC
Adding dependencies. Switching component to gtk2 since gtk+ (gtk1) is not affected by this. Whats the point in filing a ton of bugs after the problem has already been dealt with ? (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. (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. (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. 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). (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. |