Closed Bug 327463 Opened 20 years ago Closed 20 years ago

[l10n] Text-Field keyboard actions overridden in 1.0ML by browser back/forward

Categories

(Camino Graveyard :: Translations, defect)

Product:
Camino Graveyard
Component:
Translations
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino1.0

People

(Reporter: sendelweg, Assigned: dobler)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/412.6 (KHTML, like Gecko) Safari/412.2 Build Identifier: Version 2006021400 (1.0Int) In 1.0 int. the apple+cursor keys combination doesn't work in text fields anymore. Since I cannot remeber this happening before, this probably worked in the recent nightlies. alt-ck works as expected though. Reproducible: Always Steps to Reproduce: 1.Type some text into a text field 2.try to move the cursor to the end of the line or beginning 3.use Apple+curso keys (is this the cmd key?) Actual Results: apple+left results in history -1 Expected Results: beginning of line. I think this is new, must have been since 1.0, the nightlies were okay. I say it's critical because I lose data when I accidentaliy use this key combination and can't go forward in history due to dynamic content or whatever
Works great for me. Are you sure you aren't setting any keyboard shortcuts for Camino in your Keyboard & Mouse prefs pane? cl
As I said, it's the intl. Version only of 1.0 I have just downloaded todays nightly and it works again as expected. Somehow a browser window keybinding is assigned to Textfieldviews as well. I doesn't bother me much, I prefer nightlies anyway. However, I'll ask around and see if more people have trouble with this.
Also, does this happen with the 1.0 English version? Or is it peculiar to the Multi-Language version? cl
It only occured in the ML-Version. Since I'm using the nightly now I can't check it anymore. I might load the en Version to see if it's happening again. I'll let you know.
I can't repro this in 1.0ML. Are you sure you had a text field focused when hitting cmd-arrow?
sddfds sfsdfdsfds
Severity: critical → normal
Yes, I had it focused. The alt-cursor keys worked fine though.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060218 Camino/1.0.0+ same problem with this version. cmd+VK_LEFT moves to beginning of line *and* goes back in browser history.
Weird. What OS versions are the two of you using, and which keyboard layouts?
10.4.4 German layout.
(In reply to comment #9) > Weird. What OS versions are the two of you using, and which keyboard layouts? > 10.4.5, US/qwerty. note that this is on camino_1_0_branch; i haven't tested trunk. i'm also indifferent to this bug, since i added in emacs-keybindings to textfields (though i've verified the problem exists w/o them).
I can now replicate the original report (sorry, rahul, no luck with yours) with 1.0ML (de), and it's a "bug" in the German localization. The de localization uses Cmd-Left Arrow and Cmd-Right Arrow for back and forward, which means they work anytime the cursor is anywhere, no matter what. By contrast, the standard en Camino uses Cmd-[ and Cmd-] for these commands (but the Cmd-Arrow versions will work *if a textarea/input is not selected*). Something about being specified as a shortcut in the menu overrides the "if not in textarea" protections we have. I know there's been discussion before that Cmd-[ and Cmd-] are complicated 3-key shortcuts on some non-English keyboards (I think there's an old bug on this), so substituting something else for them is desired. But when doing so, localizers need to make sure they don't choose a keystroke that conflicts with (and overrides) a standard OS text-editing shortcut (Cmd-Arrow, Opt-Arrow, others?). The other localizations should probably be audited and any/all of these bad shortcuts fixed for 1.0.1.
Assignee: mikepinkerton → qa-mozilla
Status: UNCONFIRMED → NEW
Component: HTML Form Controls → Translations
Ever confirmed: true
Flags: camino1.0.1?
QA Contact: qa-mozilla
Summary: Text-Field keyboard actions → Text-Field keyboard actions overridden in 1.0ML by browser back/forward
Target Milestone: --- → Camino1.0
camino1.0.1 or not? - this is all in the hands of the ML team.
(In reply to comment #12) > I know there's been discussion before that Cmd-[ and Cmd-] are complicated > 3-key shortcuts on some non-English keyboards (I think there's an old bug on > this), so substituting something else for them is desired. But when doing so, > localizers need to make sure they don't choose a keystroke that conflicts with > (and overrides) a standard OS text-editing shortcut (Cmd-Arrow, Opt-Arrow, > others?). Cmd-[ and Cmd-] are hard to get on German keyboard layout. And there is no hint on the keyboard how to get [ and ] because these sign aren't even printed on the keyboard. That's the reason why I changed these shortcuts. Why Cmd-Arrow? Because no other useful combo is still free. And I'm absolutely sure that more people need the back/forward feature than the feature "jump to the end of the text in an input field when the cursor is in that input field". Maybe you can tell me a key combo I can use for back/forward that accessible *and* not occupied.
(In reply to comment #14) > (In reply to comment #12) > Cmd-[ and Cmd-] are hard to get on German keyboard layout. And there is no hint > on the keyboard how to get [ and ] because these sign aren't even printed on > the keyboard. > > That's the reason why I changed these shortcuts. Why Cmd-Arrow? Because no > other useful combo is still free. And I'm absolutely sure that more people need > the back/forward feature than the feature "jump to the end of the text in an > input field when the cursor is in that input field". > Agreed. Maybe a note in the German release notes should be added. I say wontFix on that one.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
sorry to come in late to the game here. The German l10n should not be changing functionality from the rest of the l10ns. If cmd-left/right arrow is already in use by the OS for text field navigation, please pick a different key for back/forward.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to comment #16) > sorry to come in late to the game here. > > The German l10n should not be changing functionality from the rest of the > l10ns. If cmd-left/right arrow is already in use by the OS for text field > navigation, please pick a different key for back/forward. German Safari also uses cmd-arrow for back/forward. I don't know any reasonable shortcut that isn't used already. If no-one could lend me a shortcut I think it's best to switch back to (unusable) cmd-[ and cmd-].
How about Cmd-; and Cmd-:? They're not currently in use by Camino, and according to OS X's keyboard layout settings, they're pretty easy to get to.
Karlheinz: Were you able to get in a fix for Camino 1.0.1? If not, we should get this in the forthcoming Camino 1.0.2 (in a week or so).
Flags: camino1.0.2?
Flags: camino1.0.1?
Flags: camino1.0.1-
(In reply to comment #14) > Why Cmd-Arrow? Because no other useful combo is still free. The Command-Arrow keyboard shortcuts are not free either. They are reserved and must not be used for anything except for the purpose mentioned in the Apple Human Interface Guidelines. This bug has caused data loss on multiple occasions. Please always stick to Apple standards and do not override reserved keyboard shortcuts. > German Safari also uses cmd-arrow for back/forward. Safari only uses Command-Arrow if the focus is not on a text field. Safari uses Command-Ö for back and Command-Ä for forward. BTW: Using Ö and Ä is a bad idea because using german language settings in software doesn't mean you also have a german keyboard layout. Apple's developer website describes Control-Arrow as "Move focus to another value or cell within a view, such as a table.". So it probably wouldn't hurt to use Control-Command-left/right Arrow for history-1/history+1. At least I can't find any documentation prohibiting the use of Control-Command-Arrow.
Summary: Text-Field keyboard actions overridden in 1.0ML by browser back/forward → [l10n] Text-Field keyboard actions overridden in 1.0ML by browser back/forward
I've sent the corrected language file (with cmd-[ and cmd-] ) to the l10n list and the new localization will be used for Camino 1.0.2 next week. This bug is fixed now. BTW I still think it's a regression for German users doing it this way.
Why use Cmd-[ or Cmd-]? I thought those were inaccessible (or, difficulty accessed) and unlabled? Wouldn't either of the suggestions in comment 18 or comment 20 be better?
Assignee: qa-mozilla → dobler
Status: REOPENED → NEW
(In reply to comment #22) > Wouldn't either of the suggestions in comment 18 or comment 20 be better? IMHO the solution in comment 18 isn't good to memorise. And if I switch to the solution of comment 20 then maybe next month there will be a user who can't stand it this way because of this and that. And I can't change it every version. German users would be upset, I think. So I'll go back to good old Camino behavior.
Based on Karlheinz comments, I'm marking this as blocking Camino 1.0.2 with the knowledge that it will be in there. Resolving this bug as fixed. Thanks for taking care of this Karlheinz!
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Flags: camino1.0.2? → camino1.0.2+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.