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 167662 - "Launch web browser" keybinding does not work.
"Launch web browser" keybinding does not work.
Status: RESOLVED DUPLICATE of bug 165343
Product: gnome-control-center
Classification: Core
Component: [obsolete] Keybinding
2.9.x
Other All
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
: 313839 344280 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-02-16 23:48 UTC by Marius Gedminas
Modified: 2006-06-08 16:07 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Marius Gedminas 2005-02-16 23:48:46 UTC
Please describe the problem:
I am unable to assign a keyboard shortcut for launching a web browser.

Steps to reproduce:
1. Go to the keybinding dialog
2. Assign a key for launching a web browser (I used <Mod4>z)
3. Press that key


Actual results:
There is a brief but noticeable focus change (the active window momentarily
loses focus and gets it back), but nothing else happens.

Expected results:
A new browser window should be opened.

Does this happen every time?
Yes

Other information:
Preferred applications dialog has "mozilla-firefox %s" as the web browser. 
GNOME applications (e.g. GNOME Terminal) can open URLs.
Comment 1 Marius Gedminas 2005-02-17 00:15:28 UTC
I noticed IGNORED_MODS at the top of gnome-settings-multimedia-keys.c, and a
deep suspicion was born in the dark corners of my mind.

<Mod4>z does not work.  Plain 'z' does work (although is quite useless).  I
assume that Control+z and Alt+z would also work.  It appears that the Penguin
key (aka Win9x, aka Super) is deliberately not accepted by
gnome-settings-multimedia-keys.

Note I can use <Mod4> in, e.g. Metacity's /apps/metacity/global_keybindings, and
it works.

Here's the output of xmodmap on my system:

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40),  Alt_R (0x71),  Alt_L (0x7d),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3        Mode_switch (0x5d)
mod4        ISO_Level3_Shift (0x5e),  Super_L (0x73),  Super_R (0x75),  Super_L
(0x7f),  Hyper_L (0x80)
mod5        Scroll_Lock (0x4e),  Mode_switch (0x5d),  ISO_Level3_Shift (0x7c)

I use an xkb symbols file of my own to map my laptop's <LSGT> key to Super_L,
with some additional hackery so that Shift+<LSGT>+<TLDE> becomes Multi_key.  I
do not think it is relevant, though.
Comment 2 Sebastien Bacher 2005-06-23 17:05:26 UTC
there is a similar issue on the ubuntu bugzilla:
https://bugzilla.ubuntu.com/show_bug.cgi?id=10521
Comment 3 Nigel Tao 2005-08-18 17:02:51 UTC
*** Bug 313839 has been marked as a duplicate of this bug. ***
Comment 4 Nigel Tao 2005-08-18 17:07:45 UTC
I think that the problem is that <Mod4> is not uniformly recognized.  Currently,
we have the less-than-ideal situation where global key-bindings are handled in
(at least) two places - gnome-settings-daemon and metacity.  Metacity can speak
<Mod4>, and handles the "open terminal" binding.  G-s-d cannot speak <Mod4> and
handles the "open web browser" binding.
Comment 5 Nigel Tao 2005-08-18 17:11:31 UTC
Possible gnome-settings-daemon patch attached to (a different, I think) bug 165343.

http://bugzilla.gnome.org/show_bug.cgi?id=165343#c4
Comment 6 Sam Morris 2006-03-30 15:56:45 UTC
Should this be renamed to something like 'gnome-settings-daemon ignores shortcuts involving <Mod4>'?
Comment 7 Sam Morris 2006-03-30 16:19:07 UTC
Oh, I found that gnome-settings-daemon ignores shortcuts involving my Alt Gr (AKA <Mod5>) key as well.
Comment 8 Elijah Newren 2006-06-08 16:04:04 UTC
*** Bug 344280 has been marked as a duplicate of this bug. ***
Comment 9 Elijah Newren 2006-06-08 16:07:03 UTC
I think this is the same as bug 165343, if someone can explain why they are different, please reopen.

*** This bug has been marked as a duplicate of 165343 ***