Closed Bug 26882 Opened 25 years ago Closed 22 years ago

spacebar causes page down in forms - textarea

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: snickell, Assigned: Brade)

References

(
URL
)

Details

(Keywords: helpwanted, regression)

Attachments

(2 files)

Little testcase to reproduce bug #26882
689 bytes, application/octet-stream
Details
Little testcase#2 to reproduce bug #26882
689 bytes, application/x-gzip
Details 
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.
Component: Form Submission → HTML Form Controls
Reassigning to Steve.
Assignee: karnaze → buster
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
Our focus memory changes fixed this.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Nope, unfortunately I'm still seeing it on the 2/14 release build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.


Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Target Milestone: M14
I'm having a lot of trouble reproducing this, as in, I havn't seen it at all.

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?


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.

*** Bug 25938 has been marked as a duplicate of this bug. ***
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.

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+]
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?)
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?
bmartin, can you try to reproduce this with 56k modem in DialUp lab?  Thanks!
QA Contact: ckritzer → bmartin
Whiteboard: [NEED INFO]
Hyatt and I think we know what is going on and will fix shortly, so you may want 
to wait on testing that
Whiteboard: [NEED INFO] → [PDT-][NEED INFO]
ok.  I will wait for the fix.
*** Bug 30467 has been marked as a duplicate of this bug. ***
*** Bug 31247 has been marked as a duplicate of this bug. ***
Move to M15
Status: REOPENED → ASSIGNED
Target Milestone: M14 → M15
fixed

Ooops, setting resolution
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
The behavior had stopped.... Its started again on Linux builds (not seeing this
on Windows)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
workaround.
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).
What info. does PDT need? This bug makes text fields unusable when it manifests. 
This definitely needs to be beta2.

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
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.)
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?
I just fixed this.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Target Milestone: M15 → M16
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)

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.
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: FIXED → ---
Putting on nsbeta3 nominee radar.
Keywords: nsbeta3
Whiteboard: [PDT-][NEED INFO] → [nsbeta2-][PDT-][NEED INFO]
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
So when did this start showing up again? Is 2000-08-26-08
 the first reoccurance?
The usual bit, if anyone knows how to get this to break reliably...


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.
Status: REOPENED → ASSIGNED
I believe my fix for bug 50606 fixed this regression
I think Pav is right, his event dropping would explain a lot of my bugs and 
the disappearance thereof (yay!)
Marking worksforme
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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 :)
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.)?
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.
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+]
*** Bug 51150 has been marked as a duplicate of this bug. ***
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)

I am unable to reproduce this in todays build.
I haven't seen it so far either today, in rather heavy use. (crossing fingers)
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.
Just noticed the "Linux" part, so this could be a separate issue, since I'm
using NT4sp6a.
gmiller: Can you provide steps to reproduce?
cc gmiller
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.
Updating QA Contact
QA Contact: bmartin → ckritzer
I got a window into this state using today's verification build on Win98.
Changing OS to all.
OS: Linux → All
->pavlov
Assignee: saari → pavlov
Status: REOPENED → NEW
I can't reproduce this on linux or windows.  could someone please give me a test
case or something for this.. please?

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
*** Bug 53101 has been marked as a duplicate of this bug. ***
Updating QA contact.
QA Contact: ckritzer → bsharma
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 http://bugzilla.mozilla.org/show_bug.cgi?id=21524
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.

This may be related to bug 59930 (from schut@gissrv.iend.wau.nl). 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.
I'm seeing this sporadically in the 12/5 build, after going months without
seeing it.
I saw this at least five times today while working with
http://tj2002.dhs.org/query.php

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.
Just FYI:  I am still able to reproduce this problem on my Win98 2000120920
build.   (by following the steps I have above exactly)
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.
I can reproduce it with wdorman's steps as well.  Yay!

BTW, this issue is also being tracked in bug 5419.
Wow, cool, a reproducable sequence! Thanks!
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
I just tried wdorman's steps on MacOS, and could not repro. I'll try the other
platforms.
Blocks: 5419
saari knows whats going on
Assignee: pavlov → saari
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.8
I do pav? target mozilla 0.8
I see this too, but sporadically.  Saari, you working on it?

