spacebar causes page down in forms - textarea

VERIFIED FIXED in mozilla1.2alpha



Layout: Form Controls
18 years ago
10 years ago


(Reporter: Seth Nickell, Assigned: Brade)


({helpwanted, regression})

helpwanted, regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments)



18 years ago
Sometimes when working with Textarea boxes, every time the spacebar is pressed,
the browser does a page down. Spaces in other form elements don't seem to ever
cause this problem - but I will admit to using far more spaces in a text area :)

I cannot reproduce the bug consistently - but it seems to happen most when I
change window focus and move back to typing in the form. Textarea boxes are
(thus far) the only elements I've been able to induce this with.


18 years ago
Component: Form Submission → HTML Form Controls

Comment 1

18 years ago
Reassigning to Steve.
Assignee: karnaze → buster

Comment 2

18 years ago
joki-hyatt-saari-mjudge-akkana:  anybody know anything about this?
rolled the dice:  assigning to saari for now.  Sure sounds like a focus issues.
I know I will not be able to look at this before Tu night deadline.
Assignee: buster → saari
Keywords: beta1
Summary: space (spacebar) causes page down in forms - textarea → [regression] space (spacebar) causes page down in forms - textarea

Comment 3

18 years ago
Our focus memory changes fixed this.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 4

18 years ago
Nope, unfortunately I'm still seeing it on the 2/14 release build.
Resolution: FIXED → ---

Comment 5

18 years ago
Incidentally, this is a dup of 25938, which has been marked as a dup of 23401,
which was marked fixed.  23401 does seem better, but 25938 is definitely not fixed.

Comment 6

18 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]


18 years ago
Target Milestone: M14

Comment 7

18 years ago
I'm having a lot of trouble reproducing this, as in, I havn't seen it at all.

Comment 8

18 years ago
Though I'm not positive...I haven't been able to produce the problem for the

past couple of day's builds. Perhaps it was fixed incidentally?

Comment 9

18 years ago
I was still seeing this in the 2/14 build, but only sporadically -- it's much
less frequent than it used to be, but once it starts happening I haven't figured
out how to get out of it. I'm still trying to find the combination of
circumstances which makes it happen.

Comment 10

18 years ago
*** Bug 25938 has been marked as a duplicate of this bug. ***

Comment 11

18 years ago
Snickell: have you come up with a way to reproduce this?  I was seeing it a lot
in yesterday's build, but haven't seen it yet in today's build and am at a loss
as to how I was reproducing it.  Maybe it really is fixed now.

Comment 12

18 years ago
Removing PDT+ for reconsideration. I can't reproduce it either. If it is really

so hard to reproduce, why would we hold beta1 for it?

shortening summary, moving regression tag to keywords.

Keywords: regression
Summary: [regression] space (spacebar) causes page down in forms - textarea → spacebar causes page down in forms - textarea
Whiteboard: [PDT+]

Comment 13

