Closed
Bug 1176929
Opened 9 years ago
Closed 9 years ago
[GTK3.14/3.16] ctrl+k shortcut does not give focus to the search field
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
VERIFIED
FIXED
mozilla44
People
(Reporter: nical, Assigned: acomminos)
References
()
Details
(Keywords: regression)
Attachments
(1 file, 2 obsolete files)
2.88 KB,
patch
|
karlt
:
review+
lizzard
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
This is on the Firefox 38.5 gtk3 build that ships with Fedora 22.
Assignee | ||
Comment 1•9 years ago
|
||
Note that the search bar only fails to steal focus when another single-line text *field* is active (multi-line text areas are unaffected). The CTRL-L shortcut (which gives focus to the address bar) works regardless of input focus. The CTRL-{L,K} shortcuts work fine on Firefox 38 with GTK2.
Assignee: nobody → acomminos
Status: NEW → ASSIGNED
Comment 2•9 years ago
|
||
See Red Hat bug for details (https://bugzilla.redhat.com/show_bug.cgi?id=1224605). It's caused by new Gtk3 keybinding and there's only a workaround for it now.
Assignee | ||
Comment 3•9 years ago
|
||
This could easily be worked around by removing the "delete-from-cursor" callback from our single-line native widget in mozilla::widget::NativeKeyBindings (CTRL-K deletes all characters to the right of the user's current position in a GtkEntry). I suppose this is more of a UX choice then rather than a bug, platform consistency vs. native keybindings. What do you think, Karl?
Flags: needinfo?(karlt)
Comment 4•9 years ago
|
||
(In reply to Andrew Comminos [:acomminos] from comment #3) > This could easily be worked around by removing the "delete-from-cursor" > callback from our single-line native widget in > mozilla::widget::NativeKeyBindings (CTRL-K deletes all characters to the > right of the user's current position in a GtkEntry). How to select the CTRL+K here? I mean if we disable GTK_DELETE_PARAGRAPH_ENDS key binding it will be disabled for all shortcuts, not only for the CTRL+K.
Comment 5•9 years ago
|
||
Ctrt+K not going in the search box when focus is on a text input is not new: this happens with gtk2 builds as well, when using the emacs key bindings for gtk. I've occasionally been annoyed by this behavior, but I, for one, would file a bug if Ctrl+K stopped deleting the end of the line in text input fields, and I can see many advanced users do the same.
Comment 6•9 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #5) > I, for one, would > file a bug if Ctrl+K stopped deleting the end of the line in text input > fields, and I can see many advanced users do the same. I would also consider that a bug. Common editing shortcuts should take priority over indiscoverable application-specific focus change navigation shortcuts. If individual users have a different way to kill to the end of the line or don't use that function, then customization can remove the gtk keybinding. https://bugzilla.redhat.com/show_bug.cgi?id=1224605#c8
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(karlt)
Resolution: --- → WONTFIX
Comment 7•9 years ago
|
||
> I would also consider that a bug.
>
> Common editing shortcuts should take priority over indiscoverable
> application-specific focus change navigation shortcuts.
I whole-heartedly disagree with this. I've been using CTRL + K (and CTRL + L) in Firefox for years. It's basically muscle memory at this point. GTK3 comes along and breaks this long used feature for some obscure "delete to end of input" text?
I use Firefox's search bar hundreds of times a day. I didn't even know about GTKs CTRL + K, but even if I did I would use it a LOT less than I use the search.
Please don't break things that have been working for years just for new GTK3 "features"
Comment 8•9 years ago
|
||
(In reply to Scott Baker from comment #7) > > I would also consider that a bug. > > > > Common editing shortcuts should take priority over indiscoverable > > application-specific focus change navigation shortcuts. > > I whole-heartedly disagree with this. I've been using CTRL + K (and CTRL + > L) in Firefox for years. It's basically muscle memory at this point. GTK3 > comes along and breaks this long used feature for some obscure "delete to > end of input" text? > > I use Firefox's search bar hundreds of times a day. I didn't even know about > GTKs CTRL + K, but even if I did I would use it a LOT less than I use the > search. > > Please don't break things that have been working for years just for new GTK3 > "features" I agree with you. Fortunately there's a simple workaround for this: https://bugzilla.redhat.com/show_bug.cgi?id=1224605#c16
Comment 10•9 years ago
|
||
I'd like to add my voice to Scott's as well. I think Ctrl+K as a way of activating the search bar via the keyboard is a very commonly used shortcut - far more common than using it to delete to the end of the input field, in my estimate. Users switching from GTK2-based Firefox to GTK3-based Firefox will experience this shortcut being broken and be disappointed. I would encourage reconsidering the decision to WONTFIX this.
Comment hidden (obsolete) |
Comment 12•9 years ago
|
||
My key theme is default (not emacs) and this still happens.
Comment 13•9 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #11) > Note that the default GTK3 behavior for CTRL-K is *not* to cut text. It only > does if the key theme is emacs, which is not the default according to > gnome-tweak-tool. And if the key theme is emacs, that CTRL-K does cut text > is very much what the user would like (at least, speaking of myself). That's not correct - see: https://git.gnome.org/browse/gtk+/commit/?id=423868b408e0997af9e9af6a3ae5bb1ff50a0965
Comment 14•9 years ago
|
||
Botond linked me to that, and that boggles my mind because my key theme is emacs and if I switch to the default, CTRL-K stops cutting the end of lines... and now I realize that I'm not using a gtk3 build. facepalm. Anyways, comment 5 and comment 6 still apply.
Comment 15•9 years ago
|
||
(In reply to Karl Tomlinson (ni?:karlt) from comment #6) > Common editing shortcuts should take priority over indiscoverable > application-specific focus change navigation shortcuts. Let's consider which group of people we'd be upsetting in each case: - If we allow Ctrl+K to continue giving focus to the search bar, the group of people we are upsetting are people who are used to Ctrl+K deleting to the end of the line in other GTK3 applications. As that is something newly added in GTK3, I would expect that's a fairly small group. - If we allow Ctrl+K to delete to the end of the line in Firefox, the group of people we are upsetting are people who are used to Ctrl+K giving focus to the search bar in GTK2 Firefox. Given that Firefox is currently shipping in GTK2 mode, that's basically every current Firefox user on Linux. I would therefore argue for the choice that upsets the smaller group of people.
Comment 16•9 years ago
|
||
I think you're minimizing the number of people using Ctrl+k to delete the end of line (A lot of people enabled the emacs key theme in Gtk+2), and inflating the number of people who know that Ctrl+k is a keyboard shortcut to the search box. Plus, Ctrl+k still goes to the search box, if the focus is not on an input element (and that hasn't changed compared to Gtk+2 with the emacs key theme).
Comment 17•9 years ago
|
||
You're right that we should not change the behaviour for people using the emacs key theme. I'm just saying we also shouldn't change the behaviour for people using Firefox with the default key theme. Is it possible to make our behaviour conditional on the Gtk key theme?
Reporter | ||
Comment 18•9 years ago
|
||
I agree with Botond that we should not change Firefox's behaviour in the default configuration as part of moving to GTK3 (or any other non-user-facing backend thingy).
Comment 21•9 years ago
|
||
Karl, do you know if it's possible for us to detect what the Gtk key theme is, and vary our behaviour accordingly? If so, would you be open to only registering the "delete_from_cursor" callback if the key theme is emacs?
Flags: needinfo?(karlt)
Comment 22•9 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #21) > Karl, do you know if it's possible for us to detect what the Gtk key theme > is, and vary our behaviour accordingly? I guess it would be possible to determine theme names, but I'm much less confident that detecting user settings for Ctrl+k or delete_from_cursor are distinguishable from theme settings. > If so, would you be open to only registering the "delete_from_cursor" > callback if the key theme is emacs? I'm not comfortable with that approach because it takes away configurability from the user. It is not possible to select a set of shortcuts that everyone is happy with, so the most important thing is to make things configurable. That feature makes it possible for people to get the Ctrl+k to location bar behaviour here, if they want it. I don't want to take away that configurability feature from people who want Ctrl+k.
Flags: needinfo?(karlt)
Comment 23•9 years ago
|
||
Hmm, you're right that we want to maintain configurability. Ideally we would preserve the default behaviour (so that users upgrading from a GTK2 Firefox build to a GTK3 Firefox build don't experience a change in what the shortcut does), while maintaining users' ability to configure what the shortcut does to be different from the default in either direction. I don't know enough about GTK to say whether this is possible.
Updated•9 years ago
|
Keywords: regression
Comment 26•9 years ago
|
||
Tracked for 42, we cannot release a gtk3 build with such bug. Rational: comment #18
status-firefox42:
--- → affected
status-firefox43:
--- → affected
tracking-firefox42:
--- → +
tracking-firefox43:
--- → +
Comment 27•9 years ago
|
||
Reopening as it is a regression, it is breaking a common work flow of some users (btw, having some numbers between the two behavior would be great). Maybe we should implement the proposal mentioned in comment #22.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 28•9 years ago
|
||
Why is this not a dup or duped by 1135341
Comment 31•9 years ago
|
||
Andrew, are you still going to work on this? Thanks
Flags: needinfo?(acomminos)
Assignee | ||
Comment 32•9 years ago
|
||
I can still work on this if a consensus is made as to if we're going to override GTK's CTRL-K keybinding, or just mark this WONTFIX (since CTRL-J does the same thing). Right now it seems like there isn't any good solution that can satisfy everyone.
Flags: needinfo?(acomminos)
Comment 33•9 years ago
|
||
CTRL-K has the great benefit of working on Windows, Linux and Mac. Since I'm working a lot of cross-platform, I'd hate to have different shortcuts on different platforms. I can totally understand if the shortcut needs to change, but please choose one that is consistent across platforms. On a side note, I have never seen a Linux Firefox installation with Emacs key bindings. I sure don't know any distribution that ships with them as default. (Obviously, this is not a representative sample of any kind.)
Comment 34•9 years ago
|
||
(In reply to Andrew Comminos [:acomminos] from comment #32) > I can still work on this if a consensus is made as to if we're going to > override GTK's CTRL-K keybinding To be honest, I don't really care about GTK's default and I don't think this matters as we care about Firefox ... It gives a bad impression of Firefox on GNU/Linux: the current behavior is hard to understand (sometimes, it works, sometimes, it doesn't), especially when you have been using this shortcut for years. To me, this is a blocker for GTK3.
Comment 35•9 years ago
|
||
(FWIW, I agree with comment 15 / comment 18 / comment 34. I'm particularly bugged by the (new) lack of a consistent keybinding across platforms, & the (new) inconsistent behavior on linux depending on whether a textfield is currently active.) If there's a need for more discussion to reach consensus here, perhaps a dev.platform thread would be in order, to avoid making this bug overly long & circle back over the same points too many times? Alternately/also, if there's something subtle & smart we can do here (as hinted in comment 23), I wonder if it'd be wisest to just take a simple fix here which bluntly restores the traditional/cross-platform Ctrl+K behavior, and then we can take care of a more-configurable option in a followup as-needed?
Updated•9 years ago
|
Flags: needinfo?(acomminos)
Comment 36•9 years ago
|
||
I consider this a regression. I've been using CTRL + K for YEARS in Firefox. I didn't know that we upgrade to GTK3, until CTRL + K stopped working and I found this bug. If we have a feature that's been in place for years and an upgrade (like switching to GTK3) causes problems with a feature, I think that's a pretty obvious regression that needs to be fixed. Compound all that with the "bug" not being consistently broken depending on where the cursor is located is really going to confuse customers. I'd really like to see us correct this.
Assignee | ||
Comment 37•9 years ago
|
||
(In reply to Daniel Holbert [:dholbert] (vacation 8/27-9/13) from comment #35) > Alternately/also, if there's something subtle & smart we can do here (as > hinted in comment 23), I wonder if it'd be wisest to just take a simple fix > here which bluntly restores the traditional/cross-platform Ctrl+K behavior, > and then we can take care of a more-configurable option in a followup > as-needed? I'm not opposed, we could probably do something to explicitly disable GTK grabbing CTRL-K. Karl should probably make the decision on this though.
Flags: needinfo?(acomminos) → needinfo?(karlt)
Comment 38•9 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #34) > GNU/Linux: the current behavior is hard to understand (sometimes, it works, > sometimes, it doesn't), especially when you have been using this shortcut > for years. This is true of all key bindings. The binding is interpreted first in the focused element. If the element recognises the binding then propagation is stopped. The same would be true when focus is in a web page. Ctrl+K has two interpretations of interest here - one is consistent with every other GTK3 app, one is specific to some non-GTK3 apps. I bet the Firefox Ctrl+J binding exists precisely for this reason. The behavior is configurable so that people can have their chosen interpretation and we won't be breaking that. This should not be a blocker for shipping GTK3 builds because this behavior change is caused by a change in GTK3. The change could just as easily have occurred in GTK2. However, there is one quirk that some have observed and it may be possible to exploit this - I don't know. GTK3 has a Ctrl+K binding only in GtkEntry, not GtkTextView. The lack of a Ctrl+K binding for GtkTextView is likely to mean that the Ctrl+K binding of GtkEntry is not often used by the user, and so we can use this hint to ignore in single-line fields also. If these application specific bindings were an important feature, then the app would have provided a way to discover the bindings. I think there are more important issues to work on.
Flags: needinfo?(karlt)
Comment 39•9 years ago
|
||
(In reply to Karl Tomlinson (ni?:karlt) from comment #38) > I bet the Firefox Ctrl+J binding exists precisely for this reason. Archeology is interesting. The first keyboard shortcut for the search box in Phoenix (yeah, back in the day) was Ctrl+; https://github.com/mozilla/gecko-dev/commit/4fa62fa81988c70cfc54c30eb4270b4dd1de8f57 where ; is key on the right of the L key. L for Location. I guess that since not all keyboards have the semi-colon on the right of the L key, it was later changed to Ctrl+k: https://github.com/mozilla/gecko-dev/commit/4f2e849dbf2c73b2c1d2c664bc6844bfce8d8483 It was then changed to Ctrl+j on Linux to have Ctrl+k always have the kill-end-of-line behavior: https://github.com/mozilla/gecko-dev/commit/e0bdf34ab3a7a8242e23b1b921ee9c4c4afbd1ba (bug 226273) Also note that Ctrl+u, Ctrl+a, Ctrl+e, Ctrl+w also all had the emacs behavior back then in text boxes by default. Bug 257405 then changed things so that GTK+ key bindings would be followed, and Ctrl+u, Ctrl+a, Ctrl+e, Ctrl+w, Ctrl+k would have their emacs behavior only if the emacs Gtk+ key bindings are used: https://github.com/mozilla/gecko-dev/commit/6cfd95944250ec54c26397084f7cdb5ec2a1c4dc Following that, bug 258694 make Ctrl+k the shortcut for the search box on Linux, making it even with other platforms, but keeping Ctrl+j working (note that Ctrl+e also worked on Windows to go to the search box): https://github.com/mozilla/gecko-dev/commit/5823068f6f478898c3c27487b270b7e4db972694 Note that with Gtk+3, without the Emacs key bindings, while Ctrl+u and Ctrl+k have the emacs behavior, Ctrl+a, Ctrl+e, and Ctrl+w don't. Ctrl+a and Ctrl+e do have alternatives on most keyboard (home and end), but I don't know that Ctrl+w has one. I'm not sure under what rationale Gtk+3 chose its current half-assed-emacs default bindings.
Comment 40•9 years ago
|
||
I'm also affected by this, but in my case I don't use the Emacs keybindings and haven't set them. % rpm -qa | egrep '^(firefox|gtk3)-' gtk3-immodule-xim-3.16.6-1.fc22.x86_64 firefox-40.0-4.fc22.x86_64 gtk3-3.16.6-1.fc22.x86_64 The Gtk key theme for both Gtk2 and Gtk3 are configured as "Default": % gsettings get org.gnome.desktop.interface gtk-key-theme 'Default' % gconftool-2 --get /desktop/gnome/interface/gtk_key_theme Default The Firefox build I'm using links against gtk3: % LD_LIBRARY_PATH=/usr/lib64/firefox ldd /usr/lib64/firefox/libxul.so | grep gtk libmozgtk.so => /usr/lib64/firefox/libmozgtk.so (0x00007f9fbcd8f000) libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007f9fb3717000) Observed behavior: 1. When focus is not on an input field, Ctrl+K focuses search bar 2. When focus is on an in-page single-line input, Ctrl+K kills to end of line 3. When focus is on an in-page multi-line input, Ctrl+K focuses search bar 4. When focus is in the address bar, Ctrl+K kills to end of line Interestingly, with this setting, Ctrl+A in the address bar selects everything, and Ctrl+E does NOT position the cursor at the end of the line (so in that sense, Emacs keybindings are indeed not enabled). This is all with org.gnome.desktop.interface gtk-key-theme set to "Default". When I change it to "Emacs" with this command and then restart Firefox: % gsettings get org.gnome.desktop.interface gtk-key-theme Now I get the following, more Emacs-keybinding-like behavior: 1. Ctrl+A in the address bar puts the cursor at the beginning 2. Ctrl+E in the address bar puts the cursor at the end 3. Ctrl+W does word-wise deletion to the left 4. Ctrl+K still kills to end-of-line The workaround described in https://bugzilla.redhat.com/show_bug.cgi?id=1224605#c16 doesn't work for me. % rpm -ql gtk3 | grep '\.css$' /usr/share/themes/Default/gtk-3.0/gtk-keys.css /usr/share/themes/Emacs/gtk-3.0/gtk-keys.css % cat /usr/share/themes/Default/gtk-3.0/gtk-keys.css /* * Default keybinding set. Empty because it is implemented inline in the code. */ Ok, so let's check the source: % git clone https://github.com/GNOME/gtk.git % cd gtk % git grep '\<GDK_KEY_k\>' [...] gtk/gtkentry.c: gtk_binding_entry_add_signal (binding_set, GDK_KEY_k, GDK_CONTROL_MASK, [...] % git blame gtk/gtkentry.c [...] 423868b40 (Matthias Clasen 2014-09-26 11:14:28 -0400 1989) gtk_binding_entry_add_signal (binding_set, GDK_KEY_k, GDK_CONTROL_MASK, [...] % git show 423868b40 commit 423868b408e0997af9e9af6a3ae5bb1ff50a0965 Author: Matthias Clasen <mclasen@redhat.com> Date: Fri Sep 26 11:14:28 2014 -0400 entry: Revisit Ctrl-u one more time Add a Ctrl-k binding too, and make them match their traditional commandline meaning or 'erase line to the beginning/end'. diff --git a/gtk/gtkentry.c b/gtk/gtkentry.c index 21403df..a6adf9ff 100644 --- a/gtk/gtkentry.c +++ b/gtk/gtkentry.c @@ -1979,11 +1979,10 @@ gtk_entry_class_init (GtkEntryClass *class) "backspace", 0); gtk_binding_entry_add_signal (binding_set, GDK_KEY_u, GDK_CONTROL_MASK, - "move-cursor", 3, - GTK_TYPE_MOVEMENT_STEP, GTK_MOVEMENT_BUFFER_ENDS, - G_TYPE_INT, -1, - G_TYPE_BOOLEAN, FALSE); - gtk_binding_entry_add_signal (binding_set, GDK_KEY_u, GDK_CONTROL_MASK, + "delete-from-cursor", 2, + G_TYPE_ENUM, GTK_DELETE_PARAGRAPH_ENDS, + G_TYPE_INT, -1); + gtk_binding_entry_add_signal (binding_set, GDK_KEY_k, GDK_CONTROL_MASK, "delete-from-cursor", 2, G_TYPE_ENUM, GTK_DELETE_PARAGRAPH_ENDS, G_TYPE_INT, 1); So this is something that was introduced in Gtk+3 less than a year ago and causes this regression, it has nothing to do with Emacs keybindings being enabled or not.
Comment 41•9 years ago
|
||
Related upstream Gtk+3 bug: https://bugzilla.gnome.org/show_bug.cgi?id=749944
Updated•9 years ago
|
Updated•9 years ago
|
Comment 43•9 years ago
|
||
(In reply to Karl Tomlinson (ni?:karlt) from comment #38) > However, there is one quirk that some have observed and it may be possible > to exploit this - I don't know. GTK3 has a Ctrl+K binding only in GtkEntry, > not GtkTextView. The lack of a Ctrl+K binding for GtkTextView is likely to > mean that the Ctrl+K binding of GtkEntry is not often used by the user, and > so we can use this hint to ignore in single-line fields also. Does this mean you support the fix proposed in comment 3 to ignore the Ctrl+K binding in a GtkEntry? (Sorry if I've misunderstood.)
Comment 45•9 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #43) > Does this mean you support the fix proposed in comment 3 to ignore the > Ctrl+K binding in a GtkEntry? (Sorry if I've misunderstood.) Comment was about removing the "delete-from-cursor" callback, but that handles much more than deleting to the end of line, I assume, and for any accelerator key. In comment 38, I was indicating that it may be possible to detect the lack of a Ctrl+K delete-from-cursor binding for GtkTextView, and use that as a trigger for a heuristic to ignore the Ctrl+K binding of GtkEntry. However, I still don't think this is worth spending time on.
Comment 46•9 years ago
|
||
(In reply to m from comment #40) > The workaround described in > https://bugzilla.redhat.com/show_bug.cgi?id=1224605#c16 doesn't work for me. I tested that ~/.config/gtk-3.0/gtk.css here, and it gave the expected behavior, so perhaps there is another setting interfering on your system.
Comment 47•9 years ago
|
||
> I still don't think this is worth spending time on.
Considering it's really a GTK+3 bug, you are probably right.
Reporter | ||
Comment 48•9 years ago
|
||
(In reply to Yajo from comment #47) > Considering it's really a GTK+3 bug, you are probably right. We spend a lot of time working around platform bugs and this one reflects on Firefox rather than on gtk as far as the user is concerned. I've heard several people complain to me about this already. In the end it's a matter of your browsing habits, so if the two groups of developers (the one that has its usual workflow broken by this change and the one that didn't use the shortcut) can't reach a consensus on an UX decision, let's actually involve UX and let them decide if the behaviour should change or not. Sylvestre, do you know who to ping in the UX team (or what's the process for UX-related decisions)?
Flags: needinfo?(sledru)
Comment 49•9 years ago
|
||
Nical, thanks for this message. I am also worried about this bug. We have 8 duplicate (4 of them being reported by Mozilla staff) and 42 didn't even reach the beta channel. Madhava, Philipp, can you help to make a call here? TLDR: the CTRL+K shortcut behavior changed from Fx 41 (due to the gtk3 migration). From the user perspective, the shortcut looks broken.
Flags: needinfo?(sledru)
Flags: needinfo?(philipp)
Flags: needinfo?(madhava)
Comment 50•9 years ago
|
||
The CTRL+K keybinding has been removed from GTK3 upstream due this bug - http://osdir.com/ml/commits.gnome/2015-09/msg03201.html Although it takes some time the update hit distros.
Comment 51•9 years ago
|
||
Thanks, Martin. This issue is only relevant to GTK+ versions 3.14 and 3.16 then.
Summary: [GTK3] ctrl+k shortcut does not give focus to the search field → [GTK3.14/3.16] ctrl+k shortcut does not give focus to the search field
Comment 52•9 years ago
|
||
Added to the 42 release notes as know issues with "The CTRL shortcut does not give focus to the search field when used from the URL bar on GNU/Linux (1176929)" as wording.
relnote-firefox:
--- → 42+
Comment 53•9 years ago
|
||
Shouldn't that be "(In reply to Sylvestre Ledru [:sylvestre] from comment #52) > Added to the 42 release notes as know issues with "The CTRL shortcut does ^^^^ CTRL-K > not give focus to the search field when used from the URL bar on GNU/Linux > (1176929)" as wording. Maybe also add "in GTK+ 3.14 and 3.16"?
Comment 54•9 years ago
|
||
Indeed, updated, thanks!
Comment 57•9 years ago
|
||
Given the frequency that people are running into this problem and the fact that upstream gtk has changed it's behaviour, it probably makes sense for us to work around this for GTK 3.14 and 3.16. Andrew, can you make a patch?
Flags: needinfo?(madhava)
Assignee | ||
Comment 58•9 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #57) > Given the frequency that people are running into this problem and the fact > that upstream gtk has changed it's behaviour, it probably makes sense for us > to work around this for GTK 3.14 and 3.16. Andrew, can you make a patch? Sure; it may require some finesse as we should still respect the Emacs keybinding set. I'll see if I can get a clean solution together that doesn't affect other text deletion shortcuts.
Assignee | ||
Comment 59•9 years ago
|
||
This is a bit of a workaround for disabling the keybinding on the default GTK key theme for affected releases of GTK3. This should catch most cases where users will be affected, unfortunately there's no way I can see to explitly query for key binding styles. Thanks!
Attachment #8665565 -
Flags: review?(karlt)
Comment 60•9 years ago
|
||
Comment on attachment 8665565 [details] [diff] [review] Disable Ctrl-K keybinding with the default key theme on GTK3. Knowing what versions are targeted makes this easier because we know exactly which bindings exist in the default install and what style properties are used in the implementation. Add a GTK_IS_ENTRY(w) test so that the C-S-Delete textview binding is not disabled. See gtk_bindings_activate_list for how user and theme bindings are handled separately from built-in bindings. If the "gtk-key-bindings" style property exists, it means that there are user or theme bindings for the widget. The built-in bindings are not in any theme, but accessed by the class name. It is not necessary to mimic that, but if "gtk-key-bindings" returns non-null then simply don't disable any bindings. It is then not necessary to check gtk-key-theme-name, because it uses the same gtk-key-bindings mechanism.
Attachment #8665565 -
Flags: review?(karlt) → review-
Comment 62•9 years ago
|
||
Sorry for the delay, but it seems like you have figured this out in the meantime.
Flags: needinfo?(philipp)
Comment hidden (obsolete) |
Assignee | ||
Comment 65•9 years ago
|
||
Thanks for the info; this patch checks "gtk-key-bindings" in GtkEntry's style context (as well as checks that the widget is a GtkEntry) and ignores Ctrl-K unless a custom key binding set is used.
Attachment #8670405 -
Attachment is obsolete: true
Attachment #8670405 -
Flags: review?(karlt)
Attachment #8670411 -
Flags: review?(karlt)
Updated•9 years ago
|
Attachment #8670411 -
Flags: review?(karlt) → review+
Comment 67•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a918ac1fea0f
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
status-firefox44:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Comment 68•9 years ago
|
||
Andrew, could you fill the uplift request to aurora? Thanks
Flags: needinfo?(andrew)
Assignee | ||
Comment 69•9 years ago
|
||
Comment on attachment 8670411 [details] [diff] [review] Disable Ctrl-K in GtkEntry unless custom key bindings are set on GTK3. Approval Request Comment [Feature/regressing bug #]: gtk3 [User impact if declined]: The ctrl-k binding to change focus to the search bar will instead delete characters to the end of the line on affected GTK versions 3.14 and 3.16 (still in widespread use). [Describe test coverage new/current, TreeHerder]: No test coverage for native key bindings AFAIK. [Risks and why]: No known risks. [String/UUID change made/needed]: N/A
Flags: needinfo?(andrew)
Attachment #8670411 -
Flags: approval-mozilla-aurora?
Comment 70•9 years ago
|
||
Comment on attachment 8670411 [details] [diff] [review] Disable Ctrl-K in GtkEntry unless custom key bindings are set on GTK3. Fix for regression, let's uplift this and verify in aurora.
Attachment #8670411 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•9 years ago
|
Flags: qe-verify+
Comment 72•9 years ago
|
||
Removing the "known issue" release note from beta 43 now that this is fixed.
Comment 74•9 years ago
|
||
We only have one Fedora 17 distribution where the issue is not reproducible. Baptiste, Simon could you please confirm that it is fixed now on latest Firefox 43 beta 2 or Developer Edition: https://archive.mozilla.org/pub/firefox/candidates/43.0b2-candidates/build1/ https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-aurora/
Flags: needinfo?(simon.lindholm10)
Flags: needinfo?(baptiste.millemathias)
Comment 75•9 years ago
|
||
I confirm that it is fixed for nightly.
Status: RESOLVED → VERIFIED
status-firefox45:
--- → verified
Comment 77•9 years ago
|
||
Thanks! Marking 43 as verified too and removing qe-verify+ keyword since Beta and Nightly verification should suffice.
You need to log in
before you can comment on or make changes to this bug.
Description
•