/be
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.
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.
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.

/be
there are probably a few worksforme bugs about this.  I'll look around and see
if there is anything to add here.
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.
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!
->moz0.9
Target Milestone: mozilla0.8 → mozilla0.9
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.
Isn't this a duplicate of bug 5419 or vice versa?
*** Bug 66652 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
*** Bug 67514 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9 → mozilla1.0
I think I've finally found a way to reproduce this bug - at least very often.

1. open http://bugzilla.mozilla.org/showvotes.cgi?voteon=26882 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
URL: http://bugzilla.mozilla.org/showvotes...
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.

=)
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.
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.

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

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.
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 ;)
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?
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
SUBMIT BUTTONS*.

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.

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.
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.
I haven't seen the problem in the last week on linux. (since saari
commented that blizzard fixed the most common cause on linux).
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.
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.)
QA Contact Update
QA Contact: bsharma → vladimire
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.

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
http://bugzilla.mozilla.org/ (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.
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
behaviour).

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.
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?
Moses - I've just tested both and it doesn't matter whether it's <textarea> or
<input type="text">.
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.
bug filed as http://bugzilla.mozilla.org/show_bug.cgi?id=83940. Thanks for 
finding this.
It looks like this has been fixed by the fix to bug 83642.
*** Bug 85553 has been marked as a duplicate of this bug. ***
Argh.  I just hit this bug in 0.9.1, for the first time in months.
I hit this again too. Keep your eyes peeled for reproducable sequences.
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 (http://www.wsabstract.com ) 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.
*** Bug 84970 has been marked as a duplicate of this bug. ***
Is this fixed?
I still see it.
*** Bug 85053 has been marked as a duplicate of this bug. ***
I don't know if this helps or not, but this happens to me often when posting
messages on a ezboard bulletin board (http://www.ezboard.com/).  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.  
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
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).
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
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 (www.ezboard.com), although I have noticed it other places
as well.
0.9.7 != trunk
Please test with trunk build as this change went in only a day ago or so.
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 ...
I'm working on some known issues with minimizing windows horking focus, so that
may be related...
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...
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.
Hi!

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,
Loïc
The attachment is in ".tar.gz" format

Loïc
*** Bug 141922 has been marked as a duplicate of this bug. ***
*** Bug 139493 has been marked as a duplicate of this bug. ***
Setting Platform=All due to bug being observed on Mac OS X also.
Hardware: PC → All
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.

rateoty
Blocks: 140346
Keywords: mozilla1.0.1, nsbeta1
*** Bug 35952 has been marked as a duplicate of this bug. ***
I have filled out this bug (http://bugzilla.mozilla.org/show_bug.cgi?id=147824),
they might have something in common.
This used to happen to me *a lot* it was my most hated bug. I have been unable
to reproduce it in 1.1a .
Same here. wfm, 1.1 alpha on Win2k.
*** 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. ***
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.
-->brade
I have a fix for this in another one of my bugs
Assignee: saari → brade
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2-][nsbeta3-]
Target Milestone: Future → mozilla1.1beta
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.
The fix for bug 158672 landed today on 1.2 trunk so this should now be fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.1beta → mozilla1.2alpha
brade: The testcases are working, but they were working before, how can this be
reliably reproduced to test the latest patch?
QA Contact: vladimire → tpreston
*** 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
pagedown.
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 1.36.2.1.6.1
diff -u -r1.36.2.1.6.1 nsPlaintextEditor.cpp
--- text/nsPlaintextEditor.cpp	28 Jun 2002 03:41:06 -0000	1.36.2.1.6.1
+++ 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
a=rjesup@wgate.com 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+
fix checked into mozilla 1.0 branch
Keywords: mozilla1.0.2+ → fixed1.0.2
Verified win xp branch build 2002091908, linux branch build 2002091906 and Mac
os x branch build 2002091905
Keywords: fixed1.0.2 → verified1.0.2
*** Bug 155595 has been marked as a duplicate of this bug. ***
verified (WFM with today's nightly on win2k, but looks like this should have
been marked verified in comment 153 anyway...)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: