Closed Bug 45390 Opened 24 years ago Closed 24 years ago

<TEXTAREA> Back/Forward Arrow keys jump 2 chars instead of 1

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: nbhatla, Assigned: saari)

References

Details

(Keywords: regression, Whiteboard: [nsbeta2-][nsbeta3-])

Attachments

(1 file)

partial fix/patch to nsXBLEventHandler.cpp
537 bytes, patch
Details | Diff | Splinter Review
Windows 98 Build 2000071112 For some strange reason, the keyboard forward/back arrow buttons jump 2 characters forward/back instead of just 1. I first noticed this bug in a <TEXTAREA> at bugzilla. Regular text fields do not experience this bug.
keyword nsbeta2 because if goes on unfixed, it makes simple keyboard text navigation in a form's <textarea> simply unusable.
Keywords: nsbeta2
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
reassigning to beppe
Assignee: clayton → beppe
I don't see a problem in this textarea when using the left and right arrow keys on a Macintosh debug build from today. Is this Windows only? I do see a problem where up and down arrows in single-line inputs or textareas aren't working properly on Macintosh (possibly related?). Akkana--do you want to take this bug or should I?
Keywords: regression
Target Milestone: --- → M17
assigning to brade
Assignee: beppe → brade
I'm seeing this problem in my Win32 build from today. I don't see it in the URL bar, but I see it in the textfields and textareas in a bugzilla bug like this one.
I just tried again and now I see it on Mac (same build, same web site (bugzilla))!
I can't reproduce this on Linux, in text fields or textareas of a bugzilla page (nor in the urlbar). Last Thursday, saari and I were seeing various strange behavior with the order of XUL and XBL key bindings, and this may be another instance of that strange behavior. Can someone find a way to reproduce this consistently?
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: [nsbeta2+] → [nsbeta2+] expected fix by 7/21/2000
Status: NEW → ASSIGNED
fix checked in for 7/20/2000 builds
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Alas, this morning, on Linux, I'm seeing this problem in spades: sporadically, all XBL events (both platform, like ^H, and XP, like arrow keys) will be handled twice in text fields and text areas. Didn't happen yesterday. I can't see how Kathy's change could have caused this. I'm still trying to figure out a way to reproduce this reliably, but it happens frequently when I use the product to type stuff into bugzilla windows, and once it starts happening, it keeps happening everywhere on that page until I reload the page. (So probably, the event system is getting confused somewhere along the line.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Odd. I can't NOT make it happen. Goes on all the time. RH6.2 w/upgrades: kernel 2.2.16, gtk+ 1.2.8, Gnome-core 1.2.1, sawfish 0.30
Removing eta date since the fix I checked in doesn't seem to be sufficient. I have no clue what is going on here. cc hyatt Shorten summary to fit.
Summary: <TEXTAREA> Back/Forward Arrow keyboard buttons jump 2 characters instead of just one → <TEXTAREA> Back/Forward Arrow keys jump 2 chars instead of 1
Whiteboard: [nsbeta2+] expected fix by 7/21/2000 → [nsbeta2+]
Okay, I'm on this. Are we still having the problem on all platforms?
It was sporadic yesterday. Unfortunately yesterday's and this morning's builds weren't good enough to use regularly, to try to find a regularity as to how often it happened. I haven't seen it yet today, but I haven't used the build much yet. R.K.Aa -- are you still seeing this all the time?
I am no longer seeing this bug on a self-build I did on my Mac (OS 9.0) yesterday morning.
still see this in build ID 2000-072113 linux. Arrow back/forth and arrow up/down all do the double stunt.
This was to have been assigned to saari but apparently that didn't happen. He was investigating this yesterday.
Assignee: brade → saari
Status: REOPENED → NEW
I'm still seeing it, but only sporadically. I just saw it on yesterday's build, on a bugzilla page I had just loaded. I think what I did was use the mousewheel to scroll down a little, click in a text field that already had something in it, hit ^H (Unix platform binding for delete-previous-char), and two characters were deleted. I'm fairly sure I had not done anything else involving XBL or XUL key bindings since loading the page, just scrolling and reading.
Please resolve the duplication and assignment between this bug and Bug 42332. They look like dupes, and they are both M17.
*** Bug 42332 has been marked as a duplicate of this bug. ***
I'm still not able to reproduce this. I'm switching over to linux as my dogfood machine to see if I can catch this happening.
Whiteboard: [nsbeta2+] → [nsbeta2+
Per todays triage, moving to nsbeta2-. Hard to reproduce.
Whiteboard: [nsbeta2+ → [nsbeta2-]
Keywords: nsbeta3
nominating nsbeta3, but I still havn't seen this
nsbeta3-, won't hold for bugs we can't reproduce. renominate if you get a reproducible case.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Target Milestone: M17 → Future
I keep getting this all the time on 2000073009 on linux, on all 4 arrow keys, and in both text areas and input lines. My system: Mandrake 7.1, kernel 2.2.16, glib/gtk+ 1.2.7, gnome-core 1.1.9, and running mozilla in kde 1.1.2 It would be a shame if this bug stayed in the betas because of reproduction problems.....
now i'm only getting this on some pages, including this one.... wierd....
I've been trying to repro this on my redhat 6.2 system without success. I guess the next step is to construct a clone of the madrake system and hope that does it!
Status: NEW → ASSIGNED
*** Bug 47131 has been marked as a duplicate of this bug. ***
Sorry that I posted it as new bug. I have the same problem in all directions on THIS page, Build 080104 Windows 98.
I am now getting the same behaviour when writing a new message on Linux M18 2000080108. This DID NOT happend in 2000073009.
*** Bug 47270 has been marked as a duplicate of this bug. ***
I get this on NT4.0sp6, Mozilla 2000080820. In fact, I'm seeing it right now!
This WFM right now on 2000082421, but i'll have too see if it doesn't reappear later...
massive update for QA contact.
QA Contact: petersen → lorca
This should be works for me now, unless somone out there is still seeing it.
Resolving as fixed, as no new reports have been recieved in over two months, and it seems to be working. Reopen if you are still getting this with a current build.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
VERIFIED. Sound reasoning to me.
Status: RESOLVED → VERIFIED
SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: