CTRL + W is not working while keyboard layout is on Hebrew

Bug #239222 reported by hidro
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: firefox-3.0

Ubuntu 8.04
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060309 Firefox/3.0

ProblemType: Bug
Architecture: i386
Date: Wed Jun 11 19:00:06 2008
DistroRelease: Ubuntu 8.04
Package: firefox-3.0 3.0~rc1+nobinonly-0ubuntu0.8.04.1
PackageArchitecture: i386
ProcEnviron:
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-18-generic i686

Revision history for this message
hidro (hidroo) wrote :
Revision history for this message
Shriramana Sharma (jamadagni) wrote :

I think the developers will expect more details than this. Are you using GNOME or KDE? And is the Hebrew keyboard layout implemented in GNOME or KDE or using Scim/Skim? On my system I use Indian language keyboard layouts using Skim on KDE but Ctrl+W (and other shortcuts for that matter) work properly.

Revision history for this message
hidro (hidroo) wrote :

GNOME implemented hebrew.
this bug didn't occur in ff3 beta 5

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 239222] Re: CTRL + W is not working while keyboard layout is on Hebrew

On Wed, Jun 11, 2008 at 04:10:46PM -0000, hidro wrote:
>
> ** Attachment added: "Dependencies.txt"
> http://launchpadlibrarian.net/15199984/Dependencies.txt
>
> ** Attachment added: "ExtensionSummary.txt"
> http://launchpadlibrarian.net/15199985/ExtensionSummary.txt

first, please try to disable your extensions in tools -> addons and
see if your issues go away. (well except the hebrew translation
extensions and ubunto firefox modifications obviously).

 status incomplete

 - Alexander

Changed in firefox-3.0:
status: New → Incomplete
Revision history for this message
hidro (hidroo) wrote :

all is disabled and nothing changed

Revision history for this message
In , nathan (nathankras) wrote :

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a1pre) Gecko/2008061702 Minefield/3.1a1pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a1pre) Gecko/2008061702 Minefield/3.1a1pre

All shortcut keys are mapped to their qwerty equivalents, rather than the correct colemak keys. For example, pressing cmd-l to go to the address bar, is the equilivant to cmd-u, and opens up the page source. (In colemak, the key at qwerty position 'u' is an 'l'. Obviously the issue does not occur with keys that are the same in both qwerty and the alternate layout, like q or w or a.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox
2. Make sure that firefox is using an english keyboard layout other than qwerty or dvorak
3. Use a keyboard shortcut that uses a key that is different between the current layout and qwerty. For example, cmd-t (qwerty f) causes this.
Actual Results:
The shortcut activated was incorrect, it executed the qwerty shortcut. In the example, this shortcut was cmd-f, which opened the find dialog.

Expected Results:
The shortcut for colemak should have bene activated. In the example, this should have opened a new tab.

I am using the colemak keyboard layout. It should be fixed to work with any keyboard layout, not just colemak, qwerty, and dvorak.

Revision history for this message
In , Mats Palmgren (matspal) wrote :

Dupe of bug 434737?

Revision history for this message
hidro (hidroo) wrote :

it is still not working

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0

Revision history for this message
In , nathan (nathankras) wrote :

The dvorak layout works now with the hotkeys I checked (on Mac OS X). The issue is with layouts other than qwerty and dvorak on Mac OS X. This bug isn't a dupe of 434737.

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 239222] Re: CTRL + W is not working while keyboard layout is on Hebrew

On Wed, Jun 18, 2008 at 06:22:04AM -0000, hidro wrote:
> it is still not working
>
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015
> Firefox/3.0
>

Does Hebrew has a "W" key at all?

 - Alexander

Revision history for this message
hidro (hidroo) wrote :

yes the keyboard hes a " w / ' " key

Revision history for this message
In , Tgj63rfisp (tgj63rfisp) wrote :

We have the same issue on Windows too.
Using an alternative keyboard layout like dvorak all keyboard shortcuts are missmapped (i.e. they are mapped for qwerty).
So, this issue can be reproduced on Mac and on Windows.

Revision history for this message
In , Daveysnack-moz (daveysnack-moz) wrote :