18 years ago
Yes, agreed.  This has gotten very hard to reproduce and no longer needs to be
PDT+.  In fact, maybe it really is fixed (I didn't see it all yesterday).  I'm
closing it for now -- if any of us see it again, we can reopen it and note the
circumstances when it happened.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 14

18 years ago
Okay, found a case where this happens.

I went to the bugzilla "Enter mail/news bug" page.  Bugzilla is really slow, so
after a few minutes, with most of the page loaded, I got tired of waiting and
started filing the bug.  Clicked on a component, scrolled down a little with the
scrollbar, clicked in the Summary field and typed something, clicked in the
Assigned to field and started typing.  Some time around then, the page finally
finished loading ... and now spaces paged the bugzilla page down.

My guess is that this means it has to do with something that happens to the
focus on OnEndDocumentLoad, which confuses the focus manager as far as spaces,
but not as far as normal typed letters.

Talked with saari about this and we agreed that the PDT+ is probably no longer
necessary since it has become so hard to reproduce.  (I only saw this once in
two days of dogfood-eating.)
Resolution: FIXED → ---

Comment 15

18 years ago
actually, I'll bet this is simple to reproduce, if you're not on a T1 line.  Try 
it on a 56k modem, I dare you!  does this make it pdt+ (if I'm right?)

Comment 16

18 years ago
Yeah, well, I don't own a modem or a dialup account so someone else will have to test that theory.  Don't we have a network that simulates 56k though?

Comment 17

18 years ago
bmartin, can you try to reproduce this with 56k modem in DialUp lab?  Thanks!
QA Contact: ckritzer → bmartin
Whiteboard: [NEED INFO]

Comment 18

18 years ago
Hyatt and I think we know what is going on and will fix shortly, so you may want 
to wait on testing that


18 years ago
Whiteboard: [NEED INFO] → [PDT-][NEED INFO]

Comment 19

18 years ago
ok.  I will wait for the fix.

Comment 20

18 years ago
*** Bug 30467 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
*** Bug 31247 has been marked as a duplicate of this bug. ***

Comment 22

18 years ago
Move to M15


18 years ago
Target Milestone: M14 → M15

Comment 23

18 years ago

Comment 24

18 years ago
Ooops, setting resolution
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 25

18 years ago
The behavior had stopped.... Its started again on Linux builds (not seeing this
on Windows)
Resolution: FIXED → ---

Comment 26

18 years ago
Yes: the new bug 35932 has also been tracking the most recent regression of this
feature (which started a couple of weeks ago).  See that bug for a possible

Comment 27

18 years ago
Oops, make that bug 35952.  It's dogfood+, since it makes it very hard to use
bugzilla (or any other page that depends on form input).

Comment 28

18 years ago
What info. does PDT need? This bug makes text fields unusable when it manifests. 
This definitely needs to be beta2.

Comment 29

18 years ago
I can try to reproduce this over 56k on Win32 machine... however, I don't have a 
Linux system configured for dialup.

Is there a set of steps to reproduce this bug 100% of the time?
Keywords: beta1, regression → nsbeta2

Comment 30

18 years ago
The most recent reopening of this bug may not have the same cause, and may not
be any more likely to happen on a dialup connection than on a T1.  I was seeing
it all the time on my Linux box here at work.  Try using linux/mozilla to make
all your bugzilla comments, and I suspect you'll see it quite often.

(I do have a linux box configured for dialup, but don't have a current build on
it; if someone has a reason to think it makes a difference, I can probably
download one.)

Comment 31

18 years ago
If we're not concerned about dialup specific issues with this bug... it makes 
sense to update the QA assigned to someone more appropriate.  Who might that be?

Comment 32

18 years ago
I just fixed this.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
Target Milestone: M15 → M16

Comment 33

18 years ago
My steps for reproduction are:
1) go to the bugzilla query page
2) click in a text field
3) click on the page
4) click back in the text field
5) press spacebar, observe scrolling page (or not, now that it is fixed)

Comment 34

18 years ago
This has regressed on Linux build 2000-08-26-08.  It isn't 100% reproduceable,
but sometimes a textarea has the input focus, and when you type a space the page
scrolls.  I have seen this three times when using bugzilla.
Keywords: regression
Resolution: FIXED → ---

Comment 35

18 years ago
Putting on nsbeta3 nominee radar.
Keywords: nsbeta3
Whiteboard: [PDT-][NEED INFO] → [nsbeta2-][PDT-][NEED INFO]

Comment 36

18 years ago
I've been seeing this a lot, it is maddening.  nsbeta3+, P3 for M18
Whiteboard: [nsbeta2-][PDT-][NEED INFO] → [nsbeta2-][PDT-][nsbeta3+]
Target Milestone: M16 → M18

Comment 37

18 years ago
So when did this start showing up again? Is 2000-08-26-08
 the first reoccurance?

Comment 38

18 years ago
The usual bit, if anyone knows how to get this to break reliably...

Comment 39

18 years ago
If anyone inside Netscape sees this, please come get me so I can look at it!

Or, check if you can reproduce bug 50317 once you're in this state. I'm
wondering if they're related.


18 years ago

Comment 40

18 years ago
I believe my fix for bug 50606 fixed this regression

Comment 41

18 years ago
I think Pav is right, his event dropping would explain a lot of my bugs and 
the disappearance thereof (yay!)

Comment 42

18 years ago
Marking worksforme
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 43

18 years ago
no such luck, trudelle saw this today.

Current thinking is just disable the spacebar scrolling of pages, as this is
proving to be very fragile in the long term.
Resolution: WORKSFORME → ---

Comment 44

18 years ago
Yeah, I always say "hide the bug so that when it pops up in some other context
later, it is even harder to find and fix."

