Closed Bug 59840 Opened 24 years ago Closed 23 years ago

Mac: Enter key should bind to default button on dialog

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

PowerPC
Mac System 9.x
defect

Tracking

()

VERIFIED DUPLICATE of bug 63728
mozilla1.1alpha

People

(Reporter: j.paulsson, Assigned: paulkchen)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20001109 BuildID: 2000110908 Enter key (the key on the right side of space on powerbooks and ibook) is not supported. Reproducible: Always Steps to Reproduce: 1. invoke a dialog 2. press enter key Actual Results: nothing Expected Results: same thing as clicking on the standard button (the one with the "ring") if enter key is used in a text field, it will print a square (standard symbol if a key is not supported by the font).
Any chance this is bug 58709?
As far as i can tell, bug 58709 only applies to javascript. They could off course have the same origin, but it doesn't seem to be the same bug.
i cannot repro this --using 2000.11.13.08 trunk bits on Mac OS 9.0. i've tried this w/Prefs, Open Web Loc and Find dialogs. is there a dialog in particular where you see this consistently? reopen if you do...
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
the problem still exists in 2000.11.13.08. well, becouse you tried it on an non-international (presumable) system and i'm using a swedish system, then the bug might be therein.
johan, thx for the additional info --i'll cc teruko, our i18n qa engr, to see if she sees this.
It also fails in NS6. I wasn't able to get it to work in a recent (older) milestone. I just tried pulling a brand-new build (my very first) on another computer this afternoon; it built successfully but the machine is now hosed for unrelated reasons, so I won't be able to test this again until I set up a new build on my laptop (Pismo 500 320MB RAM 9.0.4 English US w/ all recent updates). In the meantime, here is more info, some of which I posted to netscape.public.mozilla.mac yesterday: - the square corresponds to character code 0x03, equal to kEnterCharCode as defined in <Events.h> in the Universal Headers. (found out by pasting the character into a ResEdit STR) - the routine nsTextWidget::DispatchWindowEvent beginning at http://lxr.mozilla.org/mozilla/source/widget/src/mac/nsTextWidget.cpp#209 appears to contain references to an older version of this problem, although it's not exactly clear to me whether it is actually fixed or not. - the ConvertMacToRaptorKeycode routine in nsMacEventHandler contains a line at http://lxr.mozilla.org/mozilla/source/widget/src/mac/nsMacEventHandler.cp p#706 which maps the enter key to NS_VK_RETURN, but contains a "Fix me" comment. Not sure what that's all about. - in doing some research on the subject, I noticed a number of vaguely similar Enter key problems that mostly show as having either been fixed or marked WORKSFORME around March of this year. When I get a build again, I plan to take a quick run at the nsTextWidget routine, but *I am not a very good coder*, so please don't assume I'll be able to fix it sometime before Netscape 7 branches. I'd be happy to submit a patch if I can make one, but somebody OTHER THAN MYSELF should be working on this in an official capacity. I'm doing it mostly as a learning exercise, and because not having a working Enter key annoys the hell ot of me.
reopening based on user's comments. cc'ing ben and pchen to see if they have further insight...
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
FYI, here are three related Bugzilla entriess (these are some of the ones I mentioned earlier: http://bugzilla.mozilla.org/show_bug.cgi?id=8020 http://bugzilla.mozilla.org/show_bug.cgi?id=3974 http://bugzilla.mozilla.org/show_bug.cgi?id=3821 The latter two indicate they were fixed in March 1999 by Pierre Saslawsky <pierre@netscape.com>. Still havn't been able to bring down a build on my Powerbook yet. Working on it.
reassigning don's open keyboard nav bugs to vishy.
Assignee: don → vishy
Anyone had any luck on this bug yet?
nsbeta1, confirming, over to pchen
Status: UNCONFIRMED → NEW
Ever confirmed: true
pchen
Assignee: vishy → pchen
better summary
Summary: enter key is not supported → Enter key should bind to default button on dialog
Just to try to clear up any confusion, on a mac keyboard enter and return are 2 seperate keys. Before anyone closes this out as worksforme, please make sure you test with the right key :)
Blocks: focusnav
*** Bug 92369 has been marked as a duplicate of this bug. ***
*** Bug 91697 has been marked as a duplicate of this bug. ***
Trivial test case that exhibits the bug, type "javascript:window.alert('hello')" in the URL bar, and try to dismiss with the |enter| key (the one by the space bar). This is probably due to the fact that the |enter| key generates character code 3 rather than 13, and we don't have any code on the Mac which deals with that. ^C also generates 3, so we may have to use the keycode in our even processing to disambiguate.
See also bug 63728, Enter should activate the focused button (rather than the default button) on Windows.
is bug 101200 a dup?
no, I don't think that is a duplicate.
Keep in mind the enter key on a PowerBook generates a different keycode from the enter key on the numeric keypad.
Keywords: oeone
moving to mozilla1.1, still can use the good ol' return key ;-)
Target Milestone: --- → mozilla1.1
Was this fixed in bug 63728, or is it still broken?
Summary: Enter key should bind to default button on dialog → Mac: Enter key should bind to default button on dialog
i think this was fixed as part of bug 63728, so will mark as dup of said bug. however, pls do reopen if there's a particular test[s] where this still fails. [i cannot seem to repro this issue on mac os 10.1, at least...] *** This bug has been marked as a duplicate of 63728 ***
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → DUPLICATE
I concur - I couldn't find a dialog where Return works and Enter doesn't. There are many dialogs with default buttons where neither work though!
mass verification of duplicate bugs: to find all bugspam pertaining to this, set your search string to "DuplicateBugsBelongInZahadum". if you think this particular bug is *not* a duplicate, please provide a compelling reason, as well as check a recent *trunk* build (on the appropriate platform[s]), before reopening.
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: