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

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[Morten MacFly]

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

[Kathleen :Brade]

-->cmanske

Martin--could you try this in a newer build and let us know if it's still broken?

Comment 2

[Morten MacFly]

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.

Comment 3

[Charles Manske]

This sucks! Why is the arrow key event not taken by the edit field?

Comment 4

[Morten MacFly]

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

Comment 5

[Charles Manske]

Attachment: 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.

Comment 6

[Charles Manske]

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.

Comment 7

[Joe Hewitt (gone)]

Comment on attachment 94085 [details] [diff] [review]
patch v1

sr=hewitt

Comment 8

[Blake Ross]

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.

Comment 9

[Charles Manske]

Blake: Did you find out any more about the "target" phase issue yet?

Comment 10

[Kathleen :Brade]

Comment on attachment 94085 [details] [diff] [review]
patch v1

r=brade
fix this typo: texbox

Comment 11

[Charles Manske]

I talked more to blake and he was ok with this fix.
Checked into 1.2 trunk.

Comment 12

[[e-mail]]

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

[[e-mail]]

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

Comment 14

[Jerry]

fixed in OEM branch

Comment 15

[R.K.Aa.]

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

Comment 16

[Charles Manske]

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

Comment 17

[timeless]

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

Comment 18

[R.K.Aa.]

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

Comment 19

[Kenneth Herron]

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

Comment 20

[Michael Lefevre]

WFM with new trunk/win2k nightly. verified.

Comment 21

[HARUNAGA Hirotoshi]

*** Bug 165021 has been marked as a duplicate of this bug. ***