Delivering events to the right widget is basic functionality.  If an effort is
really made to fix this, it might reveal a basic problem that fixes many other bugs.

Of course I don't have time to fix this myself :)

Comment 45

18 years ago
Argh!  Turning off spacebar scrolling would be a huge regression and
functionality loss.  And won't we also see this problem on other keys that are
interpreted differently by textareas vs. the browser window (e.g. page up/down,
XUL vs XML bindings, etc.)?

Comment 46

18 years ago
akkana, I would think we would see it with other keys, but my tests to that end
have failed... although I've only gotten to play with it on trudelle's machine a
little. I'm using linux as much as possible to try and repro this.

Baker, quite a large amount of time has been spent on this bug, and it still
keeps regressing. I agree we need to fix it, but I'm having a hell of a time
seeing it at all this time around. When trudelle reproduced it, it wasn't a
debug build, so there wasn't much I could do with it. If you want this fixed,
the best thing you can do is try and come up with a way to reproduce it.

Comment 47

18 years ago
Eliminating space scrolling would not involve functionality loss, since PgDn 
works.  Considering that the paging while you type spaces makes the product 
unusable for forms, this is an obvious tradeoff we should make in order to 
ship, unless we can reproduce this reliably.
Whiteboard: [nsbeta2-][PDT-][nsbeta3+] → [nsbeta2-][nsbeta3+]

Comment 48

18 years ago
*** Bug 51150 has been marked as a duplicate of this bug. ***

Comment 49

18 years ago
Well, I just checked in a couple little fixes that should help linux focus 
issues. They could get command dispatching confused once you'd opened a message 
compose window (and probably other things). Could be related. 

So... if someone still sees this next week, I'm back to square one. Hopefully 
this will fix the problem though. (I know it fixes other problems)

Comment 50

18 years ago
I am unable to reproduce this in todays build.

Comment 51

18 years ago
I haven't seen it so far either today, in rather heavy use. (crossing fingers)

Comment 52

18 years ago
I'm currently seeing it with 2000090504. I'm also experiencing problems with the
arrow keys causing the page to scroll rather than moving the caret in the textarea.

Comment 53

18 years ago
Just noticed the "Linux" part, so this could be a separate issue, since I'm
using NT4sp6a.

Comment 54

18 years ago
gmiller: Can you provide steps to reproduce?

Comment 55

18 years ago
cc gmiller

Comment 56

18 years ago
I was experiencing this every time I used SlashDot's posting system. With
Bugzilla, I was experiencing the arrow key problem but not the spacebar problem,
so these may be two separate issues. I fell back to build 2000090308 and can't
reproduce either with this build. I'm downloading a nightly from today as I post
this. I'll post again if I can come up with anything.

Comment 57

18 years ago
Updating QA Contact
QA Contact: bmartin → ckritzer

Comment 58

18 years ago
I got a window into this state using today's verification build on Win98.
Changing OS to all.
OS: Linux → All

Comment 59

18 years ago
Assignee: saari → pavlov

Comment 60

18 years ago
I can't reproduce this on linux or windows.  could someone please give me a test
case or something for this.. please?

Comment 61

18 years ago
nsbeta3-/future, this no longer fits the profile for bugs that we can commit 
to.  If anyone can find a reproducible case, please renominate.  HELPWANTED
Keywords: helpwanted
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3-]
Target Milestone: M18 → Future

Comment 62

18 years ago
*** Bug 53101 has been marked as a duplicate of this bug. ***

Comment 63

18 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Comment 64

18 years ago
I'm sure there's a simpler way to reproduce this, but this method works 100% of
the time on my system.

1. Go to
2. Open the attached testcase in a new window.   (right click, and open in new
window, or on my system I just middle-click)
3. Close the smaller of the 2 windows that popped up
4. Click the URL of the remaining Mozilla window
5. Dismiss the alert by clicking OK
6. Close that Mozilla window
7. Click in the "Additional Comments" textbox
8. Type something with spaces

On my Win98SE system running 2000092808 Mozilla will pagedown every time I press
space.    Granted this testcase it quite involved, but that's how I came across
it and it works.

Comment 65

