GNOME Bugzilla – Bug 113449
Epiphany should not override pages' shortcuts, access keys
Last modified: 2018-01-30 22:32:46 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?
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?
In mozilla dom keygrabs overide menu mnemonics, but i doubt we can do that with gtk.
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.
No way to do it with gtk right now, true.
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
http://bugzilla.mozilla.org/show_bug.cgi?id=179816 is the relevant mozilla bug
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.
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.
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>
From that bug (thanks) it seem there are already prefs.
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.
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).
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...).
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?
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
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
*** Bug 144476 has been marked as a duplicate of this bug. ***
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?
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.
*** Bug 148396 has been marked as a duplicate of this bug. ***
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
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.
I just repro'd this in 2.27.90.
*** Bug 755624 has been marked as a duplicate of this bug. ***
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. :)
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.
Created attachment 312197 [details] [review] window: properly propagate events to webview The previous patch was mistakenly attached. This is the one that actually works.
Created attachment 312199 [details] [review] window: properly propagate keys to the page This is a much cleaner implementation.
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. ;)
Tested with Japanese and Greek keyboard layouts. Attachment 312199 [details] pushed as ebbc235 - window: properly propagate keys to the page
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.
This was taken into account. It only works with Ctrl, Alt and Shift keys.
(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? :-)
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.
Hello, Is it going to be pushed in epiphany 3.18.x or will we have to ait for epiphany 3.20 ?
(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).
*** Bug 757985 has been marked as a duplicate of this bug. ***
*** Bug 772604 has been marked as a duplicate of this bug. ***
*** Bug 747092 has been marked as a duplicate of this bug. ***