User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040918 Firefox/0.10 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040918 Firefox/0.10 If I'm typing in a webform, the arrow keys will not move the cursor through text I already typed. (i.e. the cursor will only point at the last character I typed) If I want to fix a typo, I need to use the mouse to select the exact spot, delete the offending text (del and b-space do work), and enter my new text. I then have to use the mouse to move the cursor back to where ever I left off. Reproducible: Always Steps to Reproduce: 1. Open FireFox 2. Go to any site with a web form. 3. Pick a form element (input or textbox), and type something. 4. Try to use the arrow keys to move the cursor to the left. Actual Results: The cursor stayed where it was. Expected Results: Moved to the left thru the chars I already typed. Gentoo Linux distro running Gnome 2.6 (I doubt this info is necessary, but just in case). Didn't affect 0.9.3. I really considered making this Major instead of Normal because it's a major annoyance. I need to implement the 'fix-typo-by-mouse' procedure while typing this bug report.

I would like to add that I also encountered this on Gentoo/Gnome 2.6. I double checked on Windows 2000 and I did NOT encounter this issue. If neccessary, I will test on a wider variety of systems at a later time. Hope this helps.

I just heard from my friend--and subsequently tested it myself--that the arrow keys don't work in the address bar; nor do HOME and END. Seems to be a overal problem with text fields: <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=260297">Bug 260297</a>

Another update, the problem is resolved when you create a new profile. Still quite an annoyance if you don't know this. :)

I can verify this on Gentoo/Gnome 2.6/x86, using Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040916 Firefox/0.10. This has made Wikipedia editing, etc. almost impossible; I've had to switch back to nonFirefox Mozilla. Requesting blocking for 1.0.

Same here. Gentoo, Firefox 1.0PR. I would like to add, that bulk erase of text via ctrl-backspace is also malfunctioning.

We're seeing this on builds of PR1 on suse as well, and yeah, it should be a 1.0 showstopper- I've gotten a half-dozen reports of this in only a few days in even my small internal tester community.

A couple notes: - Pressing the arrow keys scrolls up/down/left/right if the input area has scroll bars. - Ctrl+Left and Ctrl+Right still correctly move cursor over one word at a time. - Shift+(Up/Down/Left/Right) still correctly selects text.

Temporary workaround: Create new profile, save compreg.dat from your old profile, copy compreg.dat from new profile to your old profile dir.

The problem is that the compreg.dat file is missing these lines: @mozilla.org/widget/native-key-bindings;1?type=editor,{f916ebfb-78ef-464b-94d0-a6f2ca3200ae} @mozilla.org/widget/native-key-bindings;1?type=textarea,{2a898043-180f-4c8b-8e54-410c7a540f27} @mozilla.org/widget/native-key-bindings;1?type=input,{5c337258-a580-472e-8615-f277ddc5bb06} in the [CONTRACTIDS] section. Adding them in should work. As a side note, it seems like there are other new lines in other sections -- and I have no idea what they change.

Oops. Sorry missed some needed line additions: {5c337258-a580-472e-8615-f277ddc5bb06},,application/x-mozilla-static,,nsWidgetGtk2Module {f916ebfb-78ef-464b-94d0-a6f2ca3200ae},,application/x-mozilla-static,,nsWidgetGtk2Module {2a898043-180f-4c8b-8e54-410c7a540f27},,application/x-mozilla-static,,nsWidgetGtk2Module need to be added to the [CLASSIDS] section

