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.

Reassigning to Steve.

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.

Our focus memory changes fixed this.

Nope, unfortunately I'm still seeing it on the 2/14 release build.

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.

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.

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.

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

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!

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

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

fixed

Ooops, setting resolution

The behavior had stopped.... Its started again on Linux builds (not seeing this on Windows)

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?

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.

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.

Putting on nsbeta3 nominee radar.

I've been seeing this a lot, it is maddening. nsbeta3+, P3 for 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.

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

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.

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.

*** 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

I got a window into this state using today's verification build on Win98. Changing OS to all.

->pavlov

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

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

Updating QA contact.

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!

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

saari knows whats going on

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

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. ***

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

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

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

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

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.

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.

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

*** 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

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.

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

*** 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); }

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

fix checked into mozilla 1.0 branch

Verified win xp branch build 2002091908, linux branch build 2002091906 and Mac os x branch build 2002091905

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