Update:  After a while the navigation key shortcuts stop working in Wayland as well.

Hm, it works for me. Can you reproduce with some specific set of web sites, or does it seem random?

On my system, this problem isn't dependent on any specific website and the problem is consistent throughout the entire session logging in via Gnome 3 using Xorg.  In other words, the alt left/right arrow shortcuts never work when logged in through Xorg regardless of the website.  However, using Wayland, the alt left/right arrow sometimes work initially and then stop, so at this point it appears to be random in Wayland sessions.

I am using a Lenovo T450S.

OK, since I can't reproduce, I think we need to add some print statements to the code to have any clue what's going on here. Are you willing to build Epiphany from source so we can do that on your machine (since I can't reproduce)? It won't be quick or easy, but I don't see another way to debug this. You'll want to follow the instructions on https://wiki.gnome.org/Newcomers/BuildGnome replacing "gnome-weather" with "epiphany" in all cases.

First, build git master and see if the problem has disappeared. Since 3.22 all the code that handles keyboard shortcuts has been rewritten, so good chance the bug could have been fixed in that transition.

Now, if the bug still exists, please add a g_warning() statement at the top of window_cmd_navigation() in src/window-commands.c. When you're in the broken state, does the function get called at all when you press the keyboard shortcuts?

If not, let me know and I'll try to come up with a gdbus command that you can use to trigger the action manually, to see if that works.

(In reply to Michael Catanzaro from comment #4)
> First, build git master and see if the problem has disappeared.

Which reminds me that jhbuild is probably set up to build gnome-3-22 at the moment. You'll need to add this line to ~/.config/jhbuildrc:

moduleset = 'gnome-apps-3.24'

I am willing to attempt this but it might take me a day to get time.

Thanks.

I can consistently reproduce this _in Wayland_, though the shortcuts
are working fine here under X11. JFTR, my versions here are:

  GNOME 3.22.1
  Epiphany 3.22.1
  WebKitGTK+ 2.14.1

Just in case it might have something to do: I have the CapsLock key
enabled as an additional Ctrl key (can be done from GNOME Tweak Tool:
Typing → Caps Lock Key Behaviour → Caps Lock is also Ctrl).

(In reply to Adrian Perez from comment #7)
> I can consistently reproduce this _in Wayland_, [...]

One more data point: right now Alt-Left and Alt-Right are working. Let's
see for how long. This is the same Wayland session is before where the
shortcuts were not working, the difference is that the following happened
in the meanwhile:

 1. I unplugged the external keyboard (USB) and the Ethernet cable from
    the NIC (both connected through a stattion).
 2. The external display was disconnected (which was on the HDMI port,
    directly on the laptop).
 3. Suspended the laptop.
 4. Went home.
 5. Resumed the laptop.

This is a bit puzzling, but tomorrow I will be going to the office again,
and there I have the USB keyboard and external display, so I can check a
few more combinations of plug/unplug/suspend/resume and watch the system
logs to see if something catches my eye.

Well, funny story: the issue showed randomly for a few days after my
previous comment, but I couldn't figure out the circumstances that cause
the issue to happen. Then at some point the issue vanished, maybe because
of the 3.22.1 or 3.22.2 updates, dunno. During all these days I have been 
alternating between using X11 and Wayland sessions, both with 1) a single
external monitor, 2) laptop screen only, 3) both the external monitor and
the laptop screen... to no avail.

I have no clue what to try next :-\

I just pushed https://git.gnome.org/browse/epiphany/commit/?id=37e657bb8925df5648c57566c1fc1629cdebe5b9 because I broke these shortcuts in https://git.gnome.org/browse/epiphany/commit/?id=75064181739dfba25b5e3fa2f55e15959fe6cea3.

Maaaaaybe it will fix it?

OK I upgraded to F25 and now I can reproduce with Epiphany 3.22.1, WebKitGTK+ 2.14.1, GTK+ 3.22.2.

I can also reproduce with git master versions of everything in F25. Strange.

Created attachment 340568 [details] [review]
window: Fix key event state comparisons

GDK can set random bits in the state to indicate internal stuff. We have
to use GDK_MODIFIER_MASK to mask out its reserved values before trying
to look at the state.

This DOES NOT fix the bug -- the broken code was introduced just last week -- but it's an essential first step.

OK, the problem is that the key event state is GDK_META_MASK | GDK_MOD1_MASK, which is not correct; it should be just GTK_MOD1_MASK. We need to figure out why GTK+ thinks the meta key (which doesn't exist unless you're using a Space Cadet keyboard :) is being pressed along with Alt. At any rate, this problem is way lower level than Epiphany. I'm reassigning to GTK+ even though I don't know that it's actually a GTK+ bug, it could certainly be a problem in some dependency.

I'm also going to push this patch because it's correct, though it doesn't fix this issue.

Actually maaaybe it's intended to send the META for some inexplicable reason...? Then it would indeed be Epiphany's fault for expecting it to not be set. Another problem is that WebKit always handles the event when received, even though it doesn't do anything with it here; that's why we have to filter it in the first place. But again, none of that can explain why the issue is two months old while the key event filtering was introduced just last week.

Comment on attachment 340568 [details] [review]
window: Fix key event state comparisons

Attachment 340568 [details] pushed as 7ba5e64 - window: Fix key event state comparisons

