STR: 1) Search "mozill firefox" on Google 2) Click somewhere in the search box. Now try to correct the query by clicking after "mozill" to add an "a". Expected results: The cursor position is set where clicked. Actual results: The cursor position is briefly set, but the entire word, "mozill", is highlighted, making it difficult to edit the search without retyping the whole word "mozilla". The first click inside the textbox seems to work fine, but all subsequent clicks while focused highlight the word rather than adjust the cursor position. If you click outside of the textbox to make it lose focus, then click the textbox again, it will work again for the first click. This is only reproducible using the Swype keyboard.

blocking fennec? This bug prevents Swype users from inserting the cursor to edit text without having to retype the entire selected word. Swype works correctly on ICS stock browser and Chrome Beta, so this is our bug. Swype also works correctly in the AwesomeBar.

I don't think this bug should be a blocker, even for the .N+ milestone. Tapping a word in a text form (but not URL bar) selects the word when using Swype. This behavior is not a big problem and, in fact, is sometimes convenient feature. :)

I believe the fix for bug 780191 will also fix this Swype bug.

After further testing, I don't think bug 780191 will fix this bug.

Re-test this with a build that has jim's IME rewrite.

The issue is still reproducible on Samsung SII( Android 4.0.3) but not reproducible on Samsung Galaxy R (Android 2.3.4) using Nightly 19.0a1 (2012-11-12).

cpeterson's comment isn't true. This is very different to the default Swype behaviour, and it's definitely not a convenience. Default swype behaviour (version 3.26.92.37861.37862.7706.N7000_EUR, Samsung Galaxy Note) in all apps that don't overide (stock browser, Dolphin browser, native apps): - Tapping in a search bar, HTML input fields or text area smoothly places the cursor in the tapped position. Swype reads the word, and offers alternatives, but the word is NOT selected - Tapping then dragging the cursor handle moves the cursor smoothly without selecting words (unless words have been selected and the two-part selection cursor is being shown) - Tapping then typing inserts characters from the tapped position. Nothing is overwritten unless a word is manually selected - Selecting an alternative word using Swype changes the word, and moves the cursor to the end of the new word. The word is never selected unless selected manually. This is the expected, desired behaviour. Here's my experience using Firefox Mobile for Android (18.0 and previous release) and Firefox Beta (19.0 and previous release): - Tapping in the search bar has the default behaviour, as above. - Tapping in a HTML input field or text area initially places the cursor in the tapped position. Then, the word is selected. Then, depending on how many lines of text there are, there may be a 'juddering' where the word is rapidly selected and unselected and the scroll position of the page and/or the scroll position within the input moves rapidly. - Tapping then typing overwrites the word that was where the initial tap was. I can't find any way to unselect the word and prevent this from happening. - Tapping then dragging the cursor handle selects whatever word the cursor is overlapping when it is placed. - After a word is selected from the Swype options (including automatic selections while swyping), the cursor jumps to either the end of all the text in the input field, or to the position it had before the tap. For example, imagine a user had typed "The browser is nice, I would recommend it" They want to change this to "The browser is really very nice, I would recommend it" They tap between 'is' and 'nice', and swype the words 'really very'. The end result is "The browser is really, I would recommend it very". The word was selected despite the user not intending it to be selected, and after the automatic swype selection of the word "really", the cursor jumped back to its prior position at the end of the input. This is clearly a bug, not a convenience. There's another strange behaviour I've seen, which I'll mention here because I suspect it has a similar underlying cause. When 'Select word' is used from the long press menu, bringing up the two-part selection cursor handles, their behaviour is strange and unpredictable. Often, instead of selecting the word that was pressed, the same number of characters are selected in a line of text two or three above where the text was selected. Dragging one of the cursors in any direction usually results in nothing being selected. In my experience it's essentially broken and unusable. This behaviour only happens in Firefox, and it's only this extreme when Swype is used (with the default Samsung keyboard, it's a bit jumpy compared to in other browsers, and it often likes to unpredictably jump to the end of the text which doesn't happen in other browsers, but it usually can just about manage to select the intended text). It would be usable if, when Swype is in use, the default cursor and behaviour was used for text selection within input and textarea fields instead of this orange Firefox one, as appears to be the case with the search bar.

This bug is old and no more progress for more than 2 years, so I am removing the tracking flag now. feel free to renominate. Thank you !

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.