18 years ago
This may be related to bug 59930 (from In that bug,
GetFocussedWindow returns null, with then causes a crash. I have seen this
happen when pressing space in the google search box. If something is getting
confused about whats currently focussed (and so returns the wrong window instead
of null), the same problem could be causing both bugs.

Comment 66

18 years ago
I'm seeing this sporadically in the 12/5 build, after going months without
seeing it.

Comment 67

18 years ago
I saw this at least five times today while working with

But since I found the bug report I haven't been able to reproduce it, even with
wdormann's test steps. Doesn't help at all :-( Hopefully I'll find how to
reproduce it soon. Running Linux 2000112718.

Comment 68

18 years ago
Just FYI:  I am still able to reproduce this problem on my Win98 2000120920
build.   (by following the steps I have above exactly)

Comment 69

18 years ago
Weird, saari isn't on this bug even though he owned the other bug on this issue,
and this seems to be XP, not Unix only.  Cc'ing.

Comment 70

18 years ago
I can reproduce it with wdorman's steps as well.  Yay!

BTW, this issue is also being tracked in bug 5419.

Comment 71

18 years ago
Wow, cool, a reproducable sequence! Thanks!
Target Milestone: Future → mozilla0.9

Comment 72

18 years ago
I just tried wdorman's steps on MacOS, and could not repro. I'll try the other


18 years ago
Blocks: 5419

Comment 73

18 years ago
saari knows whats going on
Assignee: pavlov → saari


18 years ago
Target Milestone: mozilla0.9 → mozilla0.8

Comment 74

18 years ago
I do pav? target mozilla 0.8
I see this too, but sporadically.  Saari, you working on it?


Comment 76

17 years ago
I've become convinced that this is related to whatever code makes positions the
vertical scroll when a page is returned to via the Back button.  I don't believe
that I have ever seen this on the first visit to a page, but I frequently see it
when doing load page->scroll->click link->click back->type in textarea.

Comment 77

17 years ago
Brendan, it is on my list of things to do in the near term, but there are
several things on that list. Hopefully I'll get to it soon.

Comment 78

17 years ago
Okay, in about 20 attempts using wdormann's steps, I've reproduced this twice.
Are others getting 100% with those steps? Maybe I'm doing something wrong, but I
really need to find a 100% reliable way of causing this.
jwbaker's report jibes with my experience.  Typically I'm typing into a bug's
textarea, so the bug page is scrolled down a bit.  I go forward to a patch I'm
reviewing, copy some text, come back, paste it -- or I switch windows and come
back.  Somehow, spaces start going to the window, not to the textarea.

I have other woes that I associate with this syndrome: space sometimes doesn't
scroll the page (maybe it's going to a text or textarea, but I can't tell); text
I've pasted into the bugzilla textarea gets its line endings doubled (or maybe
LF=>CRLF; I'm on Linux) when I go forward and back (no submission! client side
only).  Cc'ing asa for QA help.


Comment 80

17 years ago
there are probably a few worksforme bugs about this.  I'll look around and see
if there is anything to add here.

Comment 81

17 years ago
Do you use key shortcuts for window switching, cutting/copying/pasting, mouse
only, or a combination of them? Still trying to reproduce this with some regularity.

Comment 82

17 years ago
On my system, using the steps I described above using bug 21524 works every time
as long as the attachment for bug 21524 works properly!   It should open 2 new
Mozilla windows, one small, and one larger.      It seems that sometimes the
small window pops up as expected, but rather than having the other larger window
pop up, the contents of that window are just shown in the main Mozilla window.

But that's a whole other bug alltogether, I'd guess!

Comment 83

17 years ago
Target Milestone: mozilla0.8 → mozilla0.9

Comment 84

17 years ago
This has been happening to me a lot lately. ccing myself. I've
seen this several times in the last few days when typing into
textareas on bugs that i've gotten to by clicking the link from
a bug mail. This is happening at work, despite the studly fast
intranet link.

I'm on linux using the 2001011808 tar.gz nightly build.

Comment 85

17 years ago
Isn't this a duplicate of bug 5419 or vice versa?
*** Bug 66652 has been marked as a duplicate of this bug. ***


17 years ago
Keywords: mostfreq

Comment 87

17 years ago
*** Bug 67514 has been marked as a duplicate of this bug. ***


17 years ago
Target Milestone: mozilla0.9 → mozilla1.0

Comment 88

17 years ago
I think I've finally found a way to reproduce this bug - at least very often.

1. open in a new window
   (you should have enough votes already or that window should be small enough
   to make it necessary to scroll down to see the "submit" button)
2. edit any input field, e. g. make an illegal vote (like 10) for a bug
3. scroll down and hit submit to get the "illegal vote" message
4. hit the browser's back button
-> viewport is at the top again, but maybe it should be at the bottom where
   it was when hitting "submit"?
5. click in some input field
6. hit the space bar
-> page scrolls down

Comment 89

17 years ago
I can't reporduce the problem with your test case (on linux). When i hit 
'back' the viewport is in the correct place. The bug happens to me a lot
when i'm reading mail and click a bugzilla link in a bug mail. I think
this bug is synced to certain astronomical phenomena in the same way that
only certain people can see a solar eclipse at a given time and only for a
short period.


Comment 90

17 years ago
I now have a way to reproduce this 100% on linux.
Set click to focus in sawfish. Open browser window. Open mail. click on buzilla
link from mail window. Just as the window manager brings the browser window
forward, hit spacebar several times. You should be in the "hooked on spacebar
scrolling" mode now, even if you click in the text area.

The problem is that the activate event doesn't seem to be firing from the gtk
widget code in this case and the focus controller's semaphore stays locked. As
far as it is concerned, you never clicked on the text field.

Comment 91

17 years ago
I just saw this on a bugzilla query "Additional Comments" too.

IMPORTANT: this is NOT just happening on spacebar. I see it on hitting normal
text keys too. When typing causes rapid flashing of trying to go page down and
then sort of bouncing up so the text line being entered is just viewable at the
top of the browser window. I hadn't seen this is several weeks until today, but
it definintely isn't restricted to hitting spacebar.

CC self, also shaver, fabian, hwaara by request.

Comment 92

17 years ago
BTW, not sure the importance or relevance, but I'm on 56k dialup. Seen that
mentioned in this bug.

Comment 93

17 years ago
I've seen the effect jg mentions, too, and it's maddening trying to type in that
mode.  I've wondered whether it was the same as this bug, or a different bug,
but haven't filed a different one because I don't have a reproducible case for
the non-spacebar version of this.

Comment 94

17 years ago
This happens to me every time I submit multiple pages to Altavista. The first
page is submitted fine, but after I use the Go menu to return to the page where
you enter the URL, typing in the new URL produces the effect described above.

However, there've been lots of cases that reproduce only on one machine, so
don't get your hopes up for this one ;)

Comment 95

17 years ago
Okay, I'm pretty sure blizzard killed the most common case of this happening on
linux. Mac and Windows still have cases where this will happen though. I'm
looking for a reproducable case for Win2k now. If I can't get one for win2k I'll
install 98, although I'd really rather not have to do that if at all possible.

Anyone been hitting this on recent linux builds?

Comment 96

17 years ago
OK I have had two cases on Linux in past 24 hours using a home opt build from
the tip a couple days ago.

They both occured typing into the Additional Comments field in bugzilla. The
first only affected the spacebar, the second on every key *AND MOUSECLICK ON

I say the latter in strong emphasis because I couldn't get the "Commit" button
to do anything - it just shot me to the end of the page. I had to use tab to
select the widget and hit enter. Grr.

Anyway, I strongly suggest that the problem is to do with focus.

The first incident (only on spacebar) occured when I was commenting on a bug
after pulling another bug up in another window. I read the 2nd bug, switched
back to the original report to start typing, and found the problem occuring. I
then started playing around be switching the Window Manager's focus between
windows, and clicking the textarea widget and the page, and I got the problem to
go away. Alas I don't remember a reproducable set of steps. It wasn't too
difficult to do, did it within ten clicks iirc, but getting the problem in the
first place is equally difficult.

The second case where every key was affected I don't recall doing much focus
switching. I'll try to record next time what I do and get a reproducable set of
steps both getting the problem and getting out of it again. Some help here is
going to be needed I fear.

Comment 97

17 years ago
Oh, the problem is definitely focus related. Okay, so it still lives... the
common one is the first case where you pop up a new window and the spacebar
scrolls. Your second case is new to me, I'm not even sure how you could get
every key to scroll! Something got seriously out of line there.

Comment 98

17 years ago
I see the "every key scrolls" fairly frequently when I go to a bugzilla page, go
somewhere else (another bugzilla page?) in the same window to check something,
then use the back button to go back to the bugzilla page and resume typing in
the Additional Comments field.  I haven't had problems with clicking on form
buttons, though -- I can always submit, I just can't see what I'm typing since
it scrolls on every key I press.

Comment 99

17 years ago
I haven't seen the problem in the last week on linux. (since saari
commented that blizzard fixed the most common cause on linux).