Can you try using gtk_accelerator_get_default_mod_mask() instead of GDK_MODIFIER_MASK?

I wish you had commented two minutes sooner. Why is that a thing. :(

OK, if I add at the start of main:

gtk_accelerator_set_default_mod_mask (GDK_CONTROL_MASK | GDK_SHIFT_MASK | GDK_MOD1_MASK);

Then of course the shortcut works again. But surely it's wrong to do that.

Am I supposed to use gtk_accelerator_get_default_mod_mask instead of GDK_MODIFIER_MASK in should_web_view_receive_key_press_event? That makes no difference to this bug but of course I want to get the code right.

Well essentially you are doing the work of a shortcut engine by manually checking keyvals. GtkBindingSet already does that type of stuff for you if you use it.

See gtkbindings.c

#define BINDING_MOD_MASK() (gtk_accelerator_get_default_mod_mask () | GDK_RELEASE_MASK)

and gtk_binding_set_activate().

Also note tracking the keyval as uppercase/lowercase (i haven't checked to see if that is done).

> I wish you had commented two minutes sooner. Why is that a thing. :(

No worries, the only reason is that this is fresh in my mind while working on Builder's new shortcut engine.

I don't see how GtkBindingSet would help with deciding whether or not to propagate a key event to the web view.

I mean that it might be possible to replace should_web_view_receive_key_press_event() with a binding set and call:

  if (gtk_binding_set_activate (cannot_override_binding_set, event->keyval, event->state, toplevel))
    return GDK_EVENT_STOP;

*** Bug 775417 has been marked as a duplicate of this bug. ***

I also am experiencing this bug on Arch Linux, I am using Ephiphany 3.22.3-1 from the official [extra] repository.

At the moment the controls Alt+Left and Alt+Right appear to be completly non-functional and not in a working/broken state as others seem to be reporting.

If there is any information I could gather to help narrow it down let me know what logs to attach, also I can install the git version if it helps.

(In reply to Loren Dias from comment #24)
> At the moment the controls Alt+Left and Alt+Right appear to be completly
> non-functional and not in a working/broken state as others seem to be
> reporting.

So there are two problems here:

 * The key event filtering I added in 3.22.3 is resulting in the Meta modifier being sent with Mod1 (Alt), hence your key press is being sent to the web view, which consumes it for some unknown reason (WebKit bug?). This perfectly explains why Alt+Left and Alt+Right are not working right now, that's no mystery. But I do not expect the meta modifier to be set. That seems crazy and a bug, so I'm not going to change the code to expect it unless someone can explain why it should be expected (maybe I'm wrong!). Hence this bug is assigned to GTK+ and not Epiphany in the meantime.

 * This issue was reported long before 3.22.3, so once that's fixed we go back to the original issue "it doesn't work sometimes" which is probably also a lower-level problem.

I wouldn't be surprised if there are certain interstitial GdkEventKeys that should be delivered in both cases for state management (such as modifier only keys) essentially ignoring the "handled" case.

Turns out this the GDK_META_MASK behavior is expected:

Company:  somebody explained that to me once
Company:  but I forgot
Company:  I just wanted to say that I believe there's a reason for it
Company:  it might be a stupid reason
Company:  or a backwards compatibility reason

So Epiphany's key event filter needs to change to respect that. I'll push fixes for that, but this bug remains open and assigned to GTK+ because the original complaint here predates the key event filter by about a month.

Created attachment 342175 [details] [review]
window: Don't filter Ctrl+Shift+N unnecessarily

I thought we had both Ctrl+I and Ctrl+Shift+N shortcuts for New
Incognito Window, but we don't, we only have Ctrl+I.

Created attachment 342176 [details] [review]
window: fix alt-left/right keyboard shortcuts

The call to gdk_keymap_translate_keyboard_state doesn't seem to really
do much here, except change the way we have to test for Ctrl+Shift+T by
consuming GDK_SHIFT_MASK. In particular, the keyval returned is already
the keyval in the key event, so that's not really doing anything for us.
But this is what the GDK documentation tells us to do, so why not. The
important change here, as shown in the GDK documentation, is to mask out
all the modifiers except Ctrl/Shift/Mod1 so that we ignore virtual
modifiers like Meta that we really don't want to see.

This mostly but not completely fixes the bug where the alt-left/right
shortcuts for back/forward stop working. It fixes the regression where
these shortcuts stopped working after I introduced key event filtering.
It *does not* fix the issue that was originally reported, which is that
the shortcuts mysteriously stop working sometimes; it cannot fix that
original bug, because the key event filtering was not added until a
month after that bug was reported. Hence, I am not closing the issue
here. Something seems to be wrong in either GTK+ or in mutter, as
sometimes GTK+ apps stop receiving any input at all; it might or might
not be related.

Attachment 342175 [details] pushed as 500dbd4 - window: Don't filter Ctrl+Shift+N unnecessarily
Attachment 342176 [details] pushed as 02ff0be - window: fix alt-left/right keyboard shortcuts

I found another bug for the GTK+ issue, bug #770112.

To reduce confusion, since we have two unrelated issues with the same symptom in this bug, let's use this bug for the Epiphany issue that was introduced a month after this bug was originally filed, since that's what the majority of the discussion above is about, and consider the original report a duplicate of bug #770112.