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)

Unspecified
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla44
Tracking Status
firefox42 - disabled
firefox43 + verified
firefox44 --- fixed
firefox45 --- verified
relnote-firefox --- 42+

People

(Reporter: nical, Assigned: acomminos)

References

()

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

This is on the Firefox 38.5 gtk3 build that ships with Fedora 22.
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
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.
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)
(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.
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.
(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
> 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"
(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
FWIW Ctrl+J opens downloads in Windows.
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.
My key theme is default (not emacs) and this still happens.
(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
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.
(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.
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).
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?
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).
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)
(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)
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.
Keywords: regression
Tracked for 42, we cannot release a gtk3 build with such bug. Rational: comment #18
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 → ---
Why is this not a dup or duped by  1135341
Andrew, are you still going to work on this? Thanks
Flags: needinfo?(acomminos)
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)
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.)
(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.
(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?
Flags: needinfo?(acomminos)
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.
(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)
(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)
(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.
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.
Related upstream Gtk+3 bug:
https://bugzilla.gnome.org/show_bug.cgi?id=749944
(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.)
(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.
(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.
> I still don't think this is worth spending time on.

Considering it's really a GTK+3 bug, you are probably right.
(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)
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)
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.
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
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.
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"?
Indeed, updated, thanks!
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)
(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.
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 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-
Stop tracking for 42 as we moved back to gtk 2
Sorry for the delay, but it seems like you have figured this out in the meantime.
Flags: needinfo?(philipp)
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)
Attachment #8670411 - Flags: review?(karlt) → review+
https://hg.mozilla.org/mozilla-central/rev/a918ac1fea0f
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Andrew, could you fill the uplift request to aurora? Thanks
Flags: needinfo?(andrew)
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 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+
Flags: qe-verify+
Removing the "known issue" release note from beta 43 now that this is fixed.
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)
I confirm that it is fixed for nightly.
Status: RESOLVED → VERIFIED
Works for me too on nightly and beta.
Flags: needinfo?(simon.lindholm10)
Thanks!

Marking 43 as verified too and removing qe-verify+ keyword since Beta and Nightly verification should suffice.
Flags: qe-verify+
Flags: needinfo?(baptiste.millemathias)
You need to log in before you can comment on or make changes to this bug.