XUL radiogroup processes arrow key events even if focused element isn't a radiobutton

VERIFIED FIXED in mozilla1.2alpha

Status

SeaMonkey
Composer
--
major
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: Morten MacFly, Assigned: Charles Manske)

Tracking

({fixedOEM})

Trunk
mozilla1.2alpha
x86
Windows NT
fixedOEM

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

999 bytes, patch
Kathleen Brade
: review+
Joe Hewitt (gone)
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

There is an annoying bug when trying to enter an alternate text for images in
the Composer. The cursor-movement handling in the text-field where to enter the
text is slighlty strange and should be fixed. Another option button is beeing
selected if I move the cursor one step left (or right). Therefore the text-field
looses focus and is beeing disabled.

Reproducible: Always
Steps to Reproduce:
1. Open any webpage including an image in the composer
2. Right-Click on an image and select "image properties"
3. In the Location-tab select "Alternate text" and type in something
4. Move the cursor one step left (or right).

Actual Results:  "Don't use alternate text" is beeing selected. Therefore the
actual control (text-field) disables (looses focus).

Expected Results:  The cursor should move just one step left (right) in the
text-field in.

(none)

Comment 1

16 years ago
-->cmanske

Martin--could you try this in a newer build and let us know if it's still broken?
Assignee: syd → cmanske
Summary: Control disables (and looses focus) on cursor movement → edit field (alt text) disables (and loses focus) on right arrow key press
(Reporter)

Comment 2

16 years ago
I gave a try to:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611.
(Window title says "Build ID 2002061104".)
Unfortunately the bug does still apply in the Composer.

With regards, Martin Halle.

Ps.: Please note: I can't install another browser on the computer I'm currently
working on. But I guess the admin of this machine will do this as soon as
another "official" release such as 1.1a will be published.
(Assignee)

Comment 3

16 years ago
This sucks! Why is the arrow key event not taken by the edit field?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.2alpha
(Reporter)

Comment 4

16 years ago
I just gave a try to Mozilla 1.1beta (Build ID 2002072104)
Bug does apply there too (not yet fixed).
Regards, Martin.
(Assignee)

Comment 5

16 years ago
Created attachment 94085 [details] [diff] [review]
patch v1

Problem is that all arrow key events are stolen by the radiogroup handlers.
It makes no sense for arrow keys to do the radio-to-radio navigation within a
radiogroup if the focused element is not already a radiobutton.
The currently focused radio button is the "focusedItem" of the radiogroup, so
if that is null, then a radiobutton doesn't have focus, so don't do arrow
navigation.
(Assignee)

Updated

16 years ago
Severity: normal → major
Keywords: nsbeta1, patch, review
Summary: edit field (alt text) disables (and loses focus) on right arrow key press → XUL radiogroup steals all arrow key events even if focused element isn't a radiobutton
Whiteboard: [FIX IN HAND]need r=,sr=
(Assignee)

Comment 6

16 years ago
My previous description isn't entirely correct: the radiogroup doesn't "steal" 
the keypress. Arrow keys in the textbox a processed first in editor navigation 
commands (nsSelectionMoveCommands::DoCommand()) and they don't do preventBubble
(that would actually be very hard to do in that context -- no event info there.)
So the key events are *also* being processed by the radiogroup. I still think
this fix makes sense -- arrow navigation should only occur when focus is on
a radio button.
(Assignee)

Updated

16 years ago
Summary: XUL radiogroup steals all arrow key events even if focused element isn't a radiobutton → XUL radiogroup processes arrow key events even if focused element isn't a radiobutton

Comment 7

16 years ago
Comment on attachment 94085 [details] [diff] [review]
patch v1

sr=hewitt
Attachment #94085 - Flags: superreview+

Comment 8

16 years ago
This is not really the correct fix.  The phase="target" should be preventing
this from happening, I think. I'll have to talk to hyatt.
(Assignee)

Comment 9

16 years ago
Blake: Did you find out any more about the "target" phase issue yet?
(Assignee)

Updated

16 years ago
Whiteboard: [FIX IN HAND]need r=,sr= → [FIX IN HAND]need r=

Comment 10

16 years ago
Comment on attachment 94085 [details] [diff] [review]
patch v1

r=brade
fix this typo: texbox
Attachment #94085 - Flags: review+
(Assignee)

Comment 11

16 years ago
I talked more to blake and he was ok with this fix.
Checked into 1.2 trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Keywords: patch, review
Resolution: --- → FIXED
Whiteboard: [FIX IN HAND]need r=

Comment 12

16 years ago
phase="target" is one of those unfortunately unimplemented features :-(

As an alternative workaround you could have used if (event.target == this) ...

Oh, and this dups the mostfreq bug 56141 - please avoid doing this in future!

Comment 13

16 years ago
*** Bug 56141 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Whiteboard: branchOEM

Updated

16 years ago
Whiteboard: branchOEM → branchOEM+

Comment 14

16 years ago
fixed in OEM branch
Whiteboard: branchOEM+ → fixedOEM

Updated

16 years ago

Comment 15

16 years ago
*** Bug 164875 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Keywords: fixedOEM
Whiteboard: fixedOEM
(Assignee)

Comment 16

15 years ago
*** Bug 166900 has been marked as a duplicate of this bug. ***

Comment 17

15 years ago
*** Bug 169758 has been marked as a duplicate of this bug. ***

Comment 18

15 years ago
*** Bug 179712 has been marked as a duplicate of this bug. ***

Comment 19

15 years ago
*** Bug 165707 has been marked as a duplicate of this bug. ***

Comment 20

15 years ago
WFM with new trunk/win2k nightly. verified.
Status: RESOLVED → VERIFIED

Comment 21

15 years ago
*** Bug 165021 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.