Closed Bug 68367 Opened 24 years ago Closed 23 years ago

right arrow at end of a textfield causes focus to be lost

Categories

(Core :: DOM: Editor, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: jruderman, Assigned: mjudge)

References

Details

(Whiteboard: [QAHP])

Attachments

(1 file)

Split from bug 25930, which was starting to get messy.

Steps to reproduce:
1. Open the search sidebar and focus the search textbox.
2. (Optional) type some text in.
3. With the insertion point at the end of the textbox, press the right arrow 
key.

Result: focus is lost.

Note: if you hold shift while pressing the right arrow key, the entire contents 
of the textbox become selected and the textbox still loses focus.
taking this bug for investigation

anthonyd
Assignee: beppe → anthonyd
I see this on Mac as well.
OS: Windows 98 → All
Hardware: PC → All
setting to P2 and putting in moz0.9
Priority: -- → P2
Target Milestone: --- → mozilla0.9.1
I think bug #68368 is a duplicate of this bug as well. This summary may need to 
be fixed as well.
Whiteboard: [QAHP]
*** Bug 68880 has been marked as a duplicate of this bug. ***
*** Bug 64055 has been marked as a duplicate of this bug. ***
*** Bug 73798 has been marked as a duplicate of this bug. ***
*** Bug 74268 has been marked as a duplicate of this bug. ***
Nominating for nsbeta1, since this bug was reported recently but already has 
four dups.
Keywords: nsbeta1
*** Bug 74977 has been marked as a duplicate of this bug. ***
This bug should apply to xul fields and regular html edit fields
Summary: right arrow at end of a xul textfield causes focus to be lost → right arrow at end of a textfield causes focus to be lost
I'm guessing the problem lies in nsTextFrame.cpp, around line 3902.
I don't see this problem for html textfields, only for xul textfields.  (Win98)
*** Bug 76974 has been marked as a duplicate of this bug. ***
the bug that I filed was 30038 which was marked dup of 25930 ( /verified-fixed). 
However, this is stil lreproducible for me (0503) trunk by reading th efollowing 
comments from bug 25930 :

------- Additional Comments From matxdr@yahoo.com 2001-02-10 06:23 -------

I still see this at least for the cache size text box, the homepage URL in
prefs, the wrap plain text messages at xx characters still in prefs, and in
dialogs involing bookmark properties. Using B2001020904 on WinME.

------------------------------------------------------------------------------

So the bug still lives... :)
ok getcontentoffsetsfrompoint passes in an in/out param.  this param is modified 
with invalid data before realizing an error has occured.

simple use of temp variable before indexof is called then saving correct data 
after successful call works.  no change for success case, does not corrupt out 
param on invalid case.
Assignee: anthonyd → mjudge
fixed in a differnt patch i had.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
looks fiexed now...Jesse, does it look fixed to you?

marking VERIFIED-FIXED...Jesse, REOPEN if necessary...
Status: RESOLVED → VERIFIED
Now, if I hit the right-arrow key at the end of an HTML form control on 
http://www.cs.hmc.edu/~jruderma/s/, I'm taken back to the beginning of the form 
field.  Filed bug 81721 for that problem and gave it to mjudge (who fixed this 
bug).
*** Bug 80126 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: