User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Zanata version 1.4.5-alpha-1 (20120124-0107), i.e. a new problem in the newly deployed translate.engineering instance: When using the shortcut to clone an entry Alt+G the editor window loses focus, i.e. the cursor is not in the editor window anymore. I have to use the mouse to put the cursor into the editor before being able to edit it. Slowing down the translation process as I now have to regulary reach over to use the mouse. Reproducible: Always Steps to Reproduce: 1. Open any document 2. Use the shortcut key Alt+G to clone an entry 3. Actual Results: Cursor is not in the editor anymore. Need to use the mouse to click back into the message. Expected Results: Cursor should remain in the editor window (as was the case before the latest zanata update) to allow seemless keyboard use while translating
Should have mentioned: Using Firefox 9.0.1, recently upgraded to it, so could potentially be a browser related issue as well.
Sorry, correction: This bug is *not* always reproducible - I just noticed it works now. If and when I get an idea in which cases it does or it doesn't work I'll advise.
This issue is only apparent, when the browser's search bar is open at the bottom of the page (can be opened with Ctrl+F) If the search bar is present, pressing Alt+G for cloning will lose focus as described. If the search bar is not present, pressing Alt+G works as expected.
Still an issue for 1.5 I'm therefore unable to use the browser's search functionality and the clone-shortcut Alt+G at the same time (in the same browser window)
Just tested 1.6.1 -- better, but not quite fixed yet. Steps to Reproduce: 1. Open workspace for any document 2. Open browser's search functionality (e.g. using Ctrl + F) 3. Use the shortcut key Alt+G to clone an entry 4. Try using other shortcuts, e.g. Ctrl + Enter to save Actual Results: Up until step 3 everything works fine, using the shortcut Alt+G to clone does work now even with the browser's search bar open. But the problem now shows in step 4: After using Alt+G the editor lost focus and will not respond to any shortcuts keys in step 4 Expected Results: Editor should keep focus (cursor blinking), all shortcut keys working
Problem fixed in 1.7 along with reimplementation of keyboard shortcut management. See https://bugzilla.redhat.com/show_bug.cgi?id=836051#c2
Verified with Zanata version 1.7-SNAPSHOT (20120711-0026)
This issue is back in Zanata version 2.0.3 (20121129-1831) (FF 17.0.1, CodeMirror deactivated)
I believe ON_DEV is on the way out. We should use ASSIGNED.
Some keyboard shortcut in Zanata does require cursor focus on the text area to function properly, eg. ALT+G or CTRL+ENTER. When using browser search function - eg. CTRL+F, the mouse focus is on search text box which disable some of the Zanata keyboard shortcut. I believe this is the expected behavior on shortcut keys should be act on the focused element. I've tried up to step 4 - after ALT+G, the focus is still with the editor and response to all other shortcut.
This had been fixed for 1.7 though. Is it not possible to fix it again for current/next version? I agree that it is expected behaviour to move the focus to the search bar as soon as you hit CTRL-F. But I don't think it's expected or correct behaviour for the editor to keep loosing the focus *afterwards*: When I leave the search bar open and manually move the focus back to the editor, the editor will keep losing the focus when using some operations like ALT-G and instead applies these shortcuts to the search bar again. In other words, when I try step 4, the editor loses focus and does not respond anymore to any other shortcuts. This forces translators to keep reaching for the mouse. Currently on Firefox 19.0.2
Implemented fix. See https://github.com/zanata/zanata/commit/d0856aa01e0bd0a57175d8c868324244dc8133c6
Confirm issue caused by shortcut key conflict with Firefox "Find Bar" shortcut and stopPropogation or preventDefault in javascript doesn't apply to it. The reason ALT+G was conflicting only to Hedda machine was due to the German locale in firefox, and when "Find Bar" in firefox is open, "Match case" shortcutkey in German was assign to ALT+G. Likewise, issue can be seen in english version of firefox with "find bar" open with ALT+C is used. Problem can be more complicated because there are 4 key shortcuts assigned to the "Find bar" for each locale. Suggest to add another key modifier for "copy from source" shortcut. ALT + SHIFT + G or CTRL + SHIFT + G
Shortcut keys are basically an arms race between the web app and the browser and OS. The web app never wins. We could make the shortcuts safer by adding another modifier, but this makes them harder to type, and they could still conflict with something in the user's system. I think we should try using a configurable prefix for a second shortcut (as well as Alt+G). For instance, add an alias such as Alt+X,G (which means Alt+X, then G (or Alt+G). After the user presses Alt+X, the app listens for the rest of the key sequence. If the user presses Alt+X again, or presses Esc, or waits a few seconds, the key sequence is cancelled. We should make it visually obvious that Zanata is waiting for the rest of the key sequence. Similarly, we would have Alt+X,1 to copy the first TM result, and so on for our other keys. The important thing is that we keep all the existing shortcuts (since they work for most users) and add the new shortcuts which will all use the same (configurable) "attention key". In most cases, we can probably just replace the modifier (Control, Alt, or Control-Shift) with the attention key, leaving the rest of the shortcut unchanged.
Implemented in rhbz786630 branch. See https://github.com/zanata/zanata/commit/a22b604ccb07e7da45b319712791e8e4b33cb0a1 https://github.com/zanata/zanata/commit/3a4a39bb546c1eaa791ee09a427e11213df02d37 https://github.com/zanata/zanata/commit/385f974cb19287f34f6dfc1019ceb39879126c77 https://github.com/zanata/zanata/commit/1834fa6262d120760d16af00b9cfceadaf5cb44a
(In reply to comment #14) > Shortcut keys are basically an arms race between the web app and the browser > and OS. The web app never wins. Not to mention hot key for input methods, which is very likely being used in Zanata.
(In reply to comment #15) > Implemented in rhbz786630 branch. > > See > https://github.com/zanata/zanata/commit/ > a22b604ccb07e7da45b319712791e8e4b33cb0a1 > https://github.com/zanata/zanata/commit/ > 3a4a39bb546c1eaa791ee09a427e11213df02d37 > https://github.com/zanata/zanata/commit/ > 385f974cb19287f34f6dfc1019ceb39879126c77 > https://github.com/zanata/zanata/commit/ > 1834fa6262d120760d16af00b9cfceadaf5cb44a What is the alternative key combo you were proposing?
Its ALT+x, then G. You can see the list on our keyboard shortcut window.
VERIFIED with Zanata version 2.3-SNAPSHOT (20130422-1233) With Firefox 17.0.5, 20.0 Chrome 22.0.1229.94
Closing VERIFIED bugs for Zanata versions <= 3.1.