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)
-->cmanske Martin--could you try this in a newer build and let us know if it's still broken?
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.
This sucks! Why is the arrow key event not taken by the edit field?
I just gave a try to Mozilla 1.1beta (Build ID 2002072104) Bug does apply there too (not yet fixed). Regards, Martin.
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.
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 on attachment 94085 [details] [diff] [review] patch v1 sr=hewitt
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.
Blake: Did you find out any more about the "target" phase issue yet?
Comment on attachment 94085 [details] [diff] [review] patch v1 r=brade fix this typo: texbox
I talked more to blake and he was ok with this fix. Checked into 1.2 trunk.
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!
*** Bug 56141 has been marked as a duplicate of this bug. ***
fixed in OEM branch
*** Bug 164875 has been marked as a duplicate of this bug. ***
*** Bug 166900 has been marked as a duplicate of this bug. ***
*** Bug 169758 has been marked as a duplicate of this bug. ***
*** Bug 179712 has been marked as a duplicate of this bug. ***
*** Bug 165707 has been marked as a duplicate of this bug. ***
WFM with new trunk/win2k nightly. verified.
*** Bug 165021 has been marked as a duplicate of this bug. ***