After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 113449 - Epiphany should not override pages' shortcuts, access keys
Epiphany should not override pages' shortcuts, access keys
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Interface
3.18.x (obsolete)
Other Linux
: Low normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 144476 148396 747092 755624 757985 772604 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-05-21 15:17 UTC by gnome-bug-submit
Modified: 2018-01-30 22:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
window: properly propagate events to webview (1.25 KB, patch)
2015-09-26 12:31 UTC, Georges Basile Stavracas Neto
none Details | Review
window: properly propagate events to webview (1.21 KB, patch)
2015-09-26 12:35 UTC, Georges Basile Stavracas Neto
none Details | Review
window: properly propagate keys to the page (1.45 KB, patch)
2015-09-26 12:51 UTC, Georges Basile Stavracas Neto
committed Details | Review

Description gnome-bug-submit 2003-05-21 15:17:57 UTC
On sites using the accesskey feature for forms the accesskey and the
shortcut for accessing a menu option could collide:

On http://webweaver.org/dan/css/cssforms.html alt-t for example should set
the option in the form to True but opens the "Tabs" menu in the browser.

Maybe the accesskey feature should be bind to Ctrl?
Comment 1 Dave Bordoley [Not Reading Bug Mail] 2003-05-21 18:10:02 UTC
can't bind to control either. Since that would collide as well. I
think our best bet is Super (aka windows button), since i think that
guarantess no mnemonic collisions. Bill what do you think?
Comment 2 Dave Bordoley [Not Reading Bug Mail] 2003-05-21 18:16:29 UTC
In mozilla dom keygrabs overide menu mnemonics, but i doubt we can do
that with gtk.
Comment 3 Dave Bordoley [Not Reading Bug Mail] 2003-05-21 18:20:44 UTC
hmm, thinking about it i think we'll need some kind of pref to overide
the modifier in mozilla from alt to something else. Can't think of any
other way to do it.
Comment 4 Marco Pesenti Gritti 2003-05-21 18:29:16 UTC
No way to do it with gtk right now, true.
Comment 5 bill.haneman 2003-05-21 18:32:48 UTC
I would hesitate to use Super/Windows since we really easily run out
of keybindings to use.

I don't fully understand the use case here... but if we can't emulate
Mozilla we'll be in trouble.  Can you explain the situation to me a
bit more with respect to how the forms work?  thanks
Comment 6 Dave Bordoley [Not Reading Bug Mail] 2003-05-21 18:37:59 UTC
http://bugzilla.mozilla.org/show_bug.cgi?id=179816

is the relevant mozilla bug
Comment 7 Dave Bordoley [Not Reading Bug Mail] 2003-05-21 18:43:47 UTC
bill,

afaict page authors can add mnemonics to their pages using css to
activate controls. Currently mozilla uses alt to activate these.
Problem is that gtk menus grab all keybindings first, so if a page
author adds alt+t to a page and it collied with one of our menus, the
menu gets the mnemonic not the page control. I don't think it will be
possible to change gtk behavior (or necessarily desirable even).

In contrast mozilla gives presidence to mnemonics in pages over menu
mnemonics, but this of course breaks activating the menus using the
keyboard which is probably equally as bad.

In practice this prevents epiphany from working with 6 mnemonic
activators (F,E,V,G,T, and H). So its not a huge problem but still
sucks. I think moz will have to fix this anyway since it breaks their
keynav too i assume.
Comment 8 Dave Bordoley [Not Reading Bug Mail] 2003-05-21 18:45:51 UTC
bill, 
also in the above mentioned bug the report suggest using shift for
mnemonic activation as well, so i guess that as an option too. 
Comment 9 spark 2003-05-21 18:50:50 UTC
http://bugzilla.mozilla.org/show_bug.cgi?id=128452 "in-page accesskeys 
conflict w/ UI accelerators when accelkey is ALT" is the relevent bug.

Btw, "accesskey" is an HTML attribute - e.g. <label 
accesskey="F">File</label>
Comment 10 Marco Pesenti Gritti 2003-05-21 18:55:11 UTC
From that bug (thanks) it seem there are already prefs.
Comment 11 Dave Bordoley [Not Reading Bug Mail] 2003-05-21 19:09:43 UTC
marco,

problem is that using ctrl is actually probably worst in our case than
using alt. It doesn't seem like a pref to use shift or super is
available yet afaict from the discussion.
Comment 12 Marco Pesenti Gritti 2003-05-21 19:14:39 UTC
It looks like you can set the key code, so you should be able to use
any key ... (I'm in a hurry so maybe I'm missing something).
Comment 13 spark 2003-05-21 19:20:37 UTC
ui.key.accelKey
ui.key.menuAccessKey
ui.key.generalAccessKey

These prefs control the keys. The Super (Windows) key is not present 
on some keyboards so i think that is unsuitable. I don't think this is 
a big problem because only 6 characters are affected (which depend on
the language i suppose...).
Comment 14 Dave Bordoley [Not Reading Bug Mail] 2003-05-21 19:56:12 UTC
If we don't use super the only other option is shift which is sort of
pointless, since if a text entry has focus shift will be used to
capitalize letters.

I guess the question is, is the collision between the 6 menu item
mnemonics +alt with css pages that use this spec really that big of a
deal. Otherwise the only full proof solution i can think of for most
keyboards is super.

Bill?
Comment 15 Calum Benson 2003-08-07 16:12:15 UTC
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)
Comment 16 Bugzilla Maintainers 2004-04-01 23:44:57 UTC
The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email bugmaster@gnome.org if you have any questions.

