User Agent: Mozilla/5.0 (Linux; U; Android 4.0.3; en-us; Transformer Prime TF201 Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Safari/534.30 Steps to reproduce: Opened Firefox Mobile (both release version and today's Aurora) on Transformer Prime with the keyboard dock attached. Tried pressing Ctrl-L to activate the address bar. Tried Ctrl-T for opening new tab. Actual results: Nothing Expected results: Ctrl-L should have activated the address bar for text entry. Ctrl-T should have opened a new tab Ctrl-R should reload. Etc. The point here being that when you have a hardware keyboard available, it would be great if the familiar keyboard shortcuts worked. For now this is the issue keeping me on stock Android Browser (where these shortcuts work) instead of Firefox. On stock Browser also starting to type while in a new tab activates the address bar and enters the text there.

Nuts. All the devices that I have do not have a cntrl key. The most they have is a shift and alt key. looking at the shortcut lists : Menu + tapping a new link does not open in a new tab : http://support.mozilla.org/en-US/kb/mobile-keyboard-shortcuts

(In reply to Naoki Hirata :nhirata from comment #1) > Nuts. All the devices that I have do not have a cntrl key. The most they > have is a shift and alt key. I guess it's about tablets. Both Asus Transformer ans Samsung Galaxy Tab 10.1 dock keyboards have the Ctrl keys. They really feel like laptops/netbooks, and I agree, the shortcuts there would be nice to have. Why they don't "just work", I don't really know - that might be something minor, but needs some investigation.

Not tablet specific. Trying this out on an Apple bluetooth keyboard too.

Ian - What shortcuts would we want?

Is this still being worked on? I assume we'd want the same shortcuts as desktop, where it makes sense; These shortcuts are detailed here: http://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly

Well, I'm using Firefox Beta from the Google Play store now and keyboard shortcuts on my Droid 4 has gotten worse. No menu+key combination works at all in webpages now. Pressing any menu+key combination just shows the context menu. In the awesome bar, I have to press the keyboard shortcut twice to make it work. For example, I have a URL saved in my clipboard. I tap on the awesome bar and the URL text is highlighted. I press menu+v to paste. The letter "v" replaces the existing URL. I press menu+v again and the currently copied URL gets pasted. Subsequent keyboard shortcuts work until I leave the awesome bar. It seems the initially keyboard shortcut isn't registered upon activating the awesome bar.

Do we really need keyboard shortcuts for a mobile phone? There aren't much phones with keyboards. And all phones are touch-ready.

Firefox also runs on Android tablets, some of which have keyboard docks (such as the ASUS Transformer line) and all Android devices support Bluetooth keyboards. The old version of Firefox also did support this very basic feature and this has been a pretty major regression due to the reimplementation on Android.

I know that you can check for hardware keyboards with getConfiguration(). I'm going to look at the code for the desktop shortcuts this weekend and see if its an easy fix to provide the desktop shortcuts when a physical keyboard is available. I'd like to see this option myself for my Nexus 7 with a bluetooth keyboard and my TF700. It would have been possible to implement in a desktop addon, but the hotkeys module for the mobile SDK is not done according to the documentation.

I think the easiest way to do this is likely by using the same old keyset stuff we use on desktop and xul fennec: i.e. add some keyset stuff to browser.xul: http://mxr.mozilla.org/mozilla-central/source/mobile/xul/chrome/content/browser.xul#129 change the commands to point to functions in our source that they need. We likely don't need command elements and you can instead just set the command attributes directly to the function they should call. i.e. <key id="key_reload" key="r" modifiers="accel" command="BrowserApp.selectedBrowser.reload();"/> Eventually (far in the future) we'll probably have to move away from XUL, but at that time I'd rather just write a library that reuses this stuff than write something new anyway.

Bug 831144 is about adding keyboard shortcuts to editor (i.e. input fields, textareas, contentEditables, designMode editors).

If your phone supports USB OTG then just plugging in a usb keyboard replicates this bug. This should also be marked with parity Chrome as it already has it implemented since release on Android.

(In reply to Henri Bergius from comment #0) > User Agent: Mozilla/5.0 (Linux; U; Android 4.0.3; en-us; Transformer Prime > TF201 Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 > Safari/534.30 > > Steps to reproduce: > > Opened Firefox Mobile (both release version and today's Aurora) on > Transformer Prime with the keyboard dock attached. Tried pressing Ctrl-L to > activate the address bar. > > Tried Ctrl-T for opening new tab. > > > Actual results: > > Nothing > > > Expected results: > > Ctrl-L should have activated the address bar for text entry. > > Ctrl-T should have opened a new tab > > Ctrl-R should reload. > > Etc. The point here being that when you have a hardware keyboard available, > it would be great if the familiar keyboard shortcuts worked. For now this is > the issue keeping me on stock Android Browser (where these shortcuts work) > instead of Firefox. > > On stock Browser also starting to type while in a new tab activates the > address bar and enters the text there. https://support.mozilla.org/en-US/questions/948600

> https://support.mozilla.org/en-US/questions/948600 So sorry that was a mistaken click.

If this is something we want to do for tablets (and only that), we can do it. As per release notes of android 3.0, Applications can implement custom keyboard shortcuts by subclassing Activity, Dialog, or View and implementing onKeyShortcut(). The framework calls this method whenever a key is combined with Ctrl key. When creating an Options Menu, you can register keyboard shortcuts by setting either the android:alphabeticShortcut or android:numericShortcut attribute for each <item> element (or with setShortcut()). Instead of listening on a View, I guess it's better to do it at an activity level. View will have its onKeyShortcut() called only if its focused.

(In reply to Sriram Ramasubramanian [:sriram] from comment #20) > If this is something we want to do for tablets (and only that), we can do it. > As per release notes of android 3.0, > > Applications can implement custom keyboard shortcuts by subclassing > Activity, Dialog, or View and implementing onKeyShortcut(). The framework > calls this method whenever a key is combined with Ctrl key. When creating an > Options Menu, you can register keyboard shortcuts by setting either the > android:alphabeticShortcut or android:numericShortcut attribute for each > <item> element (or with setShortcut()). > > Instead of listening on a View, I guess it's better to do it at an activity > level. View will have its onKeyShortcut() called only if its focused. This sounds like a good start. Let's get a WIP started using some of the shortcuts listed in comment 0. If things work out, we can build the list up.

Why would we choose to do this in Native UI and not in JS? It seems like setting up an architecture that works with normal Firefox localization and that addons to tie into (since we want to avoid XUL) would be useful (and IMO easier to maintain long term).

(In reply to Wesley Johnston (:wesj) from comment #22) > Why would we choose to do this in Native UI and not in JS? It seems like > setting up an architecture that works with normal Firefox localization and > that addons to tie into (since we want to avoid XUL) would be useful (and > IMO easier to maintain long term). I would agree as long as the final end point of the work was also in Gecko. I mean, don't send a message from Java to Gecko ("Shortcut:Send" or something) and then turn around and send a message back to Java ("Shortcut:OpenAwesomebar"). If handling a "CTRL+L" means opening the awesomescreen, then just do it in Java. If we get a shortcut that is unhandled in Java, we could forward it to Gecko and an add-on could listen for the message. Sadly, if the action required of the add-ons shortcut is to do something in Java (maybe to open Settings UI), the add-on might be out of luck.

This is the general approach for implementing keyboard shortcuts. We cannot override onKeyShortcut() as we are capturing keystrokes during onKeyDown() and pass it to Gecko. So, before passing it to Gecko, we can see if that was a shortcut and make use of it. Few things to note: 1. isCtrlPressed() is only 11+. A different approach to make it 8+ would be to use KeyEvent.META_CTRL_MASK and check if ctrl key was pressed. 2. Android recommends using Ctrl+Key for a shortcut and Menu+Key for a menu shortcut. Since we are overriding onKeyDown(), we can even use Ctrl+Shift+Key.

This has more of those shortcuts. We do something wrong with the onKeyDown(). onKeyDown() should be called on the activity only if no other view is using it. "Ctrl- ->" can be used to do both forward and end of text in a text-box. With text-box in focus, if I do "Ctrl- ->", it should go to the end of the text-box. However, layer view doesn't seem to consume it and the activity uses it. Also, the comment in onKeyDown() is misleading. It says this gets the event before passing it to Gecko. How could it happen? If layerview is in focus, wouldnt Gecko consume it first and then leave it to the activity to use it?

Doubts on how layer view consumes event after Activity gets a chance. ^^^

(In reply to Sriram Ramasubramanian [:sriram] from comment #26) > Doubts on how layer view consumes event after Activity gets a chance. ^^^ BrowserApp implements View.OnKeyListener, so the order for a key event is, BrowserApp.onKey() if returns false, LayerView.onKeyDown() if returns false, BrowserApp.onKeyDown() > BrowserApp.onKey() So yes, BrowserApp sees the key event in this case because of the key listener.

Comment on attachment 733024 [details] [diff] [review] WIP Looks OK, but a few caveats: * Until we figure out how to deal with conflicting shortcuts, like the CTRL+ >, let's skip those shortcuts. Only do shortcuts that we want to fire at all times, like CTRL+L (toggle urlbar, like KeyEvent.KEYCODE_BUTTON_Y), CTRL+T, CTRL+R, CTRL+F and CTRL+W. * Can we make unambiguous BACK and FORWARD? BACK is not a priority, since we have a BACK button. * I am OK with using the 11+ API for now, but I would be interested in wat it would take to support gingerbread.

Might I also suggest that copy and paste using the standard CTRL+C and ctrl+V shortcuts be included? These shortcuts are available in many Android applications, not just browsers and would be very useful when using keyboards with Firefox. I would also like to add that keyboard shortcuts (with CTRL modifier) aren't just useful for hardware keyboards, but for soft keyboards which include all modifier keys (e.g., Hacker's Keyboard for Android). Shortcuts of this kind generally work regardless of soft- or hard-keyboard.

(In reply to Achilleas from comment #29) > Might I also suggest that copy and paste using the standard CTRL+C and > ctrl+V shortcuts be included? These shortcuts are available in many Android > applications, not just browsers and would be very useful when using > keyboards with Firefox. I am hoping that clipboard shortcuts just work. If they don't we'll look at them in a followup bug, since they cause a conflict between UI and content, depending on the focus.

I thought those were implemented in bug 831144?

(In reply to Kevin Brosnan [:kbrosnan] from comment #31) > I thought those were implemented in bug 831144? Yes, Ctrl+C and Ctrl+V should work in Nightly and Aurora

Right, sorry, I must have missed it (i.e., was a bit lazy during search). Apologies for the unnecessary posts.

This adds the basic set of commands as a trial. The ambiguous ones are removed. Ctrl+L is tricky for us. We should go into an editable mode, when we focus on the URL bar. This would make us open AwesomeBar. Is that fine? If so, I can add it as a separate patch. We might not need this on GB based phones. They cannot be attached to an external keyboard unlike tablets. Also, the META keys aren't available in anything before Honeycomb.

Comment on attachment 734828 [details] [diff] [review] Patch And yes, let's do CTRL+L to open the awesomescreen. A separate patch is fine.

The duped bug above mentions that CTRL-L does not focus the URL bar.

The CTRL-W/T/R/[/]/. etc. functionality is great and much appreciated. However CTRL-L to focus the URL bar or go to the awesomescreen is still needed for optimal use on a tablet with bluetooth keyboard.

I would love to see the CTRL-L shortcut available too. My setup is an Android tablet with USB keyboard attached.

Hello, I'm using a bluetooth keyboard and noticed that classic keyboard shortcuts are not working with Firefox for Android. This is a major shortcoming, with Chrome you can use almost the same shortcuts available on the desktop version, it would be nice to have a comparable feature on Firefox for Android too. Hardware keyboards are a useful addition for tablets and the latest 'sexy' keyboard folio iterations like the one available for the Google Nexus 9 are practical and desiderable. Please add this enhancement soon! For me these are the very essential ones: * CTRL+T: new tab * CTRL+L: focus address bar * CTRL+W: close tab * CTRL+R: reload tab * CTRL+1....9: switch to tab 1....9 * ALT+left: back to the previous page * ALT+right: forward to the next page * CTRL+F : find Thanks!

I'm going to close this bug because patches for basic keyboard shortcut functionality have already landed. Ctrl+l/k is being added in bug 1199556.

For "basic keyboard shortcut" do you mean that all the following Firefox standard shortcuts have been implemented on the mobile version? * CTRL+T: new tab * CTRL+L: focus address bar * CTRL+W: close tab * CTRL+R: reload tab * CTRL+1....9: switch to tab 1....9 * ALT+left: back to the previous page * ALT+right: forward to the next page * CTRL+F : find

Bug 1199556 will handle focusing the address bar and cycling through tabs. All the other shortcuts listed are supported, except for Alt+left/right and ctrl+1...9.

Hi, just checking if there's been any progress on this one? Hardware keyboards on Android, even on large screen phones, are becoming increasingly useful as Android becomes more capable as a near-full-fledged desktop OS. I love using Firefox but Chrome has the edge of keyboard shortcuts that simply work, making it hard using Firefox when having a keyboard attached. The main one that's still missing in Firefox is Control-L for the location bar (that's quite an important one), and Control-(Page Up / Page Down) or Control-Tab / Control-Shift-tab for cycling tabs, both of which work in Chrome. Would be wonderful to have an update. Ps: In case anyone's wondering about the forward / back shortcuts, they are Control-[ and Control-] respectively.

(In reply to Naimless from comment #48) > Hi, just checking if there's been any progress on this one? > > Hardware keyboards on Android, even on large screen phones, are becoming > increasingly useful as Android becomes more capable as a near-full-fledged > desktop OS. > > I love using Firefox but Chrome has the edge of keyboard shortcuts that > simply work, making it hard using Firefox when having a keyboard attached. > > The main one that's still missing in Firefox is Control-L for the location > bar (that's quite an important one), and Control-(Page Up / Page Down) or > Control-Tab / Control-Shift-tab for cycling tabs, both of which work in > Chrome. > > Would be wonderful to have an update. > > Ps: In case anyone's wondering about the forward / back shortcuts, they are > Control-[ and Control-] respectively. Not sure what you mean by progress. It's been marked RESOLVED-FIXED since September. The last comment above yours points towards the current open bug for address bar focusing and tab switching.

Hi Achilleas, sorry, didn't realise a separate bug had been opened on address bar focusing and tab switching - still a little new to Github / Bugzilla, many thanks for pointing out!