I can confirm this issue on Windows XP. I am using a Dvorak layout where CTRL keys revert to QWERTY. In Firefox, however, if I select text and enter CTRL-C to copy, Firefox treats it as CTRL-J (what the key would be in Dvorak if I didn't have the CTRL override) and opens the Downloads window. Similarly, if I enter CTRL-V, Firefox treats it as CTRL-K and changes the focus to the search bar.

However, the problem does not occur in form text fields, in the address bar, or in the search bar.

This also wasn't a problem in Firefox 2, nor do I have this problem in other applications.

This is a particularly annoying bug as I often wish to copy text from web pages, and right now I must resort to the context menu rather than a keyboard shortcut.

Revision history for this message
In , Zazcallabah (zazcallabah) wrote :

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

Revision history for this message
In , Neilcczwdr (neilcczwdr) wrote :

well, I was hoping that by now Firefox 3 is ready to use and the most annoying bugs have been resolved...
Now imagine my surprise when I tried Firefox 3.0.1 now
only to discover that Firefox 3 is still NOT ready to use!
WTF???
How is it even possible for such an annoying bug like this one
to be in the version 3.0.1 ???
I too use the dvorak keyboard layout and I can't believe this bug hasn't been fixed yet?

Revision history for this message
In , Raulcmr3qc (raulcmr3qc) wrote :

Yes, I can confirm this too. it's very annoying.
I'm using dvorak.

Revision history for this message
In , Claudels00ht (claudels00ht) wrote :

well first I thought I was doing something wrong but now I see it's just a bug?
well I have to agree with the above poster
it's a particularly annoying bug.
is there any kind of a work-around yet?
every time I want to copy something the download window jumps at me!

Revision history for this message
In , Nancygrimm29 (nancygrimm29) wrote :

I just did a Google search and found a blog post with a link to this page. I'm having the same problem as the other people here. Can anyone tell me how/where can I switch back to Firefox 2?
I use copy&paste shortcuts quite a lot and I need to switch back to Firefox 2 because I can't use them in Firefox 3.
Thanks.

Revision history for this message
In , Russcru445956 (russcru445956) wrote :

Hello, I have the same problem on Windows XP with a dvorak keyboard layout.
keyboard shortcuts are broken.

Revision history for this message
In , Willardzrznrs (willardzrznrs) wrote :

The dvorak layout does NOT work on Windows!!! I mean I can type but ALL the keyboards shortcuts are BROKEN!!!!!!!!!!!

Revision history for this message
In , Ar1alexanders (ar1alexanders) wrote :

Having the same issue here on windows with dvorak keyboard layout.
every time I hit CTRL-C to copy something a download windows opens...
well looks like Firefox isn't ready for production use.
I'm going to switch back to Opera now but when they fix this issue I'm like to test Firefox one more time.

Revision history for this message
In , Mozilla-bugs-dotancohen (mozilla-bugs-dotancohen) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

Spinnoff of Bug #69230.

It appears that a new regression in Firefox 3.x prevents some, but not all, keyboard accelerators from working in specific keyboard layouts.

With a Hebrew keyboard layout, I can confirm that CTRL-Q and CTRL-W do not work, though CTRL-A, Z, X, C, V, P, F, H, B, and L do work as expected. Other users are encouraged to specify their keyboard layout here, and to specify which keyboard accelerators do work and which do not.

Reproducible: Always

Steps to Reproduce:
1. Enable non-US keyboard layout
2. Press accelerator key combination

Actual Results:
Nothing happens

Expected Results:
Accelerator combination should perform it's function

Revision history for this message
In , Ndemou-gmail (ndemou-gmail) wrote :

ALL accelerators mentioned (plus Ctrl-T) work fine with Greek keyb layout on Ubuntu Firefox/3.0.1 -- Mozilla/5.0 (X11; U; Linux i686; el-GR; rv:1.9.0.1) Gecko/2008072820

Revision history for this message
In , Eyalroz (eyalroz) wrote :

Ctrl+W works for me with FF 3.0.1 and Hebrew layout on Win XP. Don't remember Ctrl+Q should be doing...

Revision history for this message
In , Haggai Eran (haggai-eran) wrote :

I'm using Firefox 3.0.1 on Ubuntu linux, and I can confirm Dotan's report that Ctrl-W and Ctrl-Q doesn't work when the current keyboard layout is Hebrew.

Regards,
Haggai

Revision history for this message
In , Mozilla-bugs-dotancohen (mozilla-bugs-dotancohen) wrote :

I am also using Ubuntu Linux with Firefox 3, so this may be a Linux-specific or Ubuntu specific issue.

Revision history for this message
In , Smontagu (smontagu) wrote :

I can only reproduce this on Linux (also Ubuntu). Note that Q and W are keys that are not mapped to alphabetical characters in the Hebrew layout.

Revision history for this message
In , Yehudab (yehudab) wrote :

Reproduced using CentOS 5.2, and Hebrew layout.
Everything works except Ctrl-W and Ctrl-Q.

Revision history for this message
In , Tomer Cohen (tomer-gmx) wrote :

(In reply to comment #5)
> I can only reproduce this on Linux (also Ubuntu). Note that Q and W are keys
> that are not mapped to alphabetical characters in the Hebrew layout.

smontagu: Do you have any idea if and how we can fix it?

Revision history for this message
In , Tomer Cohen (tomer-gmx) wrote :

Adding the 'intl' keyword. Someone should do a batch run to replace every bug with the 'i18n' keyword with 'intl' since we don't have that keyword any more...

Revision history for this message
In , Smontagu (smontagu) wrote :

Created an attachment (id=336634)
Possible patch

A bit hacky, but it works. It's unfortunate that mochitests for keyhandling don't cover GTK

Revision history for this message
In , Masayuki (masayuki) wrote :

The patch is pretty hacky.

I think that when '/' or ''' key is pressed, we should go to |if (!isLatin)| block.

It seems that one of unshifted char and shifted char is alphabet but other is not so, then, we should go to the block.

Revision history for this message
In , Smontagu (smontagu) wrote :

Created an attachment (id=336660)
Patch v.2

Do you mean like this? This is what I wanted to do in the first place, but I didn't want to revert the change from is_latin_shortcut_key to (code <= 0xFF) in bug 359638.

I've tested that this doesn't regress bug 427932 or bug 433192. Can you suggest other scenarios I should be testing?

Revision history for this message
In , Masayuki (masayuki) wrote :

No. I think:

+ PRBool needLatinKeyCodes = !isLatin;
+ if (!needLatinKeyCodes) {
+ PRBool isAlpha1 = NS_IS_ALPHA(altCharCodes.mUnshiftedCharCode);
+ PRBool isAlpha2 = NS_IS_ALPHA(altCharCodes.mShiftedCharCode);
+ needLatinKeyCodes = (isAlpha1 && !isAlpha2) || (!isAlpha1 && isAlpha2);
+ }

- if (isLatin) {
+ if (needLatinKeyCodes) {

I believe this is safest way for other key layouts...

Revision history for this message
In , Karlt (karlt) wrote :

(In reply to comment #12)
> + PRBool needLatinKeyCodes = !isLatin;
> + if (!needLatinKeyCodes) {
> + PRBool isAlpha1 = NS_IS_ALPHA(altCharCodes.mUnshiftedCharCode);
> + PRBool isAlpha2 = NS_IS_ALPHA(altCharCodes.mShiftedCharCode);
> + needLatinKeyCodes = (isAlpha1 && !isAlpha2) || (!isAlpha1 && isAlpha2);
> + }
>
> - if (isLatin) {
> + if (needLatinKeyCodes) {

NS_IS_ALPHA uses isalpha, which depends on locale, so may produce some
surprises.

We also need to be careful about changing event.charCode if there is a Latin
character is the current group. If Ctrl-/ is a meaningful shortcut, then I
guess it should be preferred over Ctrl-Q (with Ctrl-Q tried as fallback).

Simon, Dotan, Eyal, Haggai, or Yehuda, or Tomer, tell me if a Hebrew user
would think otherwise?

I can think of two possible alternatives for needLatinKeyCodes:

a) Provide the basic Latin letter or numeral as an alternative when and only
   when that basic letter or numeral is not available on level 0 of the
   current group, or

b) Look for a basic Latin letter or numeral only when the current group does
   not look like a Latin layout. That perhaps can be tested through looking
   for one or more specific Latin letters on level 0 of the current layout. I
   wonder whether any layouts have an "a" but not the rest of the Latin
   alphabet. I wonder whether any Latin layouts do not have "z".

Revision history for this message
In , Masayuki (masayuki) wrote :

(In reply to comment #13)
> NS_IS_ALPHA uses isalpha, which depends on locale, so may produce some
> surprises.

NS_IS_ALPHA also checks whether the char is ASCII. So, if the result is true, should be ASCII alphabets.

> We also need to be careful about changing event.charCode if there is a Latin
> character is the current group. If Ctrl-/ is a meaningful shortcut, then I
> guess it should be preferred over Ctrl-Q (with Ctrl-Q tried as fallback).

We should not modify charCode. I think Ctrl+'/' should win. Because if Ctrl+'Q' wins, Ctrl+'/' cannot be accessible. Of course, all UI developers should not use non-alphabets and non-numeric keys for shortcut.

I think that win32 build behaves so, perhaps.
We should use same processing on all platforms if we can.

Revision history for this message
In , Karlt (karlt) wrote :

(In reply to comment #14)
> NS_IS_ALPHA also checks whether the char is ASCII.
> So, if the result is true, should be ASCII alphabets.

It checks whether the char is <= 0x7f. Locale also includes the charmap. If every charmap has the same (ASCII) meaning for the first 0x7f characters, then it should be safe. But I don't know whether that is a safe assumption.
("locale -m" gives a list of available charmaps.)

Revision history for this message
In , Masayuki (masayuki) wrote :

(In reply to comment #15)
> (In reply to comment #14)
> > NS_IS_ALPHA also checks whether the char is ASCII.
> > So, if the result is true, should be ASCII alphabets.
>
> It checks whether the char is <= 0x7f. Locale also includes the charmap. If
> every charmap has the same (ASCII) meaning for the first 0x7f characters, then
> it should be safe. But I don't know whether that is a safe assumption.
> ("locale -m" gives a list of available charmaps.

We should use |('a' <= ch && ch <= 'z') || ('A' <= ch && ch <= 'Z')| ?

Revision history for this message
In , Karlt (karlt) wrote :

(In reply to comment #16)
> We should use |('a' <= ch && ch <= 'z') || ('A' <= ch && ch <= 'Z')| ?

I'd feel safest with that.

Revision history for this message
In , Smontagu (smontagu) wrote :

(In reply to comment #14)
> We should not modify charCode. I think Ctrl+'/' should win. Because if Ctrl+'Q'
> wins, Ctrl+'/' cannot be accessible. Of course, all UI developers should not
> use non-alphabets and non-numeric keys for shortcut.

I was surprised to discover that Ctrl+/ is a shortcut for "Select All" in text fields on GTK. This is rather unpleasant: if a text field is focused, Ctrl+/ is meaningful but Ctrl+' is not; otherwise neither is meaningful. If we say that the non-alpha shortcut wins iff it is meaningful, the same key combination will be "Select All" when focus is in a text field and "Quit" when it is elsewhere, which is a combination that could easily cause data loss if a user enters text, unfocusses the text field without realising and then tries to select all.

On the other hand, if the non-alpha shortcut always wins (the status quo), Ctrl-W and Ctrl-Q are inaccessible in the Hebrew layout.

In the specific case of the Hebrew layout, I'm fairly sure that users expect these keys to produce Ctrl-Q and Ctrl-W, not Ctrl-/ and Ctrl-', and it's also not the end of the world if Ctrl-/ is inaccessible, since it's synonymous with Ctrl-A. We need to check whether other layouts will be affected, though.

Changed in firefox:
status: Unknown → In Progress
Changed in firefox-3.0:
status: Incomplete → Triaged
importance: Undecided → Low
30 comments hidden view all 110 comments
Revision history for this message
Tomer Cohen (tomerc) wrote :

Shachar - As not every Mozilla contributor is monitoring every Linux distribution and other bug tracking system, issues are not assigned to the right person. In this case, we were aware of this issue, but it is possible that Mozilla will not be aware of Linux issues just because some smart people prefer to report in Ubuntu system, in which no one is monitoring and issues are never forwarded to the upstream maintainers. The only way to make things better for Ubuntu users and Linux in general is to always report issues to the right project, which is Mozilla in this case.

As you can see in the previous comments, until I pointed to the right bug in Mozilla, people here gave the reporter some advices how to get rid of the problem, which in this case won't help him, just because the other people are not aware of similar issues in Mozilla. If the reporter was searching in Mozilla, or filing a new bug (which will be than closed as duplicate) - it was much more helpful for Mozilla, and the original maintainers will be more aware of this issue and the affected users of it.

Revision history for this message
John Vivirito (gnomefreak) wrote :

Most Mozilla app bugs are due to upstream bugs. Its always best to look for your problem upstream unless you can pin point the problem to Ubuntu only. However we do not require you to look upstream right away. We can decide if it is Mozilla bug or our bug. We will normally ask reporters to look upstream and if you cant find one to reprot the bug upstream and drop the link to this bug report.

Revision history for this message
In , Tomer Cohen (tomer-gmx) wrote :

Issue still exists with Firefox 3.5rc2, Ubuntu Linux 9.04.

Same issue reported in Ubuntu Launchpad - https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/239222

Shahar Or (mightyiam)
tags: added: hebrew
Revision history for this message
In , Masayuki (masayuki) wrote :

Created an attachment (id=393478)
Patch v1.0

Sorry for the delay.

This patch should fix this bug and can enable the all keyboard tests on 10.4 too.

I'll post this patch to tryserver after the troubles are fixed.

Revision history for this message
In , Masayuki (masayuki) wrote :

This problem should be gone before 1.9.2 final because this is major accessibility issue for some keyboard layout users.

Revision history for this message
In , Masayuki (masayuki) wrote :

Created an attachment (id=393482)
Patch v1.0

sorry, the previous patch has unexpected change.

Revision history for this message
In , Masayuki (masayuki) wrote :

https://<email address hidden>/

Here is a test build, please check whether this bug is fixed on the build, thank you.

Revision history for this message
In , Masayuki (masayuki) wrote :

Created an attachment (id=393986)
Patch v1.1

This removes GetResource completely. The all tests in test_keybodes.xul on my environment. So, this should fix this bug completely.

If somebody can test the reported keyboard layout, please test it with test builds which will be come in tryserver.

Revision history for this message
In , Masayuki (masayuki) wrote :

> The all tests in test_keybodes.xul on my environment.

Ugh, I meant the all tests in test_keycodes.xul are passed on my environment.

Revision history for this message
In , Masayuki (masayuki) wrote :

Created an attachment (id=393992)
Patch v1.1

oops, sorry for the spam.

Revision history for this message
In , Masayuki (masayuki) wrote :

https://<email address hidden>/

The new test builds are coming here soon.

Revision history for this message
In , Masayuki (masayuki) wrote :

(From update of attachment 393992)
Unfortunately, we don't get any feedback for this patch from the reporters.

However, this patch fix the test_keybodes.xul issue on 10.4. So, this should fix the all problems for the legacy keyboard resource support on 10.4.

Revision history for this message
In , Dicktyr (dicktyr) wrote :

> https://<email address hidden>/

Thanks, seems to be working for me (10.4.11 PPC).

Revision history for this message
In , Masayuki (masayuki) wrote :

http://hg.mozilla.org/mozilla-central/rev/40f0b372a4b7

Thank you, Dick. I'll request the approval for 1.9.2.

Revision history for this message
In , Masayuki (masayuki) wrote :

(From update of attachment 393992)
Let's fix this on 1.9.2 branch.

This patch fixes the 10.4 only key hell bug on some keyboard layouts. And by this patch we can test the key handling regressions automatically on 10.4 too.

Revision history for this message
In , Masayuki (masayuki) wrote :
Revision history for this message
In , shimi810 (shimi810) wrote :

Issue still exists with Firefox 3.6, Ubuntu Linux 9.10.

Revision history for this message
shimi810 (shimi810) wrote :

Issue still exists with Firefox 3.6, Ubuntu Linux 9.10.

-Mozilla/5.0 (X11; U; Linux i686 (x86_64); he-IL; rv:1.9.2) Gecko/20100115 Firefox/3.6-

Revision history for this message
Vitamin (drugcpp) wrote :

This bug exists for almost 2 years and it isn't fixed yet? Come on...

Changed in firefox-3.0 (Ubuntu):
status: Triaged → Confirmed
Revision history for this message
In , Tomer Cohen (tomer-gmx) wrote :

Issue is still relevant for 3.6.x and this bug is actually has a workaround. Any chance to land it by 1.9.3?

Revision history for this message
In , Vitamin (drugcpp) wrote :

I'm also affected with this bug, and it's really annoying. Hope this will be fixed soon.

Changed in firefox:
importance: Unknown → Medium
Revision history for this message
evp55555 (evp55555) wrote :

ubuntu 11.04, firefox 5, still the same.

Revision history for this message
Tomer Cohen (tomerc) wrote :

evp55555: If you want to see this issue fixed, you should do it directly on the upstream bug!

https://bugzilla.mozilla.org/show_bug.cgi?id=452393

Revision history for this message
In , Yotam Benshalom (benshalom) wrote :

Four years, the issue is still here and is as disturbing as ever. Is there any progress?

Revision history for this message
In , Tomer-moz-bugs (tomer-moz-bugs) wrote :

Smontagu: The purposed patch you created is from 2008, and AFAIK never got committed into the tree. It might be good idea to invalidate it and re-create it for more recent Firefox version.

Revision history for this message
In , Smontagu (smontagu) wrote :

Masayuki didn't approve my patch (comment 12). I can try to produce a new one based on subsequent comments, but I'm basically too chicken to fix this bug, since my experience with keyboard bugs is that every fix breaks something else.

Revision history for this message
In , Masayuki (masayuki) wrote :

I'm going to work on reimplementing the keycode computation on Linux. If you write the patch for this, I hope you do it quickly.

FYI: the code was moved to nsGtkKeyUtils.cpp.

Revision history for this message
In , Smontagu (smontagu) wrote :

Created attachment 603986
Patch v.3

I think that Masayuki and Karl both agreed on this approach in the comments.

Revision history for this message
In , Masayuki (masayuki) wrote :

Comment on attachment 603986
Patch v.3

I believe that this improves the usability of Hebrew users at least for now, and we should land such patch ASAP because the deadline of next merge is next week.

However, I'm concerned by following situation.

If Hebrew users is using normal Hebrew layout with Dvorak, then, I think that when Ctrl+ד is pressed, the first alternative char codes are (ד, S). And second alternative char codes are (o, O). So, there is 'S' vs 'O'. I feel it's very strange. If this is not OK, it might be better to clear the 'S' from the first alternative char codes and the charCode when shift key is pressed. Anyway, this must be minor.

Revision history for this message
In , Karlt (karlt) wrote :

Comment on attachment 603986
Patch v.3

I may have felt safer if the charCode were not overridden when ascii. Ctrl-A is beginning-of-line in my settings with emacs key theme, but Ctrl-A Shift-Ctrl-E is available if Ctrl-/ is not available. I never liked having Ctrl-Q as a short cut for quit. Keyboard input does have different behaviour depending on what is focused, and I don't think we'll be able to change that.

But this is all a guessing game and my bike-shedding shouldn't get in the way of fixing Ctrl-W. Are you able to add a comment indicating that the new block takes effect in some Hebrew layouts, please?

Revision history for this message
In , Smontagu (smontagu) wrote :
Revision history for this message
In , Masayuki (masayuki) wrote :

(In reply to Karl Tomlinson (:karlt) from comment #37)
> I never liked having
> Ctrl-Q as a short cut for quit. Keyboard input does have different
> behaviour depending on what is focused, and I don't think we'll be able to
> change that.

I think that it's not minor issue if a lot of Linux users want to use emacs like shortcut keys on Fx. At least, I think that it should be able to be disabled by pref like BackSpace key. And/Or it should show confirmation dialog.

Revision history for this message
In , Mak77 (mak77) wrote :
Revision history for this message
In , Ms2ger (ms2ger) wrote :

PRBool?

Revision history for this message
In , Shahar Or (mightyiam) wrote :

Haleluya...

Changed in firefox:
status: In Progress → Fix Released
Revision history for this message
Haggai Eran (haggai-eran) wrote :

Just added this bug to the firefox package, as firefox-3.0 is no longer available, and this bug still occurs in firefox version 11.0~b7+build1-0ubuntu1 on precise.

Revision history for this message
Micah Gersten (micahg) wrote :

This was fixed in Firefox 13 which will come to the stable releases when it is released.

Changed in firefox (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Micah Gersten (micahg) wrote :

Old firefox source package in hardy is won't fix.

Changed in firefox-3.0 (Ubuntu):
status: Confirmed → Won't Fix
no longer affects: firefox-3.0 (Ubuntu)
Changed in firefox (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox-3.0 (Ubuntu):
status: New → Confirmed
affects: firefox-3.6 (Arch Linux) → firefox-3.0 (Ubuntu)
no longer affects: firefox-3.0 (Ubuntu)
Revision history for this message
In , Emin Mastizada (emin25) wrote :

We have same problem with Azerbaijani keyboard layout, hotkey Ctrl+W not works as its Ctrl+Ü in Azerbaijani layout.
Bug: 1116180

Displaying first 40 and last 40 comments. View all 110 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.