Closed Bug 56141 Opened 25 years ago Closed 23 years ago

Arrow keys toggle between radiobuttons in group when textfield has focus

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 149517

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

(Keywords: access, Whiteboard: [KEYBASE+])

Attachments

(3 files)

minimized testcase
452 bytes, text/xul
Details
patch
1.53 KB, patch
Details | Diff | Splinter Review
patch which works on all themes
1.71 KB, patch
Details | Diff | Splinter Review
Overview Description: The arrow keys toggle focus between the radiobuttons of a radiogroup even when none of the radiobuttons have the focus (a textfield seemingly has it). Steps to Reproduce: 1) Open the preferences dialog. 2) Advanced > Proxies 3) Click Manual proxy configuration 4) Set focus to one of the now-enabled textfields below the radiobutton. 5) Press any of the arrow keys. Note: this may only work with win32/classic due to platform- and theme-specific keybindings. Actual Results: The radiobuttons of the radiogroup are toggled. If you press left or right, the caret also moves in the textfield (as it should). Expected Results: Up and down should do nothing, and left and right should *only* move the caret in the textfield with the focus. The up/down keybindings to toggle between radiobuttons in a group should only work when one of the radiobuttons has the focus. Reproducibility: 100% Occurs in branch and trunk builds (win98se). Additional Information: This also happens in the Mouse Wheel prefs pane, so there is, of course, a larger issue here. I'll get together a minimized testcase so we can find out what's going on (perhaps the radiobutton is never really losing focus although it appears to, etc.). Today is National Focus Awareness Day. Get out there and report some bugs!
Also...I know this might not be the correct component. I'm hoping the testcase will give me more clues about where this belongs.
If I recall, the actual keyboard navigation is managed by the <radiogroup>. In these particular dialogs, that element includes the <textfield> as a child, and it picks up the bubble of the event, and toggles the checked state of the <radio>s. But, that's a guess. Do you want to take this bug while you have a look at what's going on?
Tabbing seems to be wacked in that pane as well... I'd double check the xul first
No time left for non-critical bugs. ->saari/future
Assignee: trudelle → saari
Target Milestone: --- → Future
*** Bug 56286 has been marked as a duplicate of this bug. ***
fwiw, I tried event.preventBubble(); and it didn't help anything...
Attached file minimized testcase —
Actually, putting onkeypress="event.preventBubble();" for the <textfield/> does work, I must have been doing something wrong before. Reassigning to me. Saari/jrgm, is this really the best fix? Or is there any other (broader) fix we could do so that every textfield with a radiogroup parent node doesn't have to do this?
Assignee: saari → blakeross
I suppose the radiogroup should handle this logic and ignore the keypress if it originated in a textfield. But, of course, you really want to let any widget in there, so do you start programming in exceptions for all of them? I guess you need to for a complete solution. (Having widgets not bubble is wrong, and making XUL authors deal with the special case would be a pain).
John: thanks for the direction. I'll try your suggestion out. (agreed that manually preventing the bubbling isn't a good fix) retargeting milestones as if I understand the new mozilla point releases.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9.1
I suggest you take a look at radioBindings.xml, make the appropriate keyboard navigation handlers check if the event.target.localName == "radio"
Attached patch patch — — Splinter Review
jag: that's what i was doing ;-) but thanks! it's actually "radiogroup", also. jrgm: how does this patch look to you? do you foresee any problems with only allowing "radiogroup" (I ask because you mentioned programming exceptions)?
Keywords: approval, patch, review
Hmmm... Wouldn't you be wanting to see if where the keypress originated was a <radio> as opposed to a <textfield>? But I guess that would be something like event.originalTarget.localName (or whatever that's called). If target is only "radiogroup" when the key was pressed on a <radio>, then your solution is fine.
[Mid-air collision, but submitting anyways. It's kinda what Peter said.] I was thinking that you would ignore "if (target == textfield|menulist|etc.)" as opposed to what you did (but that would never be a complete solution, especially given that with XBL, widgets can have arbitrary names). Is event.target.localName == radiogroup the only case that you're interested in? (I don't really know, having not really looked). If it is and this works, then good (although don't confuse me with someone who really knows what they're talking about, like ben or saari :-]).
Yeah, this works. "radiogroup" seems to be the only thing I'm interested in, and works fine. It seems odd, since presumably the event.target.localName of a keypress event for a <radiogroup> would always be "radiogroup" (but it's not). Maybe if saari or ben could explain why this is right I'd feel better about checking this in...
jrgm: Well, ideally, since you're only interested in moving between <radio>, the better check would be for that, instead of stating which xul elements you want to ignore. Further, similar code (event="click", event="keypress" key=" ") within the same <handlers> block compares event.target.localName to "radio", which seems to contradict blake's finding that it's "radiogroup".
Odd... I've adapted blake's patch slightly to |dump(event.target.localName+"\n")| just before the |if(event.target.localName=="radiogroup")| and I see "radio" printed when on a radio button, and "textfield" when in the textfield.
jag: but my patch (with the check for "radiogroup") still works? Very strange if so. [removing ben and saari from cc for now cause I think they've had enough ;) will readd them when it comes time to review]
Here it doesn't, so I'm surprised it does for you. Did you check if you could still use the arrow keys to move from one button to the next when a button has the focus? Replace =="radiogroup" with =="radio" in blake's patch and things work as expected (i.e. you can move between radio buttons when one of them has focus, and not if say a textfield has focus).
The only time it didn't work was about 20 minutes ago when the arrow keys didn't work at all (neither when the radiobutton nor the textfield had the focus). That seemed to be some race condition, though, because it worked again once I restarted. Yes, I tested if the arrow keys still cycled between the radiobuttons if a radiobutton had the focus; the mousewheel panel was also fixed. Anyways, too tired to think right now. Will get back into this tomorrow..
For my own sanity, I just tried running one more time to ensure that it all worked as you said it did with "radio" -- and it did (with "radiogroup"). So I don't understand this. *Note that I'm in a somewhat old branch build*, although I don't see why that should make much of a difference, but see bug 56391 for why I can't test this in a new trunk build at the moment... And so John doesn't kill me, really going to sleep now...! ;-)
Dude, I didn't think you went to sleep :-]
I've been known to sleep once or twice! This patch still works for me today, this time in a brand new trunk build, in win32 classic. I deleted my entire tree, repulled, applied this patch, and built. It works. I can't explain it, but it does! Now what?
...and not working if I change it to "radiogroup"
Aha! OK...in Classic, only "radiogroup" works, and in Modern, only "radio" works. (event.target.localName returns "radiogroup" in Classic and "radio" in Modern). Now why the heck would that be? Anyone?
http://lxr.mozilla.org/seamonkey/source/themes/modern/global/radio.css#92 92 radiogroup 93 { 94 -moz-user-focus : ignore; 95 } 96 and probably some other settings for focus in both skins. (Actually, this really is not good that the two skins have different notions of how basic focus should operate on widgets.).
Hmm...so what can we do about this? Classic has special focus handling for radiogroups to comply with Windows behavior, but I don't know if `system compliance is for losers' Modern wants to use the same logic...
Hrm, nice, real nice. cc'ing BenGoodger, hyatt and hewitt. Guys, how do we solve this?
<gets a revelation> What if we just worked around this by looking for "radio" OR "radiogroup"? Has everyone but me already thought of this solution and discounted it for some reason that I'm too dumb to realize?
Attached patch patch which works on all themes — — Splinter Review
Already thought of that :-) Of course that works, and could be the chosen solution, but it's a question of design. Why do we have two different situations? Is this something we can (should?) "fix" at a lower level, or something we must take into account a bit higher up?
Sure seems like we should do the same thing in xulBindings.xml and not have different situations in the two skins.
OS: Windows 98 → All
Hardware: PC → All
*** Bug 56820 has been marked as a duplicate of this bug. ***
*** Bug 58084 has been marked as a duplicate of this bug. ***
*** Bug 54849 has been marked as a duplicate of this bug. ***
*** Bug 59729 has been marked as a duplicate of this bug. ***
need to decide what to do here.
Priority: P3 → P4
Target Milestone: mozilla0.9.1 → mozilla1.0
I think arrow keys should move you around in radiogroups in all skins (even Mac classic). No reason why it shouldn't, is there?
Yes, arrow keys should move you around radiogroups no matter what the skin -- the idea that skins can affect user focus behavior and tabbing behavior seems like asking for trouble. However, arrow keys should only move you around radiogroups *if one of the radio buttons has focus*, not if anything inside the radiogroup as a whole has focus (which is what this bug is about). And on Mac OS, radiobuttons (and any widgets except trees and textfields) can't normally get focus anyway. Thousands of Mac users would scream and yell at you if they did -- not because it's a bad idea, but because it's what Windows does, and they don't like Windows. :-/ That is an accessibility problem -- thousands of disabled users don't scream and yell at Apple that they can't give radiobuttons focus, they just quietly use Windows instead. So, um, I'd like this to be an option ... (There is a similar option in the prefs dialog for IE 5.0 for Mac.) In any case, that behavior should be determined by which platform is being used, not by which skin is being used.
What he said. :) I agree.
*** Bug 61134 has been marked as a duplicate of this bug. ***
*** Bug 62205 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
*** Bug 64077 has been marked as a duplicate of this bug. ***
Is there another bug for the problem with Classic and Modern handling focus in radiogroups differently, or is that going to be fixed in this bug?
Another problem I noticed that seems related to this bug: (classic only) in prefs->advanced->proxies, checbkxo and button can seem to both have focus in prefs->advanced->mouse wheel, checkbox and radio can seem to both have focus Should I file a new bug for that?
Bug 64176 (tab order messed up in classic for radiogroups containing text fields) might be related.
Blocks: 18575
*** Bug 64321 has been marked as a duplicate of this bug. ***
*** Bug 64635 has been marked as a duplicate of this bug. ***
Keywords: access
This is still a bug. Can we up the priority of this? It's been reported separately about 20 times since _October_ (it's a mostfreq) and there's been nothing done (though there is a patch attached, though perhaps not an optimal one). Nominating for Mozilla 0.9.
Keywords: mozilla0.9
Priority: P4 → P2
Target Milestone: mozilla1.0 → mozilla0.9
*** Bug 68446 has been marked as a duplicate of this bug. ***
*** Bug 68443 has been marked as a duplicate of this bug. ***
*** Bug 70179 has been marked as a duplicate of this bug. ***
Linux build from CVS works fine. The radiobuttons aren't toggled if I press arrow keys in text fields.
Target Milestone: mozilla0.9 → mozilla0.9.1
Yep, this works for me.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Keywords: mozilla0.9
Priority: P2 → P1
Resolution: --- → WORKSFORME
yep, ditto. however, i encountered bug 79591.
Status: RESOLVED → VERIFIED
This bug can be reproduced with 2002033109/Win2k. Reopening.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 137107 has been marked as a duplicate of this bug. ***
*** Bug 138210 has been marked as a duplicate of this bug. ***
Maybe somebody wants to set a new target milestone?
*** Bug 139171 has been marked as a duplicate of this bug. ***
*** Bug 135073 has been marked as a duplicate of this bug. ***
*** Bug 141141 has been marked as a duplicate of this bug. ***
*** Bug 141228 has been marked as a duplicate of this bug. ***
*** Bug 130783 has been marked as a duplicate of this bug. ***
*** Bug 143965 has been marked as a duplicate of this bug. ***
*** Bug 145527 has been marked as a duplicate of this bug. ***
*** Bug 141228 has been marked as a duplicate of this bug. ***
Current release behaviour: (partially fixed) In Mozilla 1.0RC2 cursor when moved with TAB to a new textfield appears as visible, but IMMEDIATELY becomes hidden and then it continues normally. It should appear as visible and remain so for the period of time assigned for that state, then become hidden, and so on.
*** Bug 148968 has been marked as a duplicate of this bug. ***
*** Bug 149744 has been marked as a duplicate of this bug. ***
*** Bug 149831 has been marked as a duplicate of this bug. ***
*** Bug 153311 has been marked as a duplicate of this bug. ***
in Mozilla 1.0 (2002053012) on W98 the right arrow doesn't do the shift of radio button, but simply move the cursor - however the cursor disappears :-) and interestingly the down arrow just makes the cursor disappear but does nothing else (almost as expected - so there is some progress :-). So only the back and up arrow show the wrong behaviour (if we neglect the cursor disparition)... encouraging no?! Another difference, after hitting the back arrow in the text field, the next radio button becomes selected but *doesn't have the focus*. The focus moves to 'inside' the next radio button apparently, but not on any object there : - there is no frame around the text of the next radiobutton, if you try to use the up down arrow then, there is no switch between radiobutton - thus you are not at the radio-button level - if you use TAB key the focus reappears, and goes to the text field inside the selected radio button - thus you must be 'inside' the radio button already Hope it may help! BTW after 25 duplicates it should be 'mostfreq'... and the summary, although describing very exactly the problem, could be changed by adding a '[preference proxy dialog]' at the end? (I mused for a while before finding this one...)
Whiteboard: [KEYBASE+]
Should we change the Target Milestone to some real value, since 0.9.1 was released loong-looong ago?
see also bug 99436, which may be a duplicate (although it starts out complaining about a different facet of navigation in this dialog).
Target Milestone: mozilla0.9.1 → ---
*** Bug 144775 has been marked as a duplicate of this bug. ***
*** Bug 146667 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 160478 has been marked as a duplicate of this bug. ***
*** Bug 161307 has been marked as a duplicate of this bug. ***
This bug just got another dup :-) But hopefully this means it's fixed now! *** This bug has been marked as a duplicate of 149517 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → DUPLICATE
*** Bug 166853 has been marked as a duplicate of this bug. ***
*** Bug 196146 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: