when using non-us keyboard layout in linux the keyboard-shortcuts (ctrl-t, ctrl-k) don't work

RESOLVED DUPLICATE of bug 69230

Status

()

defect
RESOLVED DUPLICATE of bug 69230
15 years ago
5 years ago

People

(Reporter: amiran13, Unassigned)

Tracking

({conversion, intl, qawanted})

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040612 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040612 Firefox/0.8

In my Linux box i run the X.org X-Server (xorg-x11), and i have in my
configuretion file two keyboard layouts: English (us) and Hebrew (il), and when
I'm using the hebrew layout I can't use the key-shortcuts (like Ctrl+W to close
tab...).

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Here's the keyboard section in the xorg.config file:

Section "InputDevice"

    Identifier  "Keyboard1"
    Driver      "Keyboard"
    Option "AutoRepeat" "500 30"
    Option "XkbRules"   "xfree86"
    Option "XkbModel"   "pc105"
    Option "XkbLayout" "us,il"
    Option "XkbCompat" "group_led"
    Option "XkbOptions" "grp:switch,grp:alt_shift_toggle,grp_led:scroll"

Comment 1

15 years ago
Is this related with bug 7796?
Reporter

Comment 2

15 years ago
no, i dont think so
my problem is with the keyboard shortcuts in Linux (they work fine when i use
them in windows while using the hebrew keyboard layout)

Comment 3

15 years ago
Sorry, typo...

Is this related to bug 77976?

It seems not, to me.

Does your issue affect the CTRL-K to access the search bar? This is to know
whether I have to file a new bug for this issue...
Assignee: firefox → aaronleventhal
Component: General → Keyboard Navigation
QA Contact: firefox.general → jruderman
Reporter

Comment 4

15 years ago
no, it has nothing to do with that
my problem is with ALL keyboard shortcuts when I'm using the IL keyboard layout,
I guess that the keys dont get mapped right because they are in hebrew =\
confirmed.
Status: UNCONFIRMED → NEW
Component: Keyboard Navigation → DOM: Events
Ever confirmed: true
Product: Firefox → Browser
Version: unspecified → Trunk
Assignee: aaronleventhal → events
QA Contact: jruderman → ian
*** Bug 255607 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
Note that keyboard shortcuts do not work even with the srvrkeys:none xkb option,
which solves this problem for many other applications.
Summary: when using non-us keyboard layout in linux the key-shortcuts doesn't work → when using non-us keyboard layout in linux the keyboard-shortcuts don't work
*** Bug 256733 has been marked as a duplicate of this bug. ***
Summary: when using non-us keyboard layout in linux the keyboard-shortcuts don't work → when using non-us keyboard layout in linux the keyboard-shortcuts (ctrl-t, ctrl-k) don't work
Reporter

Comment 9

15 years ago
the bug still exsists in Firefox 1 PR =\
anybody working on this bug?

Comment 10

15 years ago
The bug also exist in thounderbird 0.8 .

thanks
Daniel
Can anyone check if this happens on the trunk (say seamonkey1.8a5)?
Whiteboard: DUPEME

Comment 12

15 years ago
(In reply to comment #11)
> Can anyone check if this happens on the trunk (say seamonkey1.8a5)?

Just downloaded mozilla-1.8a5 to test it. Yes this bug exists there.
*** Bug 286296 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Depends on: 69230

Comment 14

14 years ago
This bug is perhaps a dup or related to bug 69230.

Comment 15

14 years ago
(In reply to comment #14)
> This bug is perhaps a dup or related to bug 69230.

I second that.

GTK+ 2.x considers access keys according to the physical keys, so Ctrl-C would
work no matter whether XKB is in "us", "il", el" or any other language.

I suggest Firefox/Thunderbird/et al to follow the functionality of GTK+ 2.x, as
described in bug 69230.

Comment 16

14 years ago
*** Bug 316162 has been marked as a duplicate of this bug. ***

Comment 17

14 years ago
Indeed, bug 69230 describes how its done in GTK+ 2.x and refers to the right pieces of code. I'm not sure we could just use the GTK+ implementation, but we sure can use the same ideas.

I hope to research into this some time soon.

Comment 18

14 years ago
*** Bug 319164 has been marked as a duplicate of this bug. ***

Comment 19

14 years ago
This is indeed a dupe of bug 69230, and bug 69230 has some insightful comments by Havoc Pennington (of Gtk+ devel team) so it should be used to track work on this issue.

*** This bug has been marked as a duplicate of 69230 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
No longer depends on: 69230
Resolution: --- → DUPLICATE

Comment 20

14 years ago
After so many votes :(

Comment 21

14 years ago
Votes didn't have any effect on the progress of this bug. Personally, I think voting didn't work out in the Bugzilla universe and can be considered a failed project.

If that's any comfort to you, I'm itching to get my hands on this bug...

Comment 22

14 years ago
If you care about your vote then just vote for the other bug, like I did.

I've seen the vote system on Sun's Java development support and it seems to work beautifully there - they have a "bug parade" which lists the "most wanted" and I suppose such a list can be built for Bugzilla too.

Comment 23

14 years ago
(In reply to comment #22)
Nah, it's no use. There are very few core mozilla developers and they don't really care about votes at all. So don't waste your time with it.

Comment 24

14 years ago
*** Bug 312919 has been marked as a duplicate of this bug. ***

Updated

5 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.