OK, I wasn't able to get B. Kahn's solution to work for me (but it's probably just me :-) ) In any case, I just got rid of my ~/.mozilla dir (renamed it) and brought her back up--all the problems I've been having have gone away. It just seems there is a really *big* problem with the settings import feature. See related bug(s): https://bugzilla.mozilla.org/show_bug.cgi?id=260298 https://bugzilla.mozilla.org/show_bug.cgi?id=260297 Also, as a new bug, I noticed that while using my old (imported) profile my new bookmarks never got saved, nor did any of my preferrence changes. If there isn't a bug report on those I'll probably open one...

I can confirm this bug for Mozilla 1.0PR on Gentoo Linux (Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040919 Firefox/0.10). Both in text boxes (either <textarea>, <input type=text>, <input type=password>) and the URL bar and the search text box. Mr. Kahn's solution did not work for me, either. Arrow keys, HOME, END, and Ctrl-K do not work.

Affects Fedora builds as well. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132917

So, we should be triggering component re-registration if you run with a different build id than you were using before, but that depends on MOZILLA_OFFICIAL=1 being set at build time (otherwise the build id is always 00000000). Are you guys who are seeing this building Firefox yourself, and if so, is MOZILLA_OFFICIAL getting set?

eBuilds are to Gentoo as *.rpm packages are to RedHat. eBuilds don't contain source; instead they reference a download location from the vendor.

Is referenced in eBuilds.

Gentoo offers binary and compile-from-source options for FireFox. I'm using the latter. After grepping my Portage (package manager) directory, and looking at all of the Mozilla eBuilds (package configs), it *looks like* MOZILLA_OFFICIAL is only being set in the eBuild configs for mozilla-1.7, mozilla-1.6-r1, and mozilla-1.7-r1. The text "MOZILLA_OFFICIAL" does not occur in any other file (including the eBuilds for Mozilla FireFox. How would one determine if MOZILLA_OFFICIAL was set after the fact? I've attached Mozilla and FireFox eBuilds and a related config files for reference/comparison. eBuilds are to Gentoo as *.rpm packages are to RedHat. eBuilds don't contain source; instead they reference a download location from the vendor. It almost looks like this bug is going beyond the scope of Mozilla (and may be moving more into a Genoo problem).

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

An easy way to check is to go to about:config and look at the value of app.build_id. If it's 00000000 then MOZILLA_OFFICIAL was not set.

(In reply to comment #20) > An easy way to check is to go to about:config and look at the value of > app.build_id. If it's 00000000 then MOZILLA_OFFICIAL was not set. OK -- Confirmed. app.build_id is, indeed, 00000000. Again, this is on Gentoo.

Confirm on Gentoo as well, when built from source using portage.

(In reply to comment #14) > So, we should be triggering component re-registration if you run with a > different build id than you were using before, but that depends on > MOZILLA_OFFICIAL=1 being set at build time (otherwise the build id is always > 00000000). Are you guys who are seeing this building Firefox yourself, I'm seeing it with Novell/SUSE builds, which set app.buildid to the date of the build. This kind of thing probably needs to be made reliable for non-official builds, given that if Sun and Novell (among others) are successful in their efforts to do large-scale enterprise sales, downloads directly from moz.org are going to be a shrinking percentage of the total download base :/

i noticed this when i upgraded from firefox 0.9.3 to pre 1.0. arrows don't work in textarea's, they scroll the text area, but the cursor will not move.

The compreg.dat fix worked for me. I removed compreg.dat and rebuilt disabling the typeahead extension, and these two steps fixed this. I was seeing this on Gentoo with 1.0_pre.

if someone can come up with a patch that gets this change into non-offical builds then I guess we could consider it. renominate if that happens.

This seems to be fixed in the newest Gentoo ebuild, which is for firefox 0.10.1.

I can confirm this for Firefox 0.10PR under Mandrake (10.1 Community).

Kahn's compreg.dat fixes solved the problem for me (running 1.0 preview rel on a beta of SuSE 9.2), but the tab key still doesn't behave -- Could you throw out a few more lines to add for tab, Benjamin?

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

I had this bug on a week old Windows build.

OS should be changed to "All" since this sometimes happens with Firefox 1.0 on Windows XP, too.

I use Firefox 1.0 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 When I input Chinese word (using Microsoft Pinyin input method) in input box, after I input a Chinese comma or Chinese period or other interpunction, press the left key can not move the cursor.

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

it happend not only in webforms. in fact, it happend all the time in every input area in firefox app, include every dialog box. i use microsoft pinyin 2003.

This happens to me too in FireFox 1.0.4 on WinXP-pro-SP2. For example in bugzilla text entry form, like this one. Only that it does not happen always. I'm yet to figure out the rule.

happening to me with trunk builds, _extremely_ annoying. requesting blocking, it's a very unprofessional taste attached to that bug, + it has other side effects (e.g. when arrows cannot be moved, hitting the -> ' <- character will activate find bar. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050725 Firefox/1.0+

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 The problem apperared on FF 1.5 Beta on WinXp, had not existed before. Benjamin Kahn's fix 2004-09-22 sorted this out.

gone in FF2?

I am unable to reproduce this issue. Please reopen if you have some better/newer STR.