Comment 100

17 years ago
Akkana, I know you run point to focus, do you run the "raise windows on focus"
option too? Trying to get my system into the most problematic mode.

Comment 101

17 years ago
No, I don't use autoraise.  I'm not sure mine is the most problematic mode,
though; I usually only see this once or twice a week.  James Green's setup might
be the one to copy.  (But you're welcome to copy my .kde files if you want to
try that.)

Comment 102

17 years ago
QA Contact Update
QA Contact: bsharma → vladimire

Comment 103

17 years ago
Grr two mid-air-collisions later, I'll repeat my comments:

My Setup:
Debian Sid, XF4.0.2, Ximian GNOME with Enlightenment 0.16.5 and "spiffe" theme.
Home built mozilla. Any more info needed, lemme know.

Comment 104

17 years ago
This happens for me consistently (i.e. every press of the space bar, whether or
not the caret/focus is in the form element, causes a page down) on (in the "Enter a bug # or some search terms:"
(<input type="text" name="id">) input form element).

It doesn't manifest itself if:
1) I save the HTML to disk and play with the page from there.
2) I remove the Javascript "document.forms['f'].id.focus();" from the page and
fetch the page via http (from a copy on my webspace).

I'm using build 2001060220 on Win98. Not using point to focus or auto-raise.