URL: 
http://bugzilla.mozilla.org/show_bug.cgi?id=179816
Comment 17 Marco Pesenti Gritti 2004-06-16 17:57:21 UTC
*** Bug 144476 has been marked as a duplicate of this bug. ***
Comment 18 Hakon 2004-06-16 18:04:39 UTC
I have an issue with the Escape key, which is an accel for "Stop (loading)" in
Epiphany.
Stop is of course only usable when a page is loading, which is normally a very
short while which occurs rather seldom.
Therefore, I think it would be sensible if this key was only listened for (by
gtk2) when View->Stop is in fact enabled. That is, when a page is loading, Esc
would mean mean "Stop". Otherwise it should be passed to the javascript event
handler.
But I guess it would still be an issue for gtk2 not Epiphany?
Comment 19 Marco Pesenti Gritti 2004-06-16 18:18:16 UTC
Yeah, that looks like a gtk thing too. I'd create a testcase (without
gtkmozembed that make things more complex) though, before reporting it there.
Comment 20 Christian Persch 2004-07-25 12:19:46 UTC
*** Bug 148396 has been marked as a duplicate of this bug. ***
Comment 21 Christian Persch 2004-10-13 10:52:59 UTC
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Comment 22 Calum Benson 2004-10-21 16:46:36 UTC
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.
Comment 23 Calum Benson 2006-04-26 17:06:33 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 24 Javier Jardón (IRC: jjardon) 2009-08-12 21:50:08 UTC
You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you.

Can you please check again if the issue you reported here still happens in a recent version and update this report by adding a comment and adjusting the 'Version' field?

Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here.

Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Comment 25 Reinout van Schouwen 2009-08-12 22:03:15 UTC
I just repro'd this in 2.27.90.
Comment 26 Michael Catanzaro 2015-09-25 18:48:38 UTC
*** Bug 755624 has been marked as a duplicate of this bug. ***
Comment 27 Michael Catanzaro 2015-09-25 18:50:40 UTC
We often get complaints that we override shortcuts on Google Documents (e.g. Ctrl+B for bold opens the bookmarks dialog) as well. I agree that the web site should take precedence over the browser shortcuts. No clue how to implement this. :)
Comment 28 Georges Basile Stavracas Neto 2015-09-26 12:31:10 UTC
Created attachment 312196 [details] [review]
window: properly propagate events to webview

Sometimes Epiphany wrongly steals the keyboard events
when they were supposed to be handled by the web view.
This is very clear on text editor pages such as Google
Drive's documents, where we can't set e.g. bold text
using Ctrl + B shortcut.

Fix that by propagating events with the form of (Ctrl|Alt) +
letter to the focused widget every time, instead of only
when using the emacs keyset.
Comment 29 Georges Basile Stavracas Neto 2015-09-26 12:35:42 UTC
Created attachment 312197 [details] [review]
window: properly propagate events to webview

The previous patch was mistakenly attached. This is the one that actually works.
Comment 30 Georges Basile Stavracas Neto 2015-09-26 12:51:52 UTC
Created attachment 312199 [details] [review]
window: properly propagate keys to the page

This is a much cleaner implementation.
Comment 31 Michael Catanzaro 2015-09-26 18:22:13 UTC
Review of attachment 312199 [details] [review]:

Hi!

This looks fine; this code is messy, but it solves a messy problem. Please, test an input method like Japanese (Kana Kanji) that use these modifier keys, just to make sure this doesn't break them before committing. I think it will be fine, though. (I am having trouble testing it myself because I have a debug build of WebKit, which is hitting an unrelated assertion.)

Looking forward hopefully to more patches from you. ;)
Comment 32 Georges Basile Stavracas Neto 2015-09-26 21:42:30 UTC
Tested with Japanese and Greek keyboard layouts.

Attachment 312199 [details] pushed as ebbc235 - window: properly propagate keys to the page
Comment 33 Reinout van Schouwen 2015-09-26 21:51:36 UTC
Just curious: from a security/privacy POV, I'd like to know what happens when a website decides to handle for instance F11/Esc, used for (leaving) fullscreen, or the shortcuts for Close or Quit.
Comment 34 Georges Basile Stavracas Neto 2015-09-26 21:52:57 UTC
This was taken into account. It only works with Ctrl, Alt and Shift keys.
Comment 35 Reinout van Schouwen 2015-09-27 09:53:12 UTC
(In reply to Georges Basile Stavracas Neto from comment #34)
> This was taken into account. It only works with Ctrl, Alt and Shift keys.

Ctrl+W? :-)
Comment 36 Claudio Saavedra 2015-09-28 13:05:15 UTC
I think we should special-case Ctrl+W and any other that might be important from a security/privacy point of view. A web application overriding known keybindings (like Ctrl+W) shouldn't take precedence.
Comment 37 Simon Baconnais 2015-10-22 15:13:40 UTC
Hello,

Is it going to be pushed in epiphany 3.18.x or will we have to ait for epiphany 3.20 ?
Comment 38 Michael Catanzaro 2015-10-25 02:01:17 UTC
(In reply to Simon Baconnais from comment #37)
> Hello,
> 
> Is it going to be pushed in epiphany 3.18.x or will we have to ait for
> epiphany 3.20 ?

It will be in 3.18.1 (but I don't know when that will be released, sorry).
Comment 39 Michael Catanzaro 2015-11-13 23:57:16 UTC
*** Bug 757985 has been marked as a duplicate of this bug. ***
Comment 40 Michael Catanzaro 2016-10-08 14:10:03 UTC
*** Bug 772604 has been marked as a duplicate of this bug. ***
Comment 41 Michael Catanzaro 2018-01-30 22:31:42 UTC
*** Bug 747092 has been marked as a duplicate of this bug. ***