Comment 105

17 years ago
More detail about the behaviour I'm seeing (sorry for the spam):

The first time the page loads, the JS focuses the input element. [space] does
page-down (unexpected behaviour).
Click elsewhere on page (say the background). [space] does page-down (expected
behaviour - does this for all other pages).
Click back in the input element. [space] no longer does page-down (expected

I guess this bug happens whenever the page contains JS to autofocus a text input
element on page load. I can reproduce it with a very simple page that consists
of an input element, JS to focus it on page load, and random text below it to
make the page long enough to see the page-down.

Comment 106

17 years ago
isn't that a separate bug, what you were just talking about? This bug is about
<textarea>s, not <input type=text>s, if i'm reading the summary correctly. Or
has it morphed to include some other things, too?

Comment 107

17 years ago
Moses - I've just tested both and it doesn't matter whether it's <textarea> or
<input type="text">.

Comment 108

17 years ago
Okay, this totally was broken between the a.m. builds of 5/31 and the afternoon 
respins on 6/01, on mac/linux/win32, for either <input type=text> or <textarea>

I'm going to file a bug _specifically_ for this regression with a couple of 
simple testcases, just to perfectly clear about when and what got busted, 
and what needs to be fixed.

Comment 109

17 years ago
bug filed as Thanks for 
finding this.

Comment 110

17 years ago
It looks like this has been fixed by the fix to bug 83642.

Comment 111

17 years ago
*** Bug 85553 has been marked as a duplicate of this bug. ***

Comment 112

17 years ago
Argh.  I just hit this bug in 0.9.1, for the first time in months.

Comment 113

17 years ago
I hit this again too. Keep your eyes peeled for reproducable sequences.

Comment 114

17 years ago
Here's something interesting:  when this bug hits (and I just saw it again), the
arrow keys won't move the cursor in a text area.
What, specifically, are the differences between this bug and bug # 5419?  I've
noticed this bug blocking 5419, but I can't for the life of me find any
differences in what the two bugs say, other than the summary line.

I've been seeing this problem since Moz0.9, when I started downloading
milestones regularly again.  (I don't remember whether I saw it on my earlier
milestone downloads.)  I wonder if someone can clarify which testcases generate
which results -- one of them the result of a pagedown, the other resulting in
jumping to the bottom of the page.

I see this bug very, very often while I'm doing support in the Website
Abstraction ( ) Help Forum.  For me, it usually jumps
to the bottom of the page, but every time I type a letter character immediately
after, it scrolls back to place the last-typed character at the top of the page.

Comment 116

17 years ago
*** Bug 84970 has been marked as a duplicate of this bug. ***

Comment 117

17 years ago
Is this fixed?

Comment 118

17 years ago
I still see it.

Comment 119

17 years ago
*** Bug 85053 has been marked as a duplicate of this bug. ***

Comment 120

17 years ago
I don't know if this helps or not, but this happens to me often when posting
messages on a ezboard bulletin board (  Acutally, it's
also happening to me as I type this comment.

This not only happens for '<TEXTAREA>' but also for '<INPUT TYPE="text">' on
EZBoard's posting page.  This also seems to coincide with the loss of the
ablility to use the arrow keys in a '<TEXTAREA>' field.

I'm new at posting comments, so I'm not sure if this is a lot of help or not.  

Comment 121

17 years ago
Greg, are you running current versions of Mozilla? What platform? I haven't seen
this in a while, so I'll need as much info. as possible from anyone who does
still see it
Target Milestone: mozilla1.0 → mozilla0.9.9

Comment 122

17 years ago
Yes, I was running 0.9.4 at the time, and I'm running 0.9.5 now.  This was on
Windows NT.  I'm running Windows 98 at home, and haven't noticed it on there (of
course, I use my browser at work more than I do the one at home).

Comment 123

16 years ago
need a consistent repro case here. this may have been fixed by 122462 anyway.
futuring this for now.
Keywords: nsbeta2, nsbeta3
Target Milestone: mozilla0.9.9 → Future

Comment 124

16 years ago
Still see it in 0.97 on NT 4.0 occasionally.  It can usually be fixed by
minimizing and restoring a few times.  This seems to happen quite a bit when
posting on an EZboard (, although I have noticed it other places
as well.

Comment 125

16 years ago
0.9.7 != trunk
Please test with trunk build as this change went in only a day ago or so.

Comment 126

16 years ago
Still having this with 0.9.8, 2002020406
Appeared when working with database in phpMyAdmin, twice this day ...
Don't exactly know how to reproduce this, I scrolled the page several times,
minimized the window, changed tabs, scrolled both with wheelmouse and scrollbar ...

Comment 127

16 years ago
I'm working on some known issues with minimizing windows horking focus, so that
may be related...

Comment 128

16 years ago
Noticed this on 0.9.8 (linux) - installed build 2002022114 - and its still 
there. Appears only in the textarea in phpMyAdmin - i've tried to reproduce in 
my own code but it ain't having anything - maybe its because extra form 
elements are present below the 'sql entry area' in phpMyAdmin... it appears in 
both tabbed pages and single page windows - its reproducable every time in 
phpMyAdmin 2.2.3 - buggar...

Comment 129

16 years ago
I don't know if this is the proper bug, but I now notice this behaviour on
Slashdot when entering text in a message form, and on Bugzilla Helper.

It is not happening in the regular bug comments box (this box).

Build 2002041203, Win2k.

Comment 130

16 years ago
Created attachment 81377 [details]
Little testcase to reproduce bug #26882


Just use this testcase in two stages:

1. Load the "testcase_frame2.htm" file in your browser and type some strings
and space characters in the textarea -> it works;

2. Now load the "testcase_index.htm" file in your browser. It runs the
"testcase_frame2.htm" you used before in the right frame. But if you type some
string with space characters in the textarea Moz. now browse to the end of the
page :(

Indeed it seems using the "select()" method for a textarea inside a frameset
transfers the focus to the main frameset: you can fix the problem here by
adding a "window.focus()" before the "select()" method is called... but then it
breaks the code with other browsers.

Hope that helps,

Comment 131

16 years ago
Created attachment 81378 [details]
Little testcase#2  to reproduce bug #26882

The attachment is in ".tar.gz" format

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

Comment 133

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

Comment 134

16 years ago
Setting Platform=All due to bug being observed on Mac OS X also.
Hardware: PC → All

Comment 135

16 years ago
linked with this bug is the following:
you cannot use the arrow keys to navigate inside the affected textarea. Means:
If the setting is to behave like described (hit spacebar forces frame to scroll
down), the arrow keys are disabled. You have to hit the form submit button, to
achieve proper behavior.



16 years ago
Blocks: 140346
Keywords: mozilla1.0.1, nsbeta1

Comment 136

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

Comment 137

16 years ago
I have filled out this bug (,
they might have something in common.

Comment 138

16 years ago
This used to happen to me *a lot* it was my most hated bug. I have been unable
to reproduce it in 1.1a .

Comment 139

16 years ago
Same here. wfm, 1.1 alpha on Win2k.

Comment 140

16 years ago
*** Bug 152032 has been marked as a duplicate of this bug. ***
To toss in another data point, I just saw this in my optimized Mozilla Linux
build (with a tree from Wednesday evening) for the first time in about a month
or two.  (When I saw it a month or two ago it was the first time in more like
six months.)  I was using tabbrowser at the time, with a window containing two
tabs (for bug 154815 and bug 108585), and I saw it when I started to comment on
the latter bug.  I'm not exactly sure what I did leading up to the problem,
though, and I highly doubt I'd be able to reproduce it.
*** Bug 73725 has been marked as a duplicate of this bug. ***

Comment 143

16 years ago
This bug just hit me while entering a Bugzilla comment.  So, confirming with
build 2002072704 trunk, Windows XP.

I've never seen it before and it happened only when I was in the middle of
entering a comment.  (It freaked me out too - I thought that it was related to
the build I'd just downloaded.)  After I finished a paragraph (hit Enter) it
stopped doing it and I'm not seeing it as I enter this comment.  I can't tell
you what was "going on" at the time that it started or stopped other than what
I've already said.  So while I also cannot contribue anything to its
reproducability, I can at least confirm that it does still exist.

Comment 144

16 years ago
I have a fix for this in another one of my bugs
Assignee: saari → brade


16 years ago
Whiteboard: [nsbeta2-][nsbeta3-]
Target Milestone: Future → mozilla1.1beta

Comment 145

16 years ago
I tested the patch attached to bug 158672 on Windows2K using the "Little testcase 
#2" and it prevents spacebar from causing the page down behavior.

Comment 146

16 years ago
The fix for bug 158672 landed today on 1.2 trunk so this should now be fixed.
Last Resolved: 18 years ago16 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.1beta → mozilla1.2alpha

Comment 147

16 years ago
brade: The testcases are working, but they were working before, how can this be
reliably reproduced to test the latest patch?


16 years ago
QA Contact: vladimire → tpreston

Comment 148

16 years ago
*** Bug 152009 has been marked as a duplicate of this bug. ***
For the record, to clarify my comment 141 with steps to reproduce (since I was
just using a 1.0 branch build, and did the same thing I did before writing
comment 141 again, and figured out the pattern), the steps to reproduce what I
did to see this bug were:
 * load bug 96831
 * scroll down to comment 41
 * right click on the "bug 158043" text and click "Open in New Tab"
 * click in the "Additional comments" textarea on that bug and begin typing
 * click on the bug 96831 tab
 * click on the bug 158043 tab, but *don't* click in the page or the textarea
 * continue typing in the textarea.
This, in a 1.0-branch build, leads to the state where spacebar in textarea does

Comment 150

16 years ago
I'd like to land this on the 1.0 branch if permitted.
Here is the patch which fixes this problem (already r/sr in bug 158672):

Index: text/nsPlaintextEditor.cpp
RCS file: /cvsroot/mozilla/editor/libeditor/text/nsPlaintextEditor.cpp,v
retrieving revision
diff -u -r1. nsPlaintextEditor.cpp
--- text/nsPlaintextEditor.cpp	28 Jun 2002 03:41:06 -0000
+++ text/nsPlaintextEditor.cpp	22 Jul 2002 15:55:16 -0000
@@ -525,6 +525,7 @@
     if (character && !altKey && !ctrlKey && !isShift && !metaKey)
+      aKeyEvent->PreventDefault();
       nsAutoString key(character);
       return TypedText(key, eTypedText);
Keywords: mozilla1.0.1 → mozilla1.0.2 1.0 branch approval for the 1-line fix in comment 150
Please change mozilla1.0.2+ to fixed1.0.2 when checked in
Keywords: mozilla1.0.2 → mozilla1.0.2+

Comment 152

16 years ago
fix checked into mozilla 1.0 branch
Keywords: mozilla1.0.2+ → fixed1.0.2

Comment 153

16 years ago
Verified win xp branch build 2002091908, linux branch build 2002091906 and Mac
os x branch build 2002091905
Keywords: fixed1.0.2 → verified1.0.2

Comment 154

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

Comment 155

15 years ago
verified (WFM with today's nightly on win2k, but looks like this should have
been marked verified in comment 153 anyway...)
You need to log in before you can comment on or make